[Theora-dev] Bitrate Adaption

[Dave Baker]

Hi,

Sorry for the delay in replying but thanks for the info. That's really helpful. I think for now I'll look at adapting the number of blocks coded / quantisation levels. I'll let you know if I get anywhere!

Wrong list, I know, but I assume it would be possible to do a same thing with vorbis just by adapting quantisation levels?

Thanks for your help anyway.


Dave



At Sat, 5 Mar 2005 10:30:43 -0800, Ralph Giles wrote:
> On Thu, Mar 03, 2005 at 02:17:32PM -0000, Dave Baker wrote:
> 
> > I've been reading through the Theora format spec and API reference trying to find an answer to this but haven't come across anything certain. I'm wondering whether it would be theoretically possible to change the encoded bit rate (or target video qiality) during a live stream without a standard theora decoder having any problems.
> 
> Yes, there's quite a bit of scope for that.
> 
> > I had assumed that this must be possible, given that Theora is defined as a variable bit rate codec, although in libtheora, it wouldn't be, as the bitrate / video quality has to be passed to theora_encode_init, which you'd only call before the encode started (unless it's possible to call this afterwards to change parameters?)
> 
> There are sort of two options. Within a given logical stream, you can't 
> adjust the codebooks or quant matricies, but you are free to vary what 
> use is made from them. So, as you suggest, an encoder is free to code 
> more or less blocks per frame, chose a different quant level, etc. which 
> will scaled the bitrate. And you are correct that libtheora doesn't have 
> a mechanism for signalling that.
> 
> Another option that you *can* do with the current libtheora is to insert 
> a chain boundary. This allows you to reconfigure the decoder with a 
> different set of codebooks and quant matricies, at the expense of some 
> bitstream overhead. This is a more optimal solution for infrequent but 
> radical changes in bitrate. libtheora exposes the header transmission 
> (in fact, you have to handle it specially) so you can simply flush the 
> stream, reinitialize the encoder with different parameters, and start 
> sending a new Ogg stream down the same socket.
> 
> Hopefully one or both of those options will do what you want.
> 
>  -r
> 
> 
> 
>