[Ffmpeg-devel] [PATCH] DV image quality improvement

[Roman V. Shaposhnik]

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.