[theora-dev] My issues with ogg and directshow...

[Andre Pang]

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 
> decisions.

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 
specific.

     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 
proper decoder.

     * 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 
bitstream data.

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 
can understand.

     * 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.

<p>
-- 
% 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.