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

[Corey Hickey]

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.

-Corey