[ogg-dev] oggfile, skeleton and vorbis tools

[Ian Malone]

On 3/10/06, illiminable <ogg at illiminable.com> wrote:
>
> ----- Original Message -----
> From: "Ian Malone" <ibmalone at gmail.com>
> To: "ogg-dev" <ogg-dev at xiph.org>
> Sent: Friday, March 10, 2006 5:24 PM
> Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools
>
>
> >> This is something we might want to extend skeleton to support, i know
> >> we've talked about this kind of thing before. So that skeleton can
> >> provide some kind of mapping as to how the various streams relate to each
> >> other.
> >>
> >
> > You need player support to be able to collect the options and present
> > them to the user.  Without skeleton and something like a fully capable
> > oggfile you can't do it, as you've pointed out you can mix Speex and
> > Vorbis. (I recently, accidently, had a file which contained mp3 and
> > Vorbis.  Obviously no Xiph tool will ever handle or produce that.)  So,
> > with the aim that it's intended for simple audio only players (probably
> > ones already using it, or operating with limited resources), what
> > should vorbisfile be capable of?
>
> Certainly player support is needed, and there needs to be someway to get
> information about track correlation, probably skeleton. From my projects
> perspective, oggfile is not really required. Between directshow's framework
> and my filters, i've already implemented all the capability oggfile might
> offer, and i'd say the same goes for gstreamer and vlc. I believe my
> directshow filters would be fine with ogm/mp3+vorbis and i'm fairly sure vlc
> would be fine with it.

Apologies, I wasn't clear enough, certainly the DirectShow filters, vlc,
xine etc. are 'like a fully capable oggfile' in this respect.  What I meant
was versus a single codec aimed API like vorbisfile which is meant to
allow applications to add support for Ogg/Vorbis simply.  With the
increasing number of media frameworks available it will eventually be
obsolete, Oggfile or no Oggfile.

And mentioning player support; it's in the context that the vorbisfile API
cant really communicate this with the player very well.

> Also, as of 0.70 the demuxer and codecs are completely decoupled. In other
> words, it's possible for a third party to add a new stream, implement the
> required interfaces and distribute a directshow decode filter, and it will
> just work without any changes needed from my end.
>

Nice feature.

> I'd say at this stage, it's probably fine for vorbisfile to dump anything
> non-vorbis, and play only the first vorbis stream it sees, ignoring the
> rest. Making it much more complicated than that you might as well implement
> a fully functional oggfile.
>

That's the conclusion I came to; one thing at a time.

--
imalone