[FFmpeg-devel] [PATCH] Change default behaviour of scale filter from 'progressive' to 'auto'
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Fri Mar 30 19:21:02 CEST 2012
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 ?
>
>
> > 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).
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 of course is generally related to any kind of "interlaced content"
flag being really, really unreliable.
More information about the ffmpeg-devel
mailing list