[theora-dev] My issues with ogg and directshow...
ozone at algorithm.com.au
Mon May 10 22:42:01 PDT 2004
On 11/05/2004, at 10:55 AM, Timothy B. Terriberry wrote:
> Which just means that ffdshow has done the work instead of you. Either
> on the encode side or the decode side, someone has figured out how to
> take the codec's native way of describing these parameters and mapping
> it into something "standard". Ogg mandates that this be done on the
> decode side for maximum flexibility. This only forces a codec to
> conform to the restrictions of a given media framework when being used
> by that framework; it does NOT force it to obey those restrictions
> just to be stored in an Ogg container---and thus across ALL media
> frameworks, regardless of their capabilities.
> You want to impose restrictions on Ogg to fit the PARTICULAR media
> framework you're developing for, because it reduces your work. Which
> is nice for you, but not necessarily for everyone else, including for
> things that may not even exist yet which will have to live with your
I see two different philosophies at play here:
* We want to make Ogg a very generic container that can store just
about anything, from audio to GPS data. As well as being a nice
property to boast about, this also is a bit more future-proof than
having Ogg being more specific: I think your example about the
designers of VfW and AVI not giving enough flexibility to allow for
B-frames and VBR codecs show that there's a real danger with being too
In this approach, every codec has to know how to be embedded in
Ogg, and more importantly, the demuxer must have domain-specific
knowledge of each codec which can be embedded in Ogg, so it can give
enough setup info to the media framework which can in turn spawn the
* Alternatively, you can put in a standardised header at the start
of (say) the logical bitstream with all the required setup info (for
video: fourcc, width/height, or for audio: sample rate, channels,
etc.). The demux can just rip the setup info out of the header instead
of requiring knowledge of the codecs in the bitstream.
The downside of this approach is that Ogg is no longer as generic
as it was: you limit yourself to video, audio, or other types where you
can abstract the setup info into a header package before the actual
The point of this message was to try to sum up the good and bad points
about each approach: I acknowledge that it is unwise to change the Ogg
bitstream format, and I don't propose that at all. However, I do have
a couple of observations about the latter (standardised approach):
* I think Zen's point stands that you do not have to use the
standardised header: if you've defined a standardised header for video
(which e.g. OGM does), you just don't use it if you want to store GPS
data in your Ogg container or whatnot. If you do use a standardised
header such as OGM, then you simply give the demuxer another codec it
* I find it interesting that there are now two standards (Annodex's
AnxData header and Matroska) and one pseudo-standard (OGM) which have
emerged precisely because of this problem: it's obviously something
that some people couldn't live with and had to either layer on top of
Ogg (in the case of Annodex and OGM) or went their own path and made an
alternative encapsulation (in the case of Matroska).
* The major advocates I've seen arguing for the more specific
approach are usually people who have tried implementing Ogg in
entrenched frameworks (Zen with DirectShow, Annodex with requirements
for codec-independent encapsulation, the Matroska guys with Unix media
players). I'm not saying this to divide people between white and
black, I just find that it's a result of people who have had to fight
against implementation problems in frustration.
Again, I don't propose changing Ogg at all to "fix" this problem (which
is not fair, since it's not really part of its original goals); I'm
just commenting on it to try and inject more perspective into the
discussion. Full disclaimer: I am part of the Annodex project.
% Andre Pang : trust.in.love.to.save
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Theora-dev