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

[Tim Nicholson]

On 30/04/12 14:44, Michael Niedermayer wrote:
> On Tue, Apr 17, 2012 at 10:15:15AM +0100, Tim Nicholson wrote:

> [...]

>>  doc/filters.texi       |    7 +++++--
>>  libavfilter/vf_scale.c |    4 +++-
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>> 204530437f82f96f65d5062b44225c03f15a5dd6  0001-Make-default-setting-of-parameter-interl-1-auto.patch
>> From 3d2f71dc0dec57d6058eddfe9a6f90766943080b 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 1/2] 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.
> 
> Ive tested a few files and the autodetection does not work reliable.
> for example matrixbench_mpeg2.mpg is flaged as interlaced while it
> is progressive.

Hmm, pity. I have also found that the idet filter doesn't seem to work
if a scale 0 is auto inserted (with or without my patch), which means
that it fails to detect bgr material....


> Currently progressive material is scaled correctly and interlaced
> material needs the user to override the setting otherwise it produces
> vissible artifacts
> 
> After this patch a good percentage of progressive material will need
> a override or contain not so easy to notice artifacts while
> interlaced material still will need a override in other cases.
>

...and since I was trying to reduce the incidence of having to override
all I have achieved is shifting the problem around not reducing it.. :(


> I think the patch is correct but until the input interlace flag is
> ALOT more reliable i dont think we should apply this as it likely
> would worsen the overall results for the end user, who after this
> patch would need to manually override it for all files while now
> only interlaced files need a override to be sure they are scaled
> correctly
> 

Fair comment. One of the problems with the current system is that in
order to perform the override, one has to construct a command string,
run a test on the material. Observe where scale filters ma be auto
inserted. Then reconstruct the command line with a full -vf string and
manually inserting the scaler with interlace turned on, or preceded by a
setfield filter. This can be tedious and simple command strings end up
being turned into more complex lines with filterchains. Using just -vf
setfield=prog|tff|bff on its own doesn't seem to work.

I therefore wonder if a better solution at this stage would be to add an
additional SWScaler AVOption to enable selecting the default mode.
Current users would see no change, and those who need it could simply
add the option to their command line and get the results they need in a
more elegant and simple manner than described previously.

I will try and bone up on the SWScaler API and see what it would take to
achieve that if you think that approach might work.

> maybe we could extended the interlace field range so it has more than
> 2 states
> If you can make misdetections happen in only one direction (like its
> now) that is so that progressive material is (nearly) never flagged as
> interlaced then enabling the scaler autodetection should be ok
> 
> [...]

That is a greater work methinks, and one to look at when there is more
time...

Thanks for your time and input.

-- 
Tim