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

[Timothy B. Terriberry]

> The big problem with doing it robustly is the variable codec identifier...
> Because it makes the outcome dependant on the order in which the libraries
> are called in the case where one codec identifier is prefixed by another.

Hos is that any different than the current situation where multiple 
codec implementations can all decode the same FOURCC? The result is 
order-dependent there, too. Even if you had some UNIQUE identifier of 
the codec a file was encoded with, that doesn't prevent you from having 
multiple decoder implementations, all ostensibly for the same codec. 
XviD, ffdshow, DivX, and 3ivx all claim to be able to decode MPEG4 
content, but they are certainly not feature-equivalent.

> What i don't see is why it woulld be any great disadvantage to for example
> say that codec identifiers must be null terminated and that codec
> identifiers can't contain the null character. This eliminates the
> namespacing problem and gaurantees that all unique identifiers can be
> determined to be unique, rather than the current system "that should work
> most of the time".

Because the codecs have already been in use for some time with the 
current scheme, are supported by hardware implementations, and are used 
in large bodies of existing encoded content.

Your null-terminated scheme doesn't buy you anything over simply 
specifying a length along with the identifier location when registering 
the decoder, with a "tie goes to the longest" rule. Even so, all 
identifiers are currently unique already. There's no real reason to 
expect that this will not continue to be the case.

> In contrast, using the fixed header of ogm video, with less code than any of
> the other streams, i can embed any video format recognised by ffdshow... i

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