[FFmpeg-devel] [PATCH] Change default behaviour of scale filter from 'progressive' to 'auto'
Michael Niedermayer
michaelni at gmx.at
Mon Apr 30 15:44:33 CEST 2012
On Tue, Apr 17, 2012 at 10:15:15AM +0100, Tim Nicholson wrote:
> 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.
> > 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.
> > Instead the command for the test case should be changed so that the
> > scale filter is forced to use progressive scaling.
>
> Thanks for all the input.
>
> Attached a rebased version of the original patch, together with a patch
> that changes the command of the test cases that originally failed fate,
> in order for them to now pass after application of the original patch.
>
>
> --
> Tim
> 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.
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.
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
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120430/15bef5cc/attachment.asc>
More information about the ffmpeg-devel
mailing list