[MPlayer-users] new version of detc filter! (inverse telecine)

[D Richard Felker III]

On Mon, Mar 17, 2003 at 10:45:34PM +0100, Arpi wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi,
> 
> > > -static int telecine=0;
> > > +int telecine=0;
> 
> > 24fps sequences telecined up to 30. However, dealing with badly
> > encoded movies which mix hard and soft telecine should be possible
> > with the telecine var from video.c.
> > 
> > While this is possible, IMHO a much better approach would be to put
> > timestamps in mpimage_t, and let filters change them when passing the
> > image on to the next layer. This will eventually facilitate proper
> 
> agree, but it means a big design change of teh whole mplayer/mencoder core,
> as it's designed to demuxers provideo whole frames with timestamps, and it's
> used then to decide if we drop/skip or decode the frame.
> 
> i plan to do it this way (codecs/filters provide timestamps) in mplayer G2,
> it would also solve several other problems:
> - realvideo codecs provide accurate timestamps, so we could get rid of hacks
> in demuxer
> - field-coded mpeg2 (50 fields instead of 25 frames)
> - frame order for IPB mpeg formats (now it's workaround'ed in video.c)
> but it also brings some problems:
> - frame order for IPB in avi or other 'dumb' container (can be workaround'ed)
> - timestamps not available at streamcopy (or streamcopy requires decoding...)
> - framedrop won't be so smooth as it is now for variable fps formats

IMO the demuxer should still put timestamps on frames; the vd and vf
layers should just be able to put their own timestamps on in place of
the originals when they output the frame to the next filter/vo.

> > framerate-changing filters without all the stupid hacks I've done so
> > far, and they'll work better with mencoder!
> 
> unless you do -ovc copy ...

Of course filters don't work with -ovc copy. It's not just
framerate-changing ones; all of them are unavailable!

Rich