GNOME Bugzilla – Bug 344013
[oggdemux] use parsers to suck less
Last modified: 2009-11-21 20:13:47 UTC
Oggdemux currently has several issues: * it doesn't timestamp outgoing buffers properly * its seeking algorithm is broken too This is mainly due to the fact that the demuxer doesn't use parsers to figure out timestamps and keyframe position. OggDemux should be rewritten using parsers internally to: _ output properly timestamped buffers _ figure out needed keyframe granulepos for a given position in time The currently available parsers are: _ vorbisparse _ theoraparse _ ogmaudioparse (for application/x-ogm-audio streams) _ ogmvideoparse (for application/x-ogm-video streams) _ ogmtextparse (for application/x-ogm-text streams) The parsers which need creating are: _ speexparse , for audio/x-speex streams _ diracparse, for video/x-dirac streams _ .... These parsers should be able to do the following: _ be able to handle "convert" queries on their sinkpad. the DEFAULT format on their sinkpad being the granulepos. This will allow oggdemux to query for granulepos<->time conversions. _ be able to handle a custom query "needed-granulepos" on its sinkpad which returns the needed granulepos to decoded the requested position in a given format. This allows oggdemux to know which is the most optimal position to start outputting from. _ properly timestamp outgoing buffers.
The custom query is needed, in fact, for correctness, not just for optimality - this would be used by video format parsers to direct oggdemux to seek to prior to the last keyframe (which we can't do right now). An increase in precision is, of course, a significant additional advantage. Note that the existing parsers don't yet implement all of this, it'll need adding.
FWIW, I've got some code for a generic ogg granulepos mapper locally (where the mappings are hardcoded for the various formats), but the problem I've run into is - at least for audio - that you need to actually decode in order to know the duration of a chunk and thus the timestamp of the beginning of the chunk (since the granulepos refers to the last sample within the chunk). Possibly it is possible to extract this information from vorbis/speex without decoding though, I haven't looked into this yet. Do our parsers handle this correctly?
(In reply to comment #2) > FWIW, I've got some code for a generic ogg granulepos mapper locally (where the > mappings are hardcoded for the various formats), This is why having each parser handle correctly the granulepos mapping is a good idea is that we can put that 'hardcoded' mapping within each parser. And if a new codec for ogg appears (like dirac) we can easily create a new parser without having to modify oggdemux. > but the problem I've run into > is - at least for audio - that you need to actually decode in order to know the > duration of a chunk and thus the timestamp of the beginning of the chunk (since > the granulepos refers to the last sample within the chunk). Possibly it is > possible to extract this information from vorbis/speex without decoding though, > I haven't looked into this yet. Decoding some audio codecs (if we really can't do otherwise) would be acceptable IMHO.
Tim - the problem is that there's no such thing as a 'generic ogg granulepos mapper' - it's entirely codec-specific. Hence the proposal to use parsers for specific formats (possibly falling back to a full-blown decoder in the unfortunate event of us not having a parser). For vorbis, specifically, it's pretty easy to extract the duration without doing a full decode - but you need a fully-decoded setup header, which is complex to do (of course, we can just link to libvorbis if we need to). For speex, I think the calculations are trivial.
Created attachment 67328 [details] [review] granule mapper thingy (work-in-progress) > Tim - the problem is that there's no such thing as a 'generic ogg granulepos > mapper' - it's entirely codec-specific. Hence the proposal to use parsers for > specific formats (possibly falling back to a full-blown decoder in the > unfortunate event of us not having a parser). By 'generic ogg granulepos mapper' I meant 'something where we bundle/hardcode all known granulepos mappings'. oggdemux should ideally be able to output packets with correct timestamps without the help of additional elements or libraries IMHO, just like any other demuxer. See attached patch for what I started playing with (to illustrate what I mean). > For vorbis, specifically, it's pretty easy to extract the duration without > doing a full decode - but you need a fully-decoded setup header, which is > complex to do (of course, we can just link to libvorbis if we need to). > > For speex, I think the calculations are trivial. Cool, didn't know that.
Created attachment 123381 [details] [review] Updated patch I updated the patch to recent CVS (ahem, git) and added Dirac support as well as duration queries. The latter is to fix a bug where ogg duration is underestimated by a frame in theora, leading to clipping of the last frame.
What's the state of this bug? Do we still want to do something like this?
Created attachment 142010 [details] [review] updated patch Merged patch with some of my current work and updated for current git. Patch changes: - eliminates the internal decoder inside oggdemux - adds code to convert granulepos to timestamps - adds code to calculate granules for ogg packets that don't have valid granulepos values - adds code to calculate durations of ogg packets - implements the above for theora, vorbis, dirac, speex, celt, flac, ogm With this patch, oggdemux can independently (without queries or internal elements) calculate chain duration exactly (it has never been able to do this correctly before) and fixes #568014. With minor additional work, oggdemux could add timestamps and durations to outgoing buffers, estimate the number of packets to seek backward to get to a key frame, Known regressions: - calculating vorbis durations is only a good estimate - I may have broken skeleton support
commit 72edd1467bcb5040d1e89e782fc46059743e8646 Author: David Schleef <ds@schleef.org> Date: Sat Aug 29 10:51:48 2009 -0700 ogg: Add ogg stream parsing Adds code that parses headers of various formats encapsulated in Ogg in order to calculate timestamps and durations of each buffer. Removes the creation of helper decoder elements to do this calculation via conversion queries. Fixes: #344013, #568014.