[Ffmpeg-devel] Intra-frame rate control

Loren Merritt lorenm
Fri Apr 6 08:49:40 CEST 2007


On Thu, 5 Apr 2007, RLopez wrote:

> If avcodec.lib can only change Q values at picture boundaries for MPEG2
> files that's a huge limitation.  The advantage of MPEG2 over MJPEG is the
> ability to change the Q in the middle of an image.

The advantage of MPEG2 over MJPEG is P- and B-frames. I'd call adaptive 
quant rather minor in comparison.

> A common clip people use to show this off is a field of daisies under 
> a blue sky.  The blue sky can  be encoded well with a high Q value while 
> the more complex field of daisies portion of the image can be encoded 
> with a lower Q value.

But the blue sky also uses much less bitrate at the same QP. So I'm not so 
sure that the optimal encoding mode is to raise the QP of the sky.
On the contrary, x264's adaptive quant uses _lower_ QP for smooth 
gradients like a sky, since any tiny deviation from the gradient will be 
blatantly visible, whereas small errors in the daisies would be hidden by 
the masses of detail. I don't think H.264 is so different from MPEG2 as to 
reverse the direction of that decision...

> Another problem I'm seeing caused by avcodec.lib only changing Q values at
> picture boundaries is that the instantaneous bitrate of an encoded clip
> jumps around too much.  For example when a complex image follows several
> black frames the bitrate skyrockets because the rate controller lowered the
> Q during the black frames and doesn't readjust it until the end of the
> complex frame.  This problem is especially bad when working with HD images.

Just because it only changes QP between frames doesn't mean it can only 
react. RC examines the current frame before choosing a QP. The QP chosen 
for one frame will be independent of the complexity of the previous 
frames, except insofar as RC reacts to the VBV state or otherwise 
introduces an explicit dependency (qblur, etc).

--Loren Merritt




More information about the ffmpeg-devel mailing list