[MEncoder-users] regarding skipped/duplicate frames during framerate conversion

[rob pfile]

i had posted last month regarding 60p->24p conversion of film-source  
ATSC material. bottom line is that my transcodes were full of the  
occasional frame duplications and skips, which i always took as a  
sign that the decimate filter was not always dropping the right  
number of frames. in my source material, there are lots of places  
where titles have been rendered at 60fps over the 24fps film, and low  
motion scenes, which cause decimate to pretty regularly emit extra  
frames, leading to mencoder having to skip frames. that was my  
motivation to write my own custom filter which drops exactly the  
right number of frames to get from 60fps to 24fps - i figured at that  
point my frameskips/dups would be history.

but even with this filter, i am seeing a repeated pattern of  
duplicate and skipped frames, with a skip following just 2 or 3  
frames after mencoder decided it had to duplicate one. i looked into  
this a little bit and found that the culprit is the code that's  
looking at v_timer_corr. for whatever reason, v_timer_corr goes  
through a repeating pattern which touches -1001/24000s and 8mS at the  
extremes, but never deviates past those bounds. when v_timer_corr  
hits -1001/24000s, the code emits a duplicate frame, and then a  
couple of frames later, v_timer_corr exceeds +1001/24000, and a frame  
is skipped. this goes on forever, and the output looks horrible  
unless i hack that code to allow a frametime's worth of timer  
difference, at which point it looks okay, and any skips/dups are  
purely due to PTS differences.

i also noticed a similar behavior when transcoding film-source 1080i  
material. in this case the transport stream is actually soft- 
telecined, but the flags are not consistent and so mencoder is  
constantly losing and regaining lock on the telecine pattern. for  
this reason, i've had to use -fps 30000/1001 and pullup,softskip - 
ofps 24000/1001. but i noticed in this case that libmpcodecs/video.c  
is returning the frametime that's called out in the mpeg header,  
which is changing between 1001/30000 and 1001/20000, even when  
mencoder is called with -fps 30000/1001. this would be fine if the  
frametime averaged out to 1001/24000 as it would if the source were  
telecined properly, but there are long runs of 1001/30000 frames and  
this has a similar effect on v_timer_corr, leading to unnecessary  
skips followed immediately by dups. at least this is not periodic as  
with the 720p material, but it will happen maybe 10 times over the  
course of a 30 minute show.

so... from a user's perspective, is there anything that i can do from  
the command line to prevent the above behavior? -mc 0 only seems to  
affect v_pts_corr, and actually these transport streams usually have  
a 200-400mS difference between the audio and video PTS, so i want  
mencoder to fix the initial a-v sync. and if i use -noskip on the  
1080i material which is unedited, the non-telecined material  
(commercials) seems to bork stuff up badly and mencoder eventually  
crashes with "too many video packets in the buffer".

the 1080i stuff with the frametime seems like it might actually be a  
bug, but i'm not sure at all about the 720p case. does it make sense  
to allow the user to specify a percentage of the frametime on the  
command line to allow for wider v_timer_corr excursions?

thanks,

rob