[vorbis-dev] Re: [theora-dev] Re: RFC3533

[Arc]

On Wed, May 21, 2003 at 12:34:37PM +1000, Silvia.Pfeiffer at csiro.au wrote:
> >However, according to RFC 3533:
> >
> >   "In grouping, all bos pages of all logical bitstreams MUST appear
> >   together at the beginning of the Ogg bitstream."
> >
> >This makes it unusable for long-lived physical bitstreams carrying
> >multiple logical bitsreams which appear and disappear over its lifetime.
> >It seams to me that "Grouping" and "Chaining" are, from the wrapper's
> >point of view, just two manifestations of the same multiplexing
> >mechanism with "Chaining" merely being the special case of "Grouping"
> >where the logical bitstreams happen to appear sequentially.
> >
> >(There may well be sequencing requirements imposed by the client codecs,
> >but this should be transparent to Ogg.)
> >
> >With this background, my question is this:  Is there really any technical
> >reason why the two types of multiplexing should be distinguished Ogg
> >standard (except to provide a common nomenclature for client codecs),
> >and, more particularly, why should all logical bitstreams be restricted
> >to either starting (having their bos pages appear) either all at the
> >start of the physical bitstream or all strictly sequentially within it?

I recall speaking to Monty about this a few months ago.. the reason this
is done is to simplify Ogg decoding for players, which lowers the
barrier of entry for (ie) portable players.  By loading all the codecs
at once you don't need to run checks through the length of the stream
for new logical bitstreams, and as Sylvia pointed out, don't have to
load a codec handler mid-stream.

Correct me if I'm wrong, but I also recall Monty immediatly following
this by suggesting this is a temporary restriction and is likely to be
removed in the future.

In any case, since your application has no need to remain compatable
with media players (does it?), and also correct me if I'm wrong but
most vorbis players won't even play a stream unless its vorbis-only, so
I see no reason you couldn't use libogg and the ogg container format..
tho it'd be a good idea to use a different extension, or identify it as
something other than application/ogg, simply because this would really
confuse client software expecting it to me a audio file.

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20030521/45afeec3/part.pgp