[FFmpeg-devel] Strange qmax behaviour with mpeg2
Reimar.Doeffinger at gmx.de
Tue Sep 11 16:31:01 CEST 2012
On 11 Sep 2012, at 14:14, Joseph Artsimovich <joseph at mirriad.com> wrote:
> On 11/09/2012 12:44, Reimar Döffinger wrote:
>> On 11 Sep 2012, at 13:02, Joseph Artsimovich <joseph at mirriad.com> wrote:
>>> When encoding IMX 30 content (I-frame only mpeg2 at fixed bitrate) I noticed ffmpeg produces lower quality output than other encoders. Digging deeper, I found strange behaviour of qmax parameter with mpeg2video encoder that I can only explain away as a bug.
>>> Before explaining further, here is my command line:
>>> ffmpeg -i input.mov -vtag mx3p -vcodec mpeg2video -r 25 -pix_fmt yuv422p -minrate 30000k -maxrate 30000k -b:v 30000k -intra -flags +ildct+low_delay -dc 10 -intra_vlc 1 -non_linear_quant 1 -ps 1 -qmin 1 -qmax 8 -top 1 -bufsize 1200000 -rc_init_occupancy 1200000 -rc_buf_aggressivity 0.25 -an out.mov
>>> The value of qmax=8 was taken from http://www.itbroadcastanddigitalcinema.com/ffmpeg_howto.html#Encoding_D10
>>> This value guarantees the encoded frame size won't exceed 150000 bytes, which is the maximum for IMX 30. If I set it even higher to 12 (the maximum -non_linear_quant would allow me), I get a file with identical size but lower quality. That seems very wrong. I mean if it fits bitrate restrictions at qmax=8, it shouldn't degrate quality just because you allow it to.
>> For one-pass bitrate-based encoding the encoder almost certainly will make mistakes.
>> With larger qmax the mistakes can be bigger.
>> While it is likely the encoder could be improved a lot (e.g. by adding rc-lookahead) to work better with 1-pass, unless you can reproduce it in a 2-pass encode I don't think it is particularly unexpected.
> The number of passes is irrelevant in this case, as it's an I-frame only, fixed-bits-per-frame variant of mpeg2. From my perhaps naive understanding, having done the DCT, you just need to do binary search to find the best quantization factor that produces output not larger than the maximum allowed size. From this point of view, as long as your optimal quantization factor is within [qmin, qmax], further increasing this interval should not affect the selected quantization factor. Yet, that's what happens.
Why would you use the same quantization factor for the whole frame? That would be major nonsense for some inputs, though I don't remember which methods MPEG-2 supports for changing quantizer.
Also there is no "fixed-bits-per-frame", and FFmpeg doesn't even support it approximately I think. Unless I misremember FFmpeg also never re-encodes a whole frame if the resulting bitrate is off.
>> Btw. you did not define "lower quality", so the encode might just disagree with you on which is better, in which case 2-pass would probably make it worse.
> By "lower quality" I mean blockiness.
If you do not do postprocessing, blockiness is in big part a function of quantizer difference, so if the encoder reduces quantizer for one block because it hardly affects its quality and increases it for the neighbouring one because it makes it look a lot better, it will be blockier, even though overall quality measured by e.g. PSNR will increase.
More information about the ffmpeg-devel