[FFmpeg-devel] [RFC] Interlaced material, pix_fmt change, auto-inserted scaler

Tue Jul 26 22:11:20 CEST 2011

On 26/07/11 13:29, Michael Niedermayer wrote:
> On Tue, Jul 26, 2011 at 01:46:01PM +0200, Michael Niedermayer wrote:
>> On Tue, Jul 26, 2011 at 09:49:09AM +0100, Mark Himsley wrote:
>>> On 26/07/11 01:11, Michael Niedermayer wrote:
>>>> On Mon, Jul 25, 2011 at 06:12:25PM +0100, Mark Himsley wrote:
>>>>> Sorry for a very long rational for a very short patch.
>>>>>
>>>>> Cutting to the chase: What do you think of the attached patch?
>>>>>
>>>>>
>>>>> Basically: I have been getting some strange colour artefacts when I
>>>>> convert from yuv420p to yuv422p on interlaced material.
>>>>>
>>>>> Here is a demonstration clip:
>>>>> http://commondatastorage.googleapis.com/himslm01/976_0003_01.AVI
>>>>>
>>>>> The clip is an original DV25 clip created in a camera. The important
>>>>> part is the first 200 frames where there is a whip-pan across a bright
>>>>> green light switch.
>>>>>
>>>>> If I convert that clip to a 422 format, I've chosen DV50 for ease of
>>>>> this demonstration but I have also created IMX30 MPEG 2 video and it
>>>>> shows the same issue I'm trying to describe:
>>>>>
>>>>> ffmpeg -loglevel debug -i 976_0003_01.AVI -vcodec dvvideo -pix_fmt
>>>>> yuv422p -acodec pcm_s16le 976_0003_01.DV50.avi
>>>>>
>>>>> (full output of that command is below)
>>>>>
>>>>> If I look at the 422 output at field rate (for instance in a video
>>>>> editor) then I can see that something is wrong with the chroma.
>>>>>
>>>>> I think I can also demonstrate that using FFmpeg by using the yadif
>>>>> video filter on the original 420 and the new 422 copy:
>>>>>
>>>>> ffmpeg -loglevel debug -i 976_0003_01.DV50.avi -vframes 200 -vf yadif=1
>>>>> -r 50 -f image2 422%04d.png
>>>>>
>>>>> frame 122 is a good one to compare,
>>>>>
>>>>> png taken from original footage:
>>>>> http://commondatastorage.googleapis.com/himslm01/orig0122.png
>>>>>
>>>>> png taken from conversion to 422:
>>>>> http://commondatastorage.googleapis.com/himslm01/4220122.png
>>>>>
>>>>> You can see the big difference.
>>>>>
>>>>>
>>>>> But I noticed that if I specifically add an interlaced aware scale in
>>>>> the video filter, the chroma is correct.
>>>>>
>>>>> ffmpeg -loglevel debug -i 976_0003_01.AVI -vcodec dvvideo -pix_fmt
>>>>> yuv422p -acodec pcm_s16le -vf scale=0:0:interl=-1 976_0003_01.DV50-vf.avi
>>>>>
>>>>>
>>>>> The attached patch makes scale default to being interlaced aware. Is
>>>>> that a bad thing?
>>>>>
>>>>>
>>>>> If you feel this patch will be ok I'll send it again along with updated
>>>>> documentation with no training white space.
>>>>
>>>> it should be ok
>>>>
>>>> [...]
>>>
>>> Two patches attached.
>>>
>>> ffmpeg-scale-default-interlaced-aware.diff: make scale filter default to
>>> interlaced aware scaling&  format changing dependent on source frames
>>> interlaced flag
>>>
>>> ffmpeg-scale-default-interlaced-aware-format.diff: reformat to usual
>>> coding standards
>>
>> both applied
>
> but not pushed, due to:
>
>   --- ./tests/ref/vsynth1/dnxhd_1080i    2011-07-14 21:41:40.425374187 +0200
> +++ tests/data/fate/vsynth1-dnxhd_1080i 2011-07-26 13:45:49.895749789 +0200
> @@ -1,4 +1,4 @@
>   34949ea38da2cf6a8406ad600ad95cfa *./tests/data/vsynth1/dnxhd-1080i.mov
>   3031875 ./tests/data/vsynth1/dnxhd-1080i.mov
> -0c651e840f860592f0d5b66030d9fa32 *./tests/data/dnxhd_1080i.vsynth1.out.yuv
> -stddev:    6.29 PSNR: 32.15 MAXDIFF:   64 bytes:   760320/  7603200
> +3c3226518a0f56468bf56a6682e31fae *./tests/data/dnxhd_1080i.vsynth1.out.yuv
> +stddev:   14.22 PSNR: 25.07 MAXDIFF:  119 bytes:   760320/  7603200
> make: *** [fate-vsynth1-dnxhd_1080i] Error 1
> make: *** Waiting for unfinished jobs....
> --- ./tests/ref/vsynth1/dv  2011-07-11 03:51:36.225253709 +0200
> +++ tests/data/fate/vsynth1-dv  2011-07-26 13:45:53.105749789 +0200
> @@ -1,8 +1,8 @@
>   27ade3031b17214cf81c19cbf70f37d7 *./tests/data/vsynth1/dv.dv
>   7200000 ./tests/data/vsynth1/dv.dv
> -02ac7cdeab91d4d5621e7ce96dddc498 *./tests/data/dv.vsynth1.out.yuv
> -stddev:    6.90 PSNR: 31.34 MAXDIFF:   76 bytes:  7603200/  7603200
> +31b3c8f0fa8ae336c561ccdee5738376 *./tests/data/dv.vsynth1.out.yuv
> +stddev:   12.83 PSNR: 25.96 MAXDIFF:  125 bytes:  7603200/  7603200
>   bd67f2431db160d4bb6dcd791cea6efd *./tests/data/vsynth1/dv411.dv
>   7200000 ./tests/data/vsynth1/dv411.dv
> -b6640a3a572353f51284acb746eb00c4 *./tests/data/dv.vsynth1.out.yuv
> -stddev:   30.76 PSNR: 18.37 MAXDIFF:  205 bytes:  7603200/  7603200
> +7baa332c913fc9b65b7b24830acd74e0 *./tests/data/dv.vsynth1.out.yuv
> +stddev:   31.72 PSNR: 18.10 MAXDIFF:  206 bytes:  7603200/  7603200
> make: *** [fate-vsynth1-dv] Error 1
> --- ./tests/ref/vsynth1/dv50    2011-07-11 03:51:36.225253709 +0200
> +++ tests/data/fate/vsynth1-dv50    2011-07-26 13:45:53.885749789 +0200
> @@ -1,4 +1,4 @@
>   26dba84f0ea895b914ef5b333d8394ac *./tests/data/vsynth1/dv50.dv
>   14400000 ./tests/data/vsynth1/dv50.dv
> -a2ff093e93ffed10f730fa21df02fc50 *./tests/data/dv50.vsynth1.out.yuv
> -stddev:    1.72 PSNR: 43.38 MAXDIFF:   29 bytes:  7603200/  7603200
> +0f612929578f4955c88690b36a783d79 *./tests/data/dv50.vsynth1.out.yuv
> +stddev:   20.25 PSNR: 22.00 MAXDIFF:  224 bytes:  7603200/  7603200
>
>
> [...]

I think I understand the output of fate. Taking the last example, it's 
suggesting that the PSNR has reduced from over 43 to 22, which would be 
a devastating difference.

So, that's DV, DV50, DV411 and dnxhd_1080i. I wonder - are these all 
formats where the decoder always flags the video as interlaced?

Please bare with me as I work out what the fate tests do. In all my 
viewing tests of the our problem media the output looked better with the 
patch, so I hope it's the fate tests that are flawed ;-)

-- 
Mark