[FFmpeg-devel] [PATCH] Port tinterlace filter from MPlayer.

Stefano Sabatini stefano.sabatini-lala at poste.it
Fri Jul 1 11:00:41 CEST 2011


On date Thursday 2011-06-30 10:15:15 +0200, Stefano Sabatini encoded:
> On date Wednesday 2011-06-29 05:43:18 +0200, Michael Niedermayer encoded:
> > On Tue, Jun 28, 2011 at 01:08:23PM +0300, Ivan Kalvachev wrote:
> > > On 6/28/11, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
> > > > On date Monday 2011-06-27 23:49:09 +0200, Stefano Sabatini encoded:
> > > >> On date Sunday 2010-09-26 20:32:48 +0200, Michael Niedermayer wrote:
> > > > [...]
> > > >> Updated based on the tinterlace port from FFmbc, with some
> > > >> simplifications.
> > > >
> > > > Updated again, with a request_frame() implementation.
> > > >
> > > > Some questions:
> > > >
> > > > 1) what do we want to do with the limpcodecs wrapper as they are
> > > > ported to native filters? (I suppose the right answer is "drop them"
> > > > => less code to maintain, in this case mpcodecs/tinterlace is broken
> > > > and in general fixing those filters - with no previous knowledge of
> > > > libmpcodecs - requires more time than porting them).
> > > 
> > > IMHO, once the native is working fine, remove the other.
> > 
> > agree
> > also once you and stefano agree on the patch, consider it approved by
> > me too. iam too busy to double review and you are a pretty good
> > developer who i would hope to be more active :)
> 
> Updated with more fixes.
> 
> I withdraw the "mode 5" ideas, since it requires some more changes to
> the framework which are not related to the port.

Regarding this patch, I'd appreciate some comments from Baptiste
regarding this part:

[...]
> +static int poll_frame(AVFilterLink *outlink)
> +{
> +    TInterlaceContext *tinterlace = outlink->src->priv;
> +    AVFilterLink *inlink = outlink->src->inputs[0];
> +    int ret, val;
> +
> +    val = avfilter_poll_frame(inlink);
> +
> +    if (val == 1 && !tinterlace->next) { //FIXME change API to not requre this red tape
> +        if ((ret = avfilter_request_frame(inlink)) < 0)
> +            return ret;
> +        val = avfilter_poll_frame(inlink);
> +    }
> +    assert(tinterlace->next);
> +
> +    return val;
> +}

I copied the comment verbatim, can you elaborate on that?

Regarding the "mode 5", I'm considering to write a separate filter for
that, and call it something like "tvinterlace" since it would be quite
different with respect to this (takes one picture -> returns two), and
I want to avoid to complicate the logic of this filter more (while
some routines can be shared amongst the two).
-- 
FFmpeg = Formidable and Fierce Mega Portentous Enhanced Gigant


More information about the ffmpeg-devel mailing list