[ogg-dev] Re: [theora-dev] Re: [Advocacy] Re: [Vorbis-dev] Proposal: An extension to rules all others

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Sun Apr 29 16:40:51 PDT 2007


On 4/30/07, Ralph Giles <giles at xiph.org> wrote:
> On Sun, Apr 29, 2007 at 10:01:58PM +1000, Silvia Pfeiffer wrote:
>
> > http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
>
> Thanks for putting that together. A few opinions:
>
> > it is required that random multitrack files contain a skeleton
> > track to identify all containing logical bitstreams
>
> I think this should be a best-practices recommendation, not a
> requirement (SHOULD, not MUST) in accord with the general design
> principle of making it hard to make non-compliant streams. There is
> a lot of software out there producing Ogg Theora streams without a
> Skeleton, for example. Likewise, RFC 3533 doesn't mention skeleton
> as a requirement.

I deliberately called for "random multitrack formats" and tried to
exclude ones that have a more specific definition such as Ogg Theora.
I put it as a requirement, though I really think that random
multitrack files don't have another option. But I do agree, it should
be "should" rather than "must" - I knew that'd stirr a few souls. :-)

> In practice the behaviour is the same: in the presense of unrecognized
> stream types, if there is no skeleton a muxer must throw up its hands,
> but playback is largely unaffected. I think it's better to be explicit
> about this than to say skeleton's required and leave it to the
> implementation to decide how hard it should try with streams which
> violate this.

Agreed - so maybe the recommendation is that authoring sw should
support skeleton while decoding software that aims to support random
multitrack ogg files really really should ("must"?) support the
decoding of skeleton?

Cheers,
Silvia.


More information about the ogg-dev mailing list