[MPlayer-dev-eng] New inverse-telecine filter

[Zoltan Hidvegi]

> > --- libmpcodecs/vf_pullup2.c-save2	Sat Dec  6 18:11:27 2003
> > +++ libmpcodecs/vf_pullup2.c	Sat Dec  6 18:17:27 2003
> > @@ -896,7 +896,7 @@
> >      if (!p->planes[0][0]) init(p, mpi);
> >  
> >      if (mpi->type == MP_IMGTYPE_TEMP ||
> > -	(mpi->type == MP_IMGTYPE_IPB && (mpi->flags & MP_IMGFLAG_READABLE)))
> > +	(mpi->type == MP_IMGTYPE_IPB && !(mpi->flags & MP_IMGFLAG_READABLE)))
> 
> This was the first thing I tried. No help. It just switches which pair
> of buffers get used for I/P and which get used for B.
> 
> > -	    dmpi = vf_get_image(vf->next,mpi->imgfmt,MP_IMGTYPE_EXPORT,0,p->w, p->h);
> > +	    dmpi = vf_get_image(vf->next, mpi->imgfmt, MP_IMGTYPE_EXPORT,
> > +				MP_IMGFLAG_PRESERVE|MP_IMGFLAG_READABLE,
> > +				p->w, p->h);
> 
> Readable and preserve flags are meaningless with export-type image.
> Anyway I just tried this to make sure, and it doesn't help either...

Can you try -vf filmdint=diff_thres=9999/comb_thres=9999/sad_thres=9999/io=1:1

This should be a pass-through EXPORT filter, it does not change
anything, and does the same kind of allocation as vf.c, I do not see
how could this ever fail?  If you still see any artifacts, I may
suspect compiler or some other weird bug.  I use gcc-3.3.2.  If this
does not show artifacts, and -vo md5 compares to the unfiltered
output, then the problem is in the deinterlace code.  And the
artifacts you had does not seem to propagate via motion-compensation,
which also suggests that it may be happening in the dint code.  Does
it still happen with dint_thres=256 (with the other thresholds at
default, not at 9999)?  Does it happen with unoptimized code?

Also, your pullup filter does not work with ffmpeg MPEG-4, which
assumes that the IP frames alternate (probably does partial update).

Zoli