[vorbis] Bitrate stripping?

[Arc Riley]

On Thu, Jan 01, 2004 at 01:21:24AM -0600, Graham Mitchell wrote:
> 
> * It's still possible to peel current Vorbis files, but not very well, and no 
> peeler exists (except for Segher's "April Fool's" proof-of-concept code).

Where is this proof-of-concept code?  I thought it was vaporware?

> Once peeling is working out of the box, people will start using it (and 
> loving it, I suspect), but for now there's not enough clamor for it to move 
> to the top of the TODO list of anyone capable.

I've been working to get "alternative bitrate" support in IceT 
(the IceShare <-> IceTracker protocol, http://wiki.xiph.org/IceT ).
  
Basically there's three ways for implementing this;

first there's just "alternative live-swappable pages", that is, an 
alternative stream with the same SerialNo where any page which has the 
same pageno and granulepos is a possible switching point to an 
alternative bitrate, so if an IceShare peer is streaming the content and 
they can't keep up they could get switched to this lower bitrate on the 
fly.  Obviously encoders for this will have to ensure that continued 
pages don't have matching granulepos to alternative bitrates.

This could be implemented with either bitrate peeling, where every page 
is intentionally flushed to have the same granulepos and thus no page 
contains continued packets, or it could be implemented through parellel 
encoders which use the same SerialNo and also intentionally flush.  I 
think the second would yield better quality, but would also consume more 
CPU where bitrate peeling (from what I've read) would be much faster.

The third way to implement this would be with alternative encoding 
values, where the granulerate of the streams would not match.  These 
would only be switched between bitstream chains or at the beginning of 
the transfer.  

So conceivably you could have 16kbps and 24kbps streams at 22050khz mono 
and 56kbps and 128kbps at 44100 stereo.  When a client connects it 
should tell the tracker what it's maximum speed is, where it choose 
between the lower two or the higher two, then those are switched 
interchangably depending on current bandwidth constraints.  Those 
streams could intentionally include periodic bitstream breaks to new 
chained bitstreams, so for instance a 56k listener could use that point 
to switch to a 24kbps stream or vice versa. 

For trial implementation of this I'd really like to get ahold of any 
bitrate peeling code that already exists, I might even be interested in 
continuing it's development at some future point.
--- >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.