[MEncoder-users] Inverse telecine? framerate from 120000/1001 to 24000/1001

[Rich Felker]

On Sat, Aug 26, 2006 at 10:01:16PM -0700, Corey Hickey wrote:
> Munzuk wrote:
> > Rich Felker wrote:
> >> I have no idea what you're talking about here. Don't worry about the
> >> right words, just explain the phenomenon frame-by-frame.
> >>
> >> Rich
> >>
> > 
> > well, let's try that, look at your left, then move your sight from there to 
> > the rigth slowly (about 5 seconds from shoulder to shoulder), and in the way 
> > close the eyes for 0.25 seconds every second, record it all, save on your 
> > memory and then remove with braincoder the black parts where your eyes where 
> > closed, and thats the problem. :D
> 
> I think I know what's going on here.
> 
> Your source video is 12000/1001 fps. The video is composed mostly of
> duplicate frames (use the '.' key to step through frames and see what
> I'm seeing). For the reasons Loren described, some of the duplicates are
> in sets of four and some are in sets of five, depending on the scene.
> Like this:
> 
> ---sets of four---
> frames in file:   01.02.03.04.05.06.07.08.09.10.11.12.13.14.15.16...
> frames visible:   01.01.01.01.02.02.02.02.03.03.03.03.04.04.04.04...
> visible framerate: 30000/1001 (12000/1001 divided by 4)
> 
> ---sets of five---
> frames in file:   01.02.03.04.05.06.07.08.09.10.11.12.13.14.15.16...
> frames visible:   01.01.01.01.01.02.02.02.02.02.03.03.03.03.03.04...
> visible framerate: 24000/1001 (12000/1001 divided by 5)
> 
> 
> When you watch the original file, the motion is reasonably smooth--not
> really like 120000/1001 fps, of course, but like 30000/1001 and 24000/1001.
> 
> You want to reduce the framerate to 24000/1001, but you really can't do
> that without skipping some frames. 120000 is the least common multiple
> of 30000 and 24000. Picking either of the original "visual framerates"
> and trying to force the whole movie into that framerate is bound to
> produce either skipped frames or duplicate frames, leading to some
> jerkiness.
> 
> Actually, now that I've written all that, I'm going to tell you that
> what I've just described isn't the real problem. I wanted to give you
> all that first, though, because most of it is prerequisite for
> understanding what's going wrong.
> 
> The actual problem is that mencoder's A-V sync code (where it describes
> whether it needs to skip or duplicate a frame) just isn't cut out to
> handle these repetitive patterns of frames that need to be skipped in
> order to get the desired output framerate. As far as I understand it
> (not well, but I might be correct), mencoder allows A-V desync up to a
> certain threshold, at which point it skips or duplicates only enough
> frames to get back below that threshold. Rather than skipping three out
> of four frames (or four out of five), the actual pattern is somewhat
> scattered. Therefore, often pairs (or triples, etc.) of frames from the
> original video that look identical get encoded into the destination
> file. Also, mencoder will skip/duplicate more aggressively when it
> detects that A-V sync is way off. So, sometimes more than three or four
> consecutive frames get skipped and one of the original visible frames is
> lost entirely.
> 
> This kind of A-V sync handling works decently well for most mencoder
> usage. Your case is somewhat unusual, and it falls outside the purview
> of what mencoder normally does. Is there a clean way to do what you're
> trying to do? Probably, but I could only speculate. You may have to
> describe exactly why you're re-encoding, and you may have to consider
> just leaving the original file alone.
> 
> Someone will probably correct me if I've analyzed this wrong.

IMO the situation is nowhere near this bad. Reencoding should give
(almost?) the identical pattern if you just omit -ofps and leave it at
120000/1001, as long as you _don't_ use -vf harddup. No ivtc is
needed of course.

If that doesn't work, Using -mc 0 or adjusting the value of -mc might
improve the situation.

Rich