GNOME Bugzilla – Bug 616128
oggdemux: bad calculated granulepos
Last modified: 2011-05-30 10:54:32 UTC
Created attachment 159033 [details] [review] patch oggdemux calculates the granulepos values incorrectly for this stream: http://ia331209.us.archive.org/0/items/Patent_Absurdity/Patent_Absurdity_HQ_768kbit.ogv Instead of the expected values: 64, 65, 66, 67, 68, 69, 70, 71, the current oggdemux outputs 1, 2, 3, 4, 5, 6, 7, 71. These coincidentally translate to the same timestamps, so playback is correct, however, theoraparse and oggmux get confused if you attempt to remux the stream. If the stream didn't start at time=0, the first few frames would have the wrong timestamp, and likely be dropped since the incorrect timestamps would be outside the segment. So I don't think anything *bad* happens during playback. Patch attached. It's a bit invasive, so I question whether it's worth breaking a freeze for it.
Wonder if this also helps with any of the other ogg (theora) regressions/bugs.
You mean #612438? Sounds plausible.
Some additional testing revealed this patch is incomplete.
That file's gone, but this issue might be fixed by the last patch in https://bugzilla.gnome.org/show_bug.cgi?id=553244 (no need to wait for a granpos to know which encoding the granpos uses, as it can be known from the bitstream version).
Looks like it has been moved here: http://ia700307.us.archive.org/20/items/Patent_Absurdity/Patent_Absurdity_HQ_768kbit.ogv
Seems that this is fixed now, the offset/offset_end that is generated by oggdemux looks ok now.