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

[Tim Nicholson]

On 30/03/12 18:21, Reimar Döffinger wrote:
> On Fri, Mar 30, 2012 at 06:57:56PM +0200, Michael Niedermayer wrote:
>> On Fri, Mar 30, 2012 at 05:35:46PM +0100, Tim Nicholson wrote:
>>> On 30/03/12 16:47, Tim Nicholson wrote:
>>>> On 30/03/12 15:47, Michael Niedermayer wrote:
>>>>> On Fri, Mar 30, 2012 at 10:51:28AM +0100, Tim Nicholson wrote:
>>>>>> When the option of interlaced aware scaling was first introduced interlace detection
>>>>>> was poor. This has been improved, and this proposed patch changes the default behaviour
>>>>>> of the filter to depend upon the auto detected value, bringing it into line with
>>>>>> many other options whose default value is -1 (auto).
>>>>>>
>>>>>> From 4d1ad96e209b18bdf86530d153a6a5acbc5aab8a Mon Sep 17 00:00:00 2001
>>>>>> From: Tim Nicholson <Tim.Nicholson at bbc.co.uk>
>>>>>> Date: Fri, 30 Mar 2012 10:43:46 +0100
>>>>>> Subject: [PATCH] Make default setting of parameter interl=-1 (auto)
>>>>>>
>>>>>> Previously default was 0 (progressive), but interlace detection has been
>>>>>> improved in 648e55ff, and this makes the behaviour consistent with other
>>>>>> options that use 1|0|-1 with -1 the default.
>>>>>
>>>>> This patch changes several fate tests checksums
>>>>>
>>>>> please check if these changes are ok and if so update the checksums
>>>>> with the patch
>>>>>
>>>>
>>>> Hmmm. I didn't think a command line selection logic change would affect
>>>> fate. But I am beginning to think that this change may be affecting auto
>>>> inserted filters (hopefully for the better if it stops them mangling
>>>> interlaced material).
>>>>
>>>> I'm not very fluent with fate, so this may take a while....
>>>>
>>>>
>>>>>
>>>>> [...]
>>>>> Test vsynth1-dnxhd_1080i failed. Look at tests/data/fate/vsynth1-dnxhd_1080i.err for details.
>>>>> make: *** [fate-vsynth1-dnxhd_1080i] Error 1
>>>
>>> OK so I have looked at "tests/data/fate/vsynth1-dnxhd_1080i.err" and it
>>> seems to be a normal console output for 2 passes of ffmpeg:-
>>>
>>> pgmyuv -> dnxhd
>>>
>>> then
>>>
>>> dnxhd -> rawvideo
>>>
>>>
>>> What am I looking for?
>>
>> do these converted files look better, worse or the same ?
>> The diff indicates they are worse. Is it different with actual
>> interlaced material ?
>>

Since the patch only changes the default logic I compared interlaced
material handled progressively, forced interlaced and autodetected.

I could see no difference between the last two which were both
definitely better than the first.


>>
>>> How do I check/update the checksums?
>>
>> you can copy and paste the diff into patch -p1 to update them
> 
> I think it would be preferable to change their commands to use the
> previous scaling method (I presume that scaling is really the issue
> here).

Not quite sure I understand what you mean by "previous method" The
methods employed have not changed just the selection of which to use in
a given case.

> And I also suspect that the worse quality might be related to that
> before encoding the content is progressive and thus progressive
> scaling is used but then after decoding interlaced is used.

Which is what I would expect as the first pass is generating 1080i.
Handling progressive as interlaced is usually safe, but possibly non
optimal. Handling interlaced as progressive usually damages the content
horribly.


> Which of course is generally related to any kind of "interlaced content"
> flag being really, really unreliable.

Which, if it is still the case is a major issue. However my
understanding was that this had significantly improved with the patch I
cited. This together with the ability to use the "setfield" filter to
override iffy detection lead me to think that it was a good time to
change the default operation.


-- 
Tim