[FFmpeg-devel] [PATCH] Port tinterlace filter from MPlayer.
Stefano Sabatini
stefano.sabatini-lala at poste.it
Sun Aug 28 02:49:13 CEST 2011
On date Friday 2011-07-01 11:00:41 +0200, Stefano Sabatini encoded:
> 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).
Updated, tested against the mp=tinterlace filter, same output is
issued (but mp=tinterlace has broken PTSes all set to 0), only
difference is in mode 3 where tinterlace correctly set pad lines luma
values to 16 rather than to 0.
--
FFmpeg = Frenzy and Foolish Multimedia Patchable Empowered Gadget
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-lavfi-port-tinterlace-filter-from-MPlayer.patch
Type: text/x-diff
Size: 16290 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110828/1d24b030/attachment.bin>
More information about the ffmpeg-devel
mailing list