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

[D Richard Felker III]

On Sun, Feb 16, 2003 at 10:22:46PM +0100, Johannes Guenther wrote:
> D Richard Felker III wrote:
> > On Sun, Feb 16, 2003 at 01:41:27PM +0100, Arpi wrote:
> >> isn't -vop dint the same? afair it was written for the same purpose.
> > AFAIK, -vop dint does not work at all. I've never been able to succeed
> > in getting it to drop frames.
> 
> As described is the man page -vop dint wants to skip interlaced frames,
> whereas -vop ivtc wants to skip duplicate frames (and skips only one out
> of five).
> After your hint I experimented with dint and had a look to its source
> code - it is not useful for this purpose.

Well not only is it not useful for your purpose, it doesn't even seem
to work for its intended purpose... :(

> >>why do you need 6 frames for detecting duplicated frame?
> >>keep only the previous one (IMGTYPE_IP) and comtare teh current one with
> >>the previous, if the same, drop it.
> > Agree!
> 
> I think using 6 frames is more reliable.
> You can know for sure that the frame which was inserted is among this 6
> (last) frames. Thus you choose to drop that frame that is the most
> similar one. (Actually it is not that simple: for speed reasons not every
> pixel is compared; so if the filter detects a second frame which seems
> to be also similar to another frame, a second pass with comparing more
> pixels is performed.)
> 
> Using only the (difference to the) last frame may lead to false
> decisions. To decide whether to drop the frame in progress or not you
> would need a threshold for the difference since the duplicated frame will
> not be 100% the same (compression artefacts, etc.). But frames in dark
> scenes with little motion will also fall under this threshold. With some
> heuristics (drop only one frames out of five) you can avoid some of
> this mistakes, but not all.

Are you sure?? Unless the encoder used was totally broken, the
duplicate frame will have all its macroblocks encoded as no change,
and this should be bit-for-bit identical to the previous one.

Rich