[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