[theora-dev] My issues with ogg and directshow...
Timothy B. Terriberry
tterribe at vt.edu
Mon May 10 17:55:36 PDT 2004
> 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
--- >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