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

[illiminable]

----- Original Message -----
From: "Timothy B. Terriberry" <tterribe at vt.edu>
To: <theora-dev at xiph.org>
Sent: Tuesday, May 11, 2004 1:56 PM
Subject: Re: [theora-dev] My issues with ogg and directshow...

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

Granted it doesn't work all the time, mostly because the codecs don't bother
to get registered, and majority of ones that do register end up being
shipped with windows.

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

That's their own fault ! They can't expect it to work if they don't register
it !

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

But in this case there is already precedent for generic headers as the 4
core codecs use this format.

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

Doesn't that say something ! .

Not all frameworks have the luxury of having a whole swag of global
variables they can just call at will, create special cases etc.

> 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

It is still possible... i could have just written filters to only accept ogm
if i had wanted. But realistically if i want any sort of conformance i have
to imlement the other headers.

I'm not sure making something incredibly awkard is a way to encourage people
to write conformant implementations... though it's an interesting strategy !

Though the first two implementations of vorbis in directshow, one chose to
create ogm and the second matroska (though i don't know what the motivations
of this matroska decision was, but either way they chose not to use ogg for
whaetver reasons). That's not to say that it can't be done, nor that ogg is
deficient in some way. But it probably indicates the kind of frustration
people have experienced doing this before... which i can certainly attest
to. I have a feeling that people that don't have to work in such rigid
frameworks, don't really appreciate the how frustrating it is ! That said
i'm always up for a challenge otherwise i would have given up by now. But
it's easy for people to say "this is the best way", and "you can just do
this" when they haven't actually tried it.

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

Yes, my mistake in the maths... but still possible.

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

But you know what they say about assumptions !

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

That remove annoying filter GUI is gSpot, graphedit, codecspy, avicodec and
probably others. Though it is a valid point it's not the most intuitive
thing in the world... but i mean realistically, if you don't really
understand this stuff you are probably unlikely to understnd the all the
options that ffdshow offers you either.

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

It's some microsoft site, can't think what it is off=hand but it's hardcoded
into media player. Hmmm... perhaps on my server is an idea then. because it
will inevitably be the obscure or patented codecs that will need
identification as the common free xiph codecs would generally be hard coded
in.

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

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