[FFmpeg-devel] [PATCH] avfilter: add framerate video filter

Robert Krüger krueger at lesspain.de
Fri Aug 28 17:04:29 CEST 2015


On Fri, Aug 28, 2015 at 10:55 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Robert Krüger <krueger <at> lesspain.de> writes:
>
> > > > > Shouldn't this be:
> > > > > ... required to deinterleave before and
> > > > > interleave after this filter.
> > > > > ?
>
> > From my understanding what the filter does and what
> > the visual results of each option would be
>
> You mean you tested deinterleaving and interleaving
> and it doesn't work or looks bad?
>
> > I would guess the text is meant as it is written
>
> I of course did not say that the current text means
> something else than what is written.
> (Just that it may not be the best solution for the
> given issue, both quality- and speed-wise.)



>
> > especially since Mark is both a native english
> > speaker and a very competent broadcast professional
> > but that's just my 2c.
>
> Just to make sure I don't misunderstand you:
> It is not the arguments that count but who makes them?
>
>
no, of course the arguments count. It's just that a recommendation by
someone whose track record I know and appreciate may have some more weight
than that of a random person (specifically not meaning you by that in this
context) but you are right, it's bs in a conversation like this. Consider
that comment withdrawn.


> But seriously: I can imagine (and I assume that is
> why you are saying my suggestion above is bad) that
> the deinterleaving can lead to artefacts (shadows) on
> top and bottom of the output file (assuming the
> "right" input) and should therefore be avoided.
> But in that case it should still be faster (and
> produce cleaner output) than deinterlacing to split
> the input video, use two framerate instances for the
> two fields of the input video and interleave the two
> output links of the two framerate instances.
>
>
Maybe I simply haven't understood your alternative approach correctly. Do
you mean processing the top and bottom fields as separate progressive
streams?

Anyway, I still think the text is fine as it will hopefully lead to people
adding something like yadif before the filter so they don't get weird
output for interlaced content. That does not exclude other possibilities to
deal with the fact that the algorithm was developed with progressive
signals in mind. Plus the fact that hardly anyone I know in this area
(people dealing with video conversions in their work) would know the term
"deinterleaving" and how it differs from "deinterlacing" but ymmv.


More information about the ffmpeg-devel mailing list