Closed Bug 534559 Opened 10 years ago Closed 10 years ago

Implement seeking without liboggplay


(Core :: Audio/Video, defect)

Not set



Tracking Status
blocking2.0 --- beta1+


(Reporter: cpearce, Assigned: cpearce)




(5 files)

When bug 531340 hands, we'll be removing our dependency on liboggplay and liboggz. Since we currently use those libraries to seek, we'll need to re-implement seeking.
Based on patch in bug 531340 attachment 41480 [details].

Fixes YUV conversion. Not necessary, since we will be replacing that YUV code anyway, but I include this patch so that the line numbers in subsequent patches match up. Without this patch, videos with y-offset frames try to read out of the bounds of their frame data/array when doing YUV to RGB conversion, which causes a protection fault on Windows.
Based on Part 1.

* Switches all timestamps to 64bit integers, in milliseconds. This will prevent minor floating point rounding errors when doing frame-accurate seeking.
* Abstracts reads theora and vorbis pages such that we *always* know the granulepos of all frames. Only the last packet on a page will have a granulepos. If we want to know the presentation time of the first packet after we start decoding, and it's got a -1 granulepos, we need to work it out by reading until a packet with a granulepos occurs, and calculating the granulepos of preceeding packets relative to the known granulepos. With this functionality we always know the start and end time of all packets, so we can accurately calculate the duration of the media, and do A/V accurately.
Based on Part 2.

* Remember the byte offset of the first non-header ogg page, so when we (eventually) seek to time=0, we seek there instead and don't re-read the headers.
* Determine the end time of the media by finding the last page and getting the time from its granulepos.
* Determine the start time of the media by decoding the first audio and video pages, and taking the minimum of the two.
* Remember the presentation time of the first audio sample played. We can then add this to mAudioStream->GetPosition() to accurately determine the audio clock time.
* Store the granulepos of video frames in VideoData objects, rather than just their timestamps, so (in a later patch) we can calculate video frames' offset to their keyframes if necessary.
Based on Part 3.

* Refactor starting and stopping decode threads into a single function, so we can easily start/stop decode as necessary when seeking.
* Add a ResetDecode() method which will clear all state related to decoding. We need to reset the decode on every seek bisection.
* Add a monitor around the audio stream. This prevents us deleting the stream while we're feeding data to it. This can probably be removed when we refactor the audio infrastructure.
* Implement seeking to time=0. Press the Home key when a <video> is focused to test.
Based on Part 4.

* Add a SEEK_LOGGING #define which enables logging of bisection debugging info.
* Implements a bisection search visual-artifact free seeking for nsOggDecodeStateMachine.
* Does NOT do any tricks to optimize for network playback, goes for accuracy. So that means it will do two bisection operations; once to find the seek-target-frame, and another the target-frame's keyframe. Both bisection operations  could require up to 20 or so HTTP requests in their worst cases, though usually each requires about half of that.

I will implement more optimizations/tricks in later patches...
I think since you've made so many changes on top of the patch to bug 531340 it would be best if you just take over that bug and put your changes in there. I see no point in continuing development of 531340.
Ok, I'm happy to take over if that's your preference. Have you made any bug fixes since your most recent patch in bug 531340 which I would find useful?

It would be great if you can act as a reviewer on my patches (once they're ready), you're more experienced than I, and your advice would be invaluable.
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 531340
Target Milestone: mozilla1.9.3 → mozilla2.0
You need to log in before you can comment on or make changes to this bug.