[MPlayer-dev-eng] New filter vf_ivtc, smart dropping of every 5th

[Billy Biggs]

  Does the posted filter actually just drop every 5th frame?  If so then
it is misnamed.  IVTC usually refers to "inverse telecine", where you
reverse a 2-3 pulldown sequence.  While this does effectively drop one
frame out of every 5 input frames, it's not that the 5th frame is identical
to the 4th, but rather, there are 2 repeated fields out of every 10 fields.

  While using motion vectors for reversing 2-3 pulldown is a good idea,
it's not as simple as you propose.  Furthermore, 2-3 pulldown decoding
for DVDs is made difficult, since sometimes the sequence is encoded using
the repeat_first_field flag of the DVD, and many DVDs randomly switch
between using this and encoding the sequence in full.  As an aside, I
believe that the best way to handle this case for DVD recompression is
simply to always expand to 29.97 interlaced content and use a heuristic
based filter, as otherwise I've found things get pretty complicated.

  -Billy

Johannes Guenther (johannes.guenther at s1999.tu-chemnitz.de):

> Arpi wrote:
> > what about doung it in 2 passes?
> > first pass would save the motion vectors (or the weightened absolute
> > sum of them) and you use that info for teh second pass.
> > duplicated frames have mostly 0;0 MVs while previous and next frame will
> > have similar, non-zero MVs.
> 
> Interesting idea.
> 
> The cleanest way would be to initially scan the movie (no encoding is
> needed) and record the differences to create a table of frames to drop
> while encoding later. This should not take much time (now it would also
> make sense to optimize the difference calculation / to use te optimized
> functions from libavc). The dropping itself does not need a buffer any
> more.
> 
> One may think of using the info from 'divx2pass.log' (as I did ;-) but
> there are too many cons:
>  - only usable when with using libavc and 2pass mode
>  - even then the 'divx2pass.log' is hardly usable for the 2nd pass
>    because it has records of frames which will be dropped (one can try
>    to correct the info but this would be a nasty hack if possible at
>    all: one have to think of changed key frame intervals, likely
>    destroyed IBBPBBP... pattern and much more)
> 
> Bye,
> 	Johannes
> -- 
> http://beam.to/Hawk
> PGP Key fingerprint = 2F 72 52 1C CF 86 96 35  8A DD 8E F5 C6 05 CE C5
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng