Last Comment Bug 613699 - nsOggReader should always capture Theora granulepos
: nsOggReader should always capture Theora granulepos
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 650994
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-19 19:22 PST by Chris Pearce (:cpearce)
Modified: 2011-05-08 01:07 PDT (History)
0 users
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Chris Pearce (:cpearce) 2010-11-19 19:22:32 PST
I discovered a bug in OggIndex's decoder, and the same bug exists in nsOggReader.

When nsOggReader starts decoding Theora, it finds the first packet with a granulepos, and we increment that granulepos every time we read a subsequent packet, and use that as the packet's granulepos. If a packet already has a granulepos (because it's the last packet in the page) we overwrite the running granulepos with the incoming granulepos, since I found they can be different when there are gaps in the media.

This is wrong, it produces inconsistent results. When we seek to the "gap" page and capture granulepos there, we'll assign granulepos to the packets different to how we assign them when decoding the gap page from the previous granulepos capture.

In the "seek to the gap" case, we (correctly) assume the gap is before the first packet on the page, whereas with the "decoding from previous capture" case we'll assume the gap is before the last packet in the page.

ffmpeg output files with these gaps sometimes.

When we decode Theora, we should always read ahead until the packet with a non -1 granulepos, and propagate that backwards to assign granulepos to packets. We already have this code, we should just always use it and not try to keep a running granulepos for Theora.
Comment 1 Chris Pearce (:cpearce) 2011-05-08 01:07:15 PDT
Fixed by bug 650994.

Note You need to log in before you can comment on or make changes to this bug.