[FFmpeg-devel] [PATCH] Change default behaviour of scale filter from 'progressive' to 'auto'

[Tim Nicholson]

On 04/04/12 19:20, Reimar Döffinger wrote:
> On Wed, Apr 04, 2012 at 03:15:08PM +0100, Tim Nicholson wrote:

>> ----- Original Message -----
>>> From: Baptiste Coudurier <baptiste.coudurier at gmail.com>
>>> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
>>> Cc: Tim Nicholson <nichot20 at yahoo.com>
>>> Sent: Wednesday, 4 April 2012, 2:48
>>> Subject: Re: [FFmpeg-devel] [PATCH] Change default behaviour of scale filter from 'progressive' to 'auto'
>>>
>>> On 04/03/2012 09:07 AM, Tim Nicholson wrote:
>> [....]
>>>>  diff --git a/tests/ref/vsynth1/dnxhd_1080i b/tests/ref/vsynth1/dnxhd_1080i
>>>>  index f8f6df0..de4732e 100644
>>>>  --- a/tests/ref/vsynth1/dnxhd_1080i
>>>>  +++ b/tests/ref/vsynth1/dnxhd_1080i
>>>>  @@ -1,4 +1,4 @@
>>>>   027c985483caab9397592bf27477dce1 *./tests/data/vsynth1/dnxhd-1080i.mov
>>>>   3031911 ./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
>>>
>>> A default change that produces a difference like this is unacceptable IMHO.
>>> This is quite a big difference.
>>>
>>
>> If this was a real world case would agree. However the fate test deliberately puts progressive material in an interlaced stream, and then back again. If you do the same round trip with interlaced material the results are very different. The results are only worse because the stream is being handled in the format it claims to be, rather than blindly handled progressively.
> 
> However that is a rather real-world behaviour for DV and DNxHD files as
> far as I can tell.

Well real world only in as much as any interlaced stream, not just DV or
DNX may contain only progressive content, but equally may contain a
mixture, or interlaced only.

I am suggesting we trust the flagging *unless* we know it to be wrong,
in which case the tools exist to override the setting

> But regardless of that, I am very much against changing the test
> reference, that bad PSNR will make it hard to see actually codec
> bugs.

When you say "reference" I presume you mean reference media sample.

> Instead the command for the test case should be changed so that the
> scale filter is forced to use progressive scaling.

I agree wholeheartedly, with the addition perhaps of an additional
sample of interlaced material be used to check performance in that mode.

I am not familiar enough with fate to see how to set about changing the
invoked command line for the tests for those codecs at issue, or to know
if such "fiddling" with reference tests is acceptable.

If such tweaking to the  command string is acceptable I will try and get
my head around adjusting fate.

-- 
Tim