[vorbis] Rgenerating headers

[Michael Smith]

At 12:17 AM 22/11/2002 +0100, you wrote:
>Hi Michael
>
>Thx for the answer.
>
> > >So, back to my question - is there any reason why you shouldn't
> > >be able to completely regenerate the header packets/frames
> > >from what I have outlined ?
> > Unfortunately, yes.
>
>Why *unfortunately* ?

Because it'd be really useful to be able to do as you suggested,
so not being able to is unfortunate.

<p>>
> > This requires that the _client_ have the encoder
> > as well. Worse, it requires that the client have _exactly_ the same
> > version of the encoder as the server.
>
>Please define "have _exactly_ the same version".
>
>Would Vorbis 1.0 and Vorbis 1.0rc3 have been two different
>versions in this context ?

Yes, much too different for this to work.

>
>Both Vorbis 1.0 and Vorbis 1.0rc3 identify them selves as Vorbis version 0.
>

Right. That's the stream format revision (it hasn't been revised, hence
it's still at 0). There's no (decoder) incompatibility - rc3 is perfectly
capable of decoding 1.0-encoded streams.

>If Vorbis 1.0 and Vorbis 1.0rc3 would have been different
>versions in the context we are talking about, then how
>does a program identify which version the library is ?

A player needs only support the stream version (currently, vorbis
only has stream version 0, as you've seen). The specification
lays out how to decode that format.

Your suggestion is to drop the tertiary header (which defines
the particular mappings and codebooks used for vorbis, which
the specification leaves very flexible - this is the design
tradeoff of flexibility vs. large header), and to list the
encoding parameters that the encoder used to generate this
header. That works if (and only if) the decoder has access
to the exact encoder used to generate the stream. 

Obviously enough, most players don't have an encoder. Those
that do don't neccesarily have any particular encoder (though
there aren't any independent encoder implementations yet, the
libvorbis libraries are flexible enough that incompatible streams
(i.e. streams with mismatched tertiary headers) are easy to create.

So, since you can't (in most players, and you can't EVER guarantee
it) limit the headers produced, you can't just provide some subset
of the information.

That said, it has been suggested that we specify a different form
of vorbis (perhaps a "low-complexity profile") which is much more
limited, and in that context an approach like you suggest may well
be possible. That, however, vastly decreases the power of the
vorbis format, and isn't really appropriate for general purpose
streaming.

Michael

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.