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

[Timothy B. Terriberry]

> You've never seen media player go "Contacting codec server" ? It is
> possible, just not everyone does it, and microsoft doesn't supply all
> possible codecs which is a problem hence the "Error downloading codec"
> message.

Sure, I've seen it... I've NEVER seen it actually work, even for codecs 
Microsoft wrote themselves! One of my friends who used to work at 
Microsoft told me that he seen it work on a machine inside their campus.

But it tries to get a codec even if the file is complete garbage, so 
long as it has the right extension. No distinction between "corrupt" and 
"unknown format" is made that I can see.

> That's easier said than done though, and it's not all that specific... i
> agree it works most of the time, but relying on people to do this isn't
> necessarily the best policy.

Perhaps not... but even Microsoft's specific "register FOURCC codes with 
us" is ignored by most people, who just start using a new FOURCC without 
bothering to tell anyone.

> There's always special cases, i'm not advocating getting rid of the varaible
> codec specific header, because it is obviously useful for such cases, but
> they are by and large the exception and not the rule.

The problem comes when people start to look at it as a rule, and ignore 
the exceptions. Then all your flexibility in design gets ignored in 
practice.

> If the generic is part of teh spec... then no-one has an excuse not to
> imlpement the generic as well. As i said it's not mutually exclusive.

Sure people have an excuse! "It's more work, and no one uses it anyway!" 
You're advocating creating a rigid, pre-defined standard header format, 
and then saying, "Oh yeah, AND your framework has to handle completely 
arbitrary headers, and we can't really tell you how to recognize them or 
what they might look like." Developers will say, "Ha, ha, very funny. I 
will just support this one header format and then not care, and everyone 
had better use that if they want to work with my software." With the way 
things currently are, that attitude is not possible. You have to support 
most of the generality of the format to get anything useful working at 
all. Some might argue that's a feature, not a bug.

> Not always... what if for some reason the shorter identifier's next bytes
> which are not part of the identifier happen to coincide with bytes that are
> ? For example if there is a \001vorbis and a \001vorbis2... the tie breaker
> is all good until vorbis's (\001vorbis) version number becomes 2, then it is
> indistinguishable.

It would actually have to become 50 (mod 256)---ASCII '2'---which isn't 
too likely. And whatever garbage data read as the number of channels and 
sampling rate would both have to be non-zero, and the framing bit at the 
end would have to be set.

Is it _possible_ to have a header for some other codec pass as a valid 
Vorbis header? Sure. Could it be done purely by accident, without 
malicious intent? I doubt it.

> No, no-one is forced to use the ogm header. But it may be an idea to
> document it's structure as people are going to use it regardless. The ogm
> header is no different to any other codecs header.

Sure, Ogg doesn't say you CAN'T use the OGM header. And other people 
have certainly implemented support for it in their demuxers. The main 
issue is that OGM is mostly used for embedding patented codecs in Ogg, 
and those are fairly uninteresting to Xiph, since we can't develop for 
them and can't distribute them. So no one in Xiph has needed what OGM 
provides.

> We've got some consesnsus on a remote identification system, so ignoring
> that part... but if you are going to have such a system that identifies
> based on the initial packet, then at least that must be enforced. As for the
> alphas, no big deal... but once in real use, it really needs to be enforced
> that identification must be possbile from the identification header.

Right. Changing the bitstream without bumping the version number is a 
big no-no once the Theora spec is official.

> That's a bug ! That's just as likely to happen as the wrong data being put
> in the native header.

Sure, YOU may think so, and I won't call you wrong. But other people 
happily write MPEG-4 specific code to scan the VOL header and override 
the aspect ratio in the AVI header with the one found there, and tout it 
as a "feature". If someone puts wrong data in the native header, at 
least it's wrong for everyone, which means it's much more likely to get 
treated as a bug.

Another issue that crops up is when the standardized header is MORE 
flexible than the native format is capable of. VP3, for example, didn't 
really support non-multiple of 16 frame sizes, but that didn't stop 
people from creating such streams in Quicktime containers, and the 
result had "issues" by all reports.

> You are right it's not perfect. But the user can always deregeister filters
> that don't play ball.

Right, because I know exactly where the "deregister annoying filter" GUI 
is. Actually, I do---it's in regedt32---but my mom doesn't.

> Well, we'd all love for everything to be perfect first time round... in
> reality it's rarely the case. All i'm saying is if the spec is being upped
> in such a way to make breaking changes, why not use the opportunity to make
> other changes that have arisen since the original spec which couldn't be
> done becuase they would break exisitnig implementations.

Well, you can certainly talk to Monty about it, and Jean-Marc and the 
FLAC guys. I wouldn't hold out hope for getting a WAVEFORMATEX in the 
header, but they might be able to come to some consensus.

> But still something has to be done to use these codecs... and the most valid
> choice is currently ogm. Otherwise everyone is going to have their own way
> to put mpeg into ogg and that's how you end up with tons of files which to
> the letter of the spec are conformant (they all create their own magic
> header), but differing implementations either will/won't or partially play
> them.

Hopefully they'll all have unique codec identification headers!

> But why make the "I give up" choice even a possibiltiy when you can factor
> that into the initial decision making process where possible. In order for
> anything to gain popularity and widespread use across multiple platforms
> compromises to various things will always have to be made to accomodate the
> conventions and quirks of that platform.

Because sometimes you aren't designing things for wide-spread use across 
multiple platforms. Nothing says you can't embed things for SPECIFIC 
platforms with a very narrow use that solve your particular problem into 
an Ogg stream (again GPS or NAV data is a reasonable example: while it's 
POSSIBLE to render it as an overlay on a video stream in DirectShow like 
I suggested before, it may not be worth the original developer's time to 
design such a filter, and then "I give up" is okay; there isn't anything 
useful the framework can do with that data by default).

> Now that's not me trying to convince anyone that you should all do it the
> windows way, far from it. Just something to think about.

Well, don't assume that it's just Windows frameworks that have a hard 
time dealing with Ogg. The Ogg abstraction imposes a different 
container/codec separation than pretty much any existing format, and all 
the Unix media frameworks that built up around "hack up minimal support 
these formats" (usually AVI/MPEG) have had some headaches with 
supporting Ogg. The main difference is that there they have the freedom 
to change the framework, while with DirectShow we do not.

We can still define our own extensions to the DirectShow framework that 
support the richer codec/container interaction of the Ogg family, where 
"ask the codec" is the default answer for lots of muxer questions. It's 
like "embrace and extend", but in reverse.

> Problem is, how does the demux know which servers to contact ? That is the
> benefit of a single point of contact. Unless you embed the host name where
> the codec is in the header in some specific way, you have no way to know who
> you should be asking. But that's back to the original problem.

How does Windows Media Player know? I've certainly never told it where 
to get codecs from (though given its success at that, that's not 
necessarily a good thing). Either set something up on xiph.org that 
everyone can use and hardcode that, or make it configurable and hope 
someone somewhere makes something usable (or both!). I've already 
mentioned the limitations the first choice imposes for patented codecs.
--- >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.