[MEncoder-users] inverse telecine with 60 fps progressive video

[D Richard Felker III]

On Fri, Apr 08, 2005 at 11:16:06PM -0700, Scott W. Larson wrote:
> D Richard Felker III wrote:
> 
> >Even a 2:3 pattern is extremely choppy..
> > 
> >
> The 2:3 pattern makes 24 fps material look perfect at 60 frames per 
> second. I've never seen film look this smooth outside of a movie theater.

Then you have very bad eyes. :) Everyone complains about how choppy
telecine looks.... particularly during pans and vertical-scrolling
credits.
 
> >Never set -fps manually; mencoder knows the input fps. 
> >
> At least it wasn't hurting anything.

It was because you were using the wrong numbers.

> >Also, the
> >numbers are 60000/1001 and 24000/1001, NOT 59.97 and 23.967.
> > 
> >
> Of course I meant to type 23.976. This value is suggested three times in 

It's still wrong. I didn't even notice your typo, I was talking about
the incorrect rounding.

> the mencoder documentation. The documentation doesn't suggest 24000/1001 
> anywhere. It doesn't even mention that -ofps accepts this fractional 
> notation.

It does now (cvs). You're using an old version.
BTW all floating-point options in mplayer/mencoder accept fractional
notation. It's a common part of the config parser module. :)

> >Possibly, with the right settings. You need to adjust the thresholds
> >so it doesn't drop too much or too little.
> > 
> >
> I'm half way through a conversion using decimate with no tuning. 

Excellent. Glad to know it's useful for someone. I just wrote it for
testing very-low-bitrate encodes where I wanted to drop as many frames
as possible, and didn't figure it would ever really be useful to
someone else.

> Everything I've reviewed so far looks absolutely perfect! No choppiness, 
> no duplicates, exactly what I wanted. Thanks for steering me away from 
> trying to use pulldown filters. It would have taken me months to figure 
> out they weren't really doing anything.
> 
> I also put tinterlace=1 in front of decimate to throw away half the 
> frames. It's faster since decimate has less work to do.

:)

Rich