[vorbis] Peeling (was RE: streaming)

[John Ripley]

> From: Beni Cherniavsky [mailto:cben at users.sf.net]
> Sent: 26 September 2003 10:35
> To: vorbis at xiph.org
> Subject: Re: [vorbis] streaming
>
> - Vorbis is designed to allow "peeling": if you truncate packets, you
>   still get a legal Vorbis stream but with lower quality.  This should
>   allow very effecient streaming of multiple bitrates from the same
>   file (encoded at the highest bitrate).  This works but
>   unfortunately, the current encoder and peelers are not tuned well
>   enough - the quality you get from peeling is much lower than if you
>   you directly encoded at the same rate.  So usable peeling is
>   vapourware so far.

I'm not convinced about the Vorbis I spec lending itself well to peeling.
All the suggestions I've seen so far involve some kind of quality decision
at decode time where the trailer of the residue is thrown away. This is
expensive and I'd say it's the wrong way to go about it.

Peeling decisions need to be made at encode time, where we don't care about
expense (as much), and then inserted into the bitstream. The encoder, for
example, can say which sections of the residue should be discarded. Then at
"peel" time all you need to do is copy the bitstream minus those sections.

Trouble is, I only see two ways of doing this:

1) The encoder uses the first 4 passes to generate a "low quality" stream.
The next 4 passes are used to build this up to a "high" quality stream. An
ordinary decoder will naturally decode this as a high quality file. A
peeling just has to throw away residue passes 4-7. This requires no change
to the format, is completely compatible, but has an awful lot of coded zeros
which are essentially just padding.

2) Similar strategy to above, but insert info in the residue to indicate how
many codes should be kept for various quality versions. This is extremely
cheap because there's no padding involved but I can't see any way of
communicating this without changing the spec.

I'd definitely favour method 2. Bear in mind that my idea of peeling is
something that can be done at 100MB/sec (i.e on-the-fly as you stream it to
your portable over USB2/firewire), not at similar speeds to the original
encode. So, what does everyone actually have in mind for a peeling
implementation?

- John Ripley.
--- >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.