ogg dev - Oct 2007 - Re: Peer review draft for the new

"Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
...
> First though let me start a discussion on skeleton here, which is
> fundamental to this rfc and for which I'd like to get more input from
> everyone.
>
> I think, "application/ogg" makes not much sense without having
> skeleton inside the ogg file. Half the reason for having a generic,
> free-ended encapsulation format is to have headers that can specify
> what is within such that any decoder has a chance to assess whether it
> will be able to do something sensible with it. So, I would like to
> actually prescribe the use of skeleton in application/ogg files.
...
> Just to be clear - I would not prescribe skeleton for audio/ogg files
> with ogg extension, which are clearly the old vorbis 1 files only. Or
> to spx files, which are speex files under audio/ogg. But "SHOULD"
> should work for audio/ogg with oga extensions without getting anyone
> into trouble.
>
> Opinions anyone?
I am an outsider here, but sometimes that helps.

When I first read the Ogg Skeleton stuff, my
reaction was "you mean the Ogg container
doesn't have this built in?"  I would suggest
some general principles:

1.  Ogg Skeleton should be as mandatory as
    possible without breaking significant numbers
    of existing files in the wild.

    There are obviously loads of Ogg Vorbis out
    there.  If there are only a few Ogg speex files
    in the wild then they are better handled by a
    tool to automatically convert.

2.  Following on from 1, a tool which inputs an
    Ogg containier with one or more streams, and
    outputs a new Ogg container with the same
    streams plus an Ogg Skeleton stream stuffed
    in front would be very helpful.  The tool could
    also select and create the appropriate file
    extension.

3.  You can't discuss Ogg contents without also
    discussing the minimum requirements for Ogg
    players.  I would suggest it is time to bite the
    bullet and specify that players must recognize
    and decode an Ogg Skeleton stream if
    present.

    At the moment, Ogg Skeleton can break
    existing players.  This has got to change if
    Xiph is to move forward.  Existing player
    developers will need support to do this, and
    you will lose a few who can't/wont do it, but it
    has to be done.  Discussion should be about
    "when" and "how", not "if".

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese@stanfordalumni.org
Web: http://members.tripod.com/martin_leese/

> 1.  Ogg Skeleton should be as mandatory as
>     possible without breaking significant numbers
>     of existing files in the wild.
> 
>     There are obviously loads of Ogg Vorbis out
>     there.  If there are only a few Ogg speex files
>     in the wild then they are better handled by a
>     tool to automatically convert.
It's hard to tell how many Ogg/Speex (.spx) files there are out there, 
but I see no reason to break them because of Skeleton. Also, Speex files 
are probably the ones for which Skeleton is the least relevant, simply 
because they tend to be single-codec files. If you can afford to put the 
bandwidth required for Theora (or any video codec), you can afford the 
quality/bitrate of Vorbis. Whether Skeleton should now be included by 
default for Speex is still an open question, though. I would tend to say 
yes once most of the decoders implement it properly.
>     At the moment, Ogg Skeleton can break
>     existing players.  This has got to change if
>     Xiph is to move forward.  Existing player
>     developers will need support to do this, and
>     you will lose a few who can't/wont do it, but it
>     has to be done.  Discussion should be about
>     "when" and "how", not "if".
Well, this is definitely not a decision to take lightly -- at least when 
it comes to Vorbis-only files.

	Jean-Marc

Martin Leese wrote:
> "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
> ...
>> First though let me start a discussion on skeleton here, which is
>> fundamental to this rfc and for which I'd like to get more input
from
>> everyone.
>>
>> I think, "application/ogg" makes not much sense without
having
>> skeleton inside the ogg file. Half the reason for having a generic,
>> free-ended encapsulation format is to have headers that can specify
>> what is within such that any decoder has a chance to assess whether it
>> will be able to do something sensible with it. So, I would like to
>> actually prescribe the use of skeleton in application/ogg files.
<snip: not for .spx, .ogg>
> 
> I am an outsider here, but sometimes that helps.
> 
> 
> 1.  Ogg Skeleton should be as mandatory as
>     possible without breaking significant numbers
>     of existing files in the wild.
> 
>     There are obviously loads of Ogg Vorbis out
>     there.  If there are only a few Ogg speex files
>     in the wild then they are better handled by a
>     tool to automatically convert.
> 
I think the Speex thing is a detail.  However as .spx
and .ogg are legacy provisions my opinion is changing
.spx would be contrary to that.
> 2.  Following on from 1, a tool which inputs an
>     Ogg containier with one or more streams, and
>     outputs a new Ogg container with the same
>     streams plus an Ogg Skeleton stream stuffed
>     in front would be very helpful.  The tool could
>     also select and create the appropriate file
>     extension.
> 
This is pretty easy to write using liboggz from svn
and Tahseen's skeleton creating functions (in his
vorbis-tools branch).  I just haven't found an
afternoon to do it yet.
> 3.  You can't discuss Ogg contents without also
>     discussing the minimum requirements for Ogg
>     players.  I would suggest it is time to bite the
>     bullet and specify that players must recognize
>     and decode an Ogg Skeleton stream if
>     present.
> 
>     At the moment, Ogg Skeleton can break
>     existing players.  This has got to change if
>     Xiph is to move forward.  Existing player
>     developers will need support to do this, and
>     you will lose a few who can't/wont do it, but it
>     has to be done.  Discussion should be about
>     "when" and "how", not "if".
> 
I've thought since the 'clean-break' realisation
occurred for application/ogg audio/ogg and video/ogg
that the things you and Silvia have suggested were
an implicit part of this change.  The only one I'd
raise an eyebrow at is players must decode Skeleton
rather than simply tolerate its presence; Particularly
since I'm not sure what the practical requirements
would be.  (And applications shouldn't---in the plain
English sense---trust the Skeleton header for security
reasons.  It can only be a guide.)

-- 
imalone

-- 
imalone

-- 
imalone