[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