[vorbis] vbr / cbr / abr API calls

[Akos Maroy]

Michael Smith wrote:

Let me clear it up a bit, as I see a bit of confusion here with the 
phrases used:

>>CBR:
>>
>>    ret = vorbis_encode_setup_managed( &vorbisInfo,
>>                                       getInChannel(),
>>                                       getOutSampleRate(),
>>                                       -1,
>>                                       getOutBitrate() * 1000,
>>                                       -1)
>>       || vorbis_encode_ctl( &vorbisInfo, OV_ECTL_RATEMANAGE_AVG, NULL)
>>       || vorbis_encode_setup_init( &vorbisInfo);
> 
> 
> This is a fully VBR mode (as for the VBR mode below, but selected by
> bitrate). True CBR is more or less completely useless (most other
> codecs don't even offer it - even mp3 just fakes it using the bit
> reservoir), but can be configured if you want by setting min/max/nom
> to the same value. Expect poor performance if you do.

thus: calling vorbis_encode_setup_managed() initializes a VBR mode 
encoding, with quality specified by bitrate? (with the possibility to 
set upper-lower limits).

But isn't this what ABR should be about?

> 
> 
>>
>>ABR:
>>
>>    ret = vorbis_encode_init( &vorbisInfo,
>>                              getInChannel(),
>>                              getOutSampleRate(),
>>                              -1,
>>                              getOutBitrate() * 1000,
>>                              -1 );
>>
>>VBR:
>>
>>    ret = vorbis_encode_init_vbr( &vorbisInfo,
>>                                  getInChannel(),
>>                                  getOutSampleRate(),
>>                                  getOutQuality() );
>>
>>
>>Are these calls correct?
> 
> 
> The latter two are correct.
> 
> You can also set hard min (not very useful) and hard max (potentially
> very usefu) bitrates for quality-based modes using 
> vorbis_encode_ctl(&vi, OV_ECTL_RATEMANAGE_SET, ai) (where ai is a
> struct ovectl_ratemanage_arg *) with the struct members set 
> appropriately (pretty obvious - just look at the struct definition in
> vorbisenc.h)

So is there a real difference between:

     ret = vorbis_encode_init( &vorbisInfo,
                               getInChannel(),
                               getOutSampleRate(),
                               (getOutBitrate() * 1000) * 1.1,
                               getOutBitrate() * 1000,
                               -1 );

and:

     ovectl_ratemanage_arg   ai;

     // fill out ai here

     ret = vorbis_encode_init_vbr( &vorbisInfo,
                                   getInChannel(),
                                   getOutSampleRate(),
                                   getOutQuality() )
        || vorbis_encode_ctl( &vorbisInfo, OV_ECTL_RATEMANAGE_SET, &ai);

also, can you elaborate on the structure ovectl_ratemanage_arg:

truct ovectl_ratemanage_arg {
   int    management_active;

   long   bitrate_hard_min;
   long   bitrate_hard_max;
   double bitrate_hard_window;

   long   bitrate_av_lo;
   long   bitrate_av_hi;
   double bitrate_av_window;
   double bitrate_av_window_center;
};

it may be obvious to you, but I don't see what for example 
bitrate_hard_window, bitrate_av_* are for, and what are the possible 
values for management_active (e.g. is this a boolean-like member, or are 
there different levels of management)? for bitrate_hard_min, is -1 a 
"don't care" value?

> In managed modes (ABR/CBR are subsets of that), min and max bitrate do
> the obvious thing - they set a minimum and maximum bitrate for the
> encoder to use.

Above you said that by calling vorbis_encode_setup_managed() I actually 
get a VBR mode. Here you associate managed mode with ABR and CBR. What 
are managed modes then? This is a bit confusing :((

> Managed modes are much slower. The encoder has to do a lot more
> work to figure out an encoding whilst also meeting the bitrate
> constraints. The reason 'CBR' seemed faster to you was that you weren't
> using a CBR mode at all. It's a choice the user has to make - if they
> need the hard constraints (which is possible, though rare, for streaming
> purposes, and maybe for some other purposes too), then it's worth 
> using > twice the cpu.

I need such features exactly for streaming. What I'm looking for is the 
possibility to specify a maximum bitrate, so that users with limited 
bandwith can be sure that they can listen to the stream, so as their 
bandwidth is not exceeded.

<p>Akos

<p><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.