[Ffmpeg-devel] [PATCH] DV image quality improvement (original) (raw)

Roman V. Shaposhnik Roman.Shaposhnick
Tue Feb 28 04:21:18 CET 2006

Dan Maas wrote:

I have nothing against having this alternative method for assigning class numbers, but I would like to suggest one thing: could you, please, make it easy to switch between the two versions of how classes are assigned ?

See attached... I've rewritten the patch so that it's just a one-line change from the SMPTE method. I also included the new checksums. The PSNR increase on ffmpeg's test video is from 29.03 to 29.17. The impact on natural-looking live video is more dramatic - the 4825-frame BBC test video (all live scenes) goes up from 41.77 to 44.72 with my adjustment (in DV50 mode - patch forthcoming). Applied. By the way, since I usually update all three golden files, could you please do the same: tests/ffmpeg.regression.ref tests/libav.regression.ref tests/rotozoom.regression.ref

I completely agree with you here. In fact, when I was developing DV encoder the quantization step table (on page 37) made me very puzzled. It is quite obvious to anyone that having just two class numbers 2 and 3 is enough to cover all possible cases of quantization

Class number is per-block, whereas QNO is per-macroblock. A really sophisticated encoder could optimize class numbers together with QNO to squeeze out every last bit of efficiency. Of course, that would come at a huge cost in CPU time. Bingo! I guess I kinda had it backwards because first class numbers get assigned and later QNOs are calculated. This actually made me thinking that there could be an additional opportunity for us here: after all QNOs are calculated we might still tweak individual class numbers to fill up the space if there's any left. Of course which blocks to tweak is a big question -- we've got 5*6 of them and it's not quite clear which ones might give us the biggest visual bang for the space buck. Another idea would be to always give a bias of -1 to luma blocks making them all class 1 (instead of 2) the downside is not huge at all -- just one QNO combination (8, 8, 16, 16).

On the bright side, I've looked at a lot of DV encoders, and most of them don't even come close to the sophistication of ffmpeg's. For instance, my $1500 Canopus ADVC-500 hardware encoder assigns a fixed QNO to almost all blocks, and performs quantization very coarsely by playing with class numbers. Only Apple's encoder seems to make an attempt of optimizing both class numbers and QNO. But it's still more conservative than ffmpeg in QNO assignment, so the results aren't necessarily better. With this class-number patch, ffmpeg's output is roughly equal in image quality to the Apple encoder. (no small feat, as Apple's is one of the best, if not the best one out there) Well, that's really nice to hear.

Thanks, Roman.

More information about the ffmpeg-devel mailing list