[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 8:55 AM
Subject: Re: [theora-dev] My issues with ogg and directshow...

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

a) Bugs : Not much you can do about this except enourage people to rectify
them
b) Same codec different feeatures: User can specify their preference.
c) Same codec different outputs: Rectify the spec and invalidate the
incorrect ones.

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

Yes, that's a good point. But that assumes the spec is fixed for all
eternity.

I was not suggesting just go and change it, i was more trying to understand
what the rationale was in the first place !

> 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

As i mentioned... a tie goes to the longest knwon to the demuxer, not
necessarily the longest that may be in a muxed file created some time later.

> 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

Exactly my point, the mux only needs to know, the mux is the more comlpex
component, and the mux only occurs once.

> it into something "standard". Ogg mandates that this be done on the
> decode side for maximum flexibility. This only forces a codec to conform

I don't see how it's maximum flexibility, if all files were done this way
and part of an ogg header format, then all frameworks can utilise it.

I can't think of any audio codec that doesn't have a pcm sample rate and a
number of channels ?

Nor any video codec that doesn't have an initial frame size ?

I'm more of the opinion that be generic where it makes sense to be generic,
but be specific where it makes sense to be specific.

In specific cases... ie audio and video (which are also the most common
cases), why not be specific, in other cases be generic. If an audio or video
codec comes along that makes using the specific codec impossible, then it
will use the generic one.

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

If such a header format were part of the spec, then it would be across all
frameworks as that would be part of the required imlementation. OGM while
designed originally for directshow is now in widespread use and is also
imlemented on other frameworks, there is nothing about such a format that
precludes other frameworks from using it. Nor anything about it that forces
codecs to be muxed with it rather than the native format... There are files
out there with ogm/divx in one stream and native vorbis in the other.

>
> You want to impose restrictions on Ogg to fit the PARTICULAR media
> framework you're developing for, because it reduces your work. Which is

No, that's not true. If i wanted to reduce my work at all costs, i just
wouldn't do anything ! :) I'd go and work on another one of my projects. The
fact that i've written 4 decoders, 2 encoders and my own imlpementations of
a  mux and a demux library, would probably indicate that reducing my
workload is not really my priority.

If i wanted to make life easier for myself writing under directshow, i'd
just change the format to do what i wanted it to and say to hell with the
spec. But no-one benefits from that approach.

> 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 think that's a bit of a harsh judgement ! I'm not trying to impose or
force anyone to do anything, i 'm just putting out there the particular
problems that exist under the particular framework that i'm implementing
under, in the hope that some of these issues will at least allow future
decisions to be made with as much information abuot issues specific to this
platform as possible, and that hopefully issues that relate to this platform
get at least some weight, rather than just issues that occur under the
majority of developers preferred platform.

It cuts both ways, many of the decisions make implentation on my preferred
platform more difficult at the benefit of other platforms. I'm not saying
either way is right, i'm just offering up some issues that relate to this
platform.

If the decisions are made that don't suit my platform i'll just continue to
hack around them as i have been.

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