[FFmpeg-devel] [PATCH] Change default behaviour of scale filter from 'progressive' to 'auto'
Carl Eugen Hoyos
cehoyos at ag.or.at
Mon Apr 2 10:21:59 CEST 2012
Tim Nicholson <nichot20 <at> yahoo.com> writes:
> > Which is why I am slightly against this patch:
> > Afaict, on DVB-T (SD), all material is signalled as being
> > interlaced, although all movies and series are progressive
> > (because 24Hz stretched and "interlaced" to 50Hz does not
> > produce visible fields).
>
> Ahh, the so called PSF mode, (Progressive Sequential Field).
Exactly.
> The trouble is there is may also be true interlaced material
> within these streams as well.
Of course.
> In fact within a single program you may find a mix of both types
> if the content switches between studio and film based material.
Yes, this is what I see.
> So I would challenge the "all material" in your statement.
What I see here is: All material is signalled as being interlaced,
(nearly) all movies and all series (as opposed to "studio based
material") are (visually) progressive.
What is wrong about this?
> > I suspect who works with interlaced material knows it
> > and can set the scaling correctly.
> >
>
> Whilst this is true there is one major snafu in the current
> arrangement, and that is that quite often in a filterchain
> a scale filter gets auto inserted between other filters,
> and by default handles material progressively.
> Therefore when building filtergraphs one has to be very
> careful to forced add scale filters with interlace enabled at every
> place where a scale filter would otherwise be auto inserted.
I had not realised this.
> It is much neater, and leads to clearer filtergraphs,
> if one could force the interlace type at the start of
> a filterchain using 'setfield' and leave the rest of
> the chain containing just the required filters for the
> actual required function.
Isn't this a different approach than what your patch does?
> Handling PSF material as interlaced can mean that non optimal
> interpolation is used, but the material is not otherwise damaged.
> However the reverse of handling interlaced as progressive can
> render material unusable.
I absolutely may be wrong but I thought when handling interlaced
as progressive the problem is immediately visible but when
handling progressive as interlaced the material gets permanently
damaged in a way that is not immediately obvious.
Carl Eugen
More information about the ffmpeg-devel
mailing list