[Vorbis-dev] Re: [ogg-dev] Peer review draft for the new media types/file extensions

[Ian Malone]

On 03/10/2007, Ivo Emanuel Gonçalves <justivo at gmail.com> wrote:
> On 10/1/07, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> > ok, so instead of editing it directly, I shall make a list of the
> > things I'd like to change here
>
> Thank you.  It is much appreciated.
>

> > More generally, I would like to suggest for audio/ogg with oga and
> > video/ogg with ogv extensions that skeleton SHOULD be used for the
> > same simple reason of being able to identify the codecs inside.
>
> This I'm not so sure.  AFAIK, there's still no official or
> non-official tools out there (except a few simple SVN projects) that
> deal with Skeleton.  There's no Skeleton RFC either.  We have to push
> for both urgently.
>

Really this is the point; we want to be able to start using
Skeleton and other new things.  That can't happen, and tools
for working with them wont be widespread, until Skeleton
starts to be widespread.  But in the current situation you
can't add Skeleton and expect the stream to work.  This is
why .ogg and .spx are being preserved for backward
compatibility.

> >   - third/fourth paragraph: I don't think we should exclude executable
> > content in Ogg by design. I think this may well be interesting in
> > future, so we should not unnecessarily restrict ourselves. We should
> > however say that receivers should be careful and validate the origin
> > of executable content inside Ogg before actually executing it.
>
> Perhaps.  More opinions, please?
>

Means there's something to write in the security section.
I think technically it's already been done anyway; I remember
someone mentioning a plugin (for XMMS?) that would run a
command stored in a particular comment tag, so a security
mention is warranted anyway.

>
> >   - under "published specifications" add the skeleton specification reference
>
> That's one problem: there isn't any, but a wiki page.  Whoever knows
> Skeleton in and out needs to write an Internet Draft ASAP.  Really
> ASAP.
>

The wiki page is only a summary of section 4 of the Annodex
bitstream specification:
<http://annodex.net/TR/draft-pfeiffer-annodex-02.html#anchor6>

> >   - also: I have a question about the mac file type code - does it
> > make sense to call it "OggS" everywhere?
>
> Paging Monty.  I followed RFC3534's lead here.
>

Not a mac person, but I assume these are analogous to
file extensions on Windows, therefore some version of
the .xxx already hammered out for Windows?

> >   - delete "Note that timed text is visually presented and is
> > considered to be visual material." That's not really true - you can
> > e.g. have timed text which is just metadata in use for search engines.
> > And it's irrelevant anyway.
>
> It's not irrelevant.  It makes an actual distinction between video/ogg
> and audio/ogg.  Also, timed text are lyrics or subtitles, which is a
> visual thing.  The search engine case you describe would be metadata,
> which usually is not visual.
>

This would mean that the inclusion of lyrics in a pop song
would make it 'video'.  You can search for song lyrics online;
timed text can be metadata.

> Better wording needed in the document, perhaps?
>
> >   - replace "MAY" with "SHOULD" because audio/ogg should have skeleton
>
> I explained on an earlier message in this thread why I think that's a bad idea.
>
> > might as well
> > encourage ppl to create demuxing functionality
>
> I know what you mean, but that would be wishful thinking, similar to
> the W3C's XHTML, which went nowhere.  Developers are used to
> MPEG-4/MP3-style solutions.  Simple solutions.
>
> If we were more mainstream, this would be a logical demand we could
> do, but considering our situation, the less we complicate things to
> developers, the better we will be.  Work around this issue somehow,
> please.
>

I think this is a central part of the new approach. Demuxing is
needed and is not very difficult[1].  The situation will be /more/
complicated if there's one approach for .oga, another for .ogv
and a third for .ogx, which is what this looks like otherwise.
If not addressed, someone else will be writing another RFC
seven years from now to try to push out another tiny
increment and they will have to push out a new set of
types/extensions to avoid overlapping the old ones, assuming
Ogg is still around.

[1] And really if you don't do it then you need to do lots of
   replication to handle ogg/audio which is encapsulated FLAC,
   Vorbis, Speex or PCM.

-- 
imalone