568162 - Fix a hack leftover in the WebM seeking code from the prototype implementation

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Matthew Gregan [:kinetik]]

From https://bugzilla.mozilla.org/show_bug.cgi?id=566245#c14

Comment 1

[Matthew Gregan [:kinetik]]

Attachment: patch v0

I think this is what we want.  Decode forward at least 2 frames (rather than just one).  Use the start time of the second frame as the end time for the first frame, since we can't assume they're a fixed distance apart (and thus can't use/don't have a valid mCallbackPeriod).

Asking Chris P for review since he wrote the Ogg version of this code.

Comment 2

[Matthew Gregan [:kinetik]]

Attachment: patch v0

Without random hunks of other patches included.

Comment 3

[Matthew Gregan [:kinetik]]

I'm not sure why, but this patch seems to make seeking quite a bit slower.  Needs investigation.

Comment 4

[Matthew Gregan [:kinetik]]

I measured it by timing the start and end of nsWebMReader::Seek and it turns out that it's only slower by about what you'd expect for decoding an additional frame or so.  Over approximately 400 seeks in a local copy of sync.webm, the mean time to seek is 101ms ± 5ms before and 128ms ± 6ms after.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 447473 [details] [diff] [review]
patch v0

Looks reasonable.

Comment 6

[Matthew Gregan [:kinetik]]

This still applies on top of the latest version of bug 566245, so it's ready to land whenever that bug does.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

http://hg.mozilla.org/mozilla-central/rev/523c8b56ca16