[MEncoder-users] Five inverse telecine filters to choose from -- four broken, one a little crazy
Christopher "Monty" Montgomery
xiphmont at gmail.com
Wed Sep 26 16:38:07 CEST 2007
All of detc, ivtc, pullup, filmdint exhibit bugs that make them
useless on a fairly simple file with which each should work correctly.
The only inverse telecine filter that works is 'divtc' (although it
guesses wrong alot), which is slightly odd because the video is and
always was progressive.
mencoder built from 2007-09-25 SVN snapshot.
Details:
The file in question is the infamous 'Backstroke of the West' pirate
of _Star Wars Episode III: Revenge of the Sith_ with the hilarious
subtitles. This is not the original ISO, unfortunately, this is a
torrent of an avi transcode that was... not particularly well done.
Sadly, it's the only copy that seems to still be around years later.
The ripper appears to have independently ripped, telecined, scaled and
transcoded each VOB, then pasted the video together. Aside from a
couple of other noob errors that I can correct, this means the frame
number of the dupe telecine frame shifts at the boundary of each VOB's
video contribution. It is a hard dupe frame in a standard 4->5
precompression. The video is progressive. In the first VOB, the dupe
frame is #1, in the second the dupe is #3, in the third it's #2, etc.
Leaving out irrelevant bits of the video filter chain, the bug report
is as follows:
framestep=1:
For some reason, I have to have this after the inverse telecine filter
or results are consistently much much worse (the filters lose telecine
sync much earlier). I don't understand what it's necessary...
All of the below filter chains have "framestep=1,softskip,harddup"
following the inverse telecine filter.
detc:
detc=dr=0
Never drops any frames. This wouldn't be the correct choice anyway,
but the fact that it never manages to drop a single frame is wrong as
far as I can tell from the docs. I get "Skipping frame" from later in
the filter chain every fifth frame like clockwork.
detc=dr=1
Works correctly for entirety of the first 'VOB', never adjusts the
dupe frame shifting at the first boundary. It drops the incorrect
frame for the entirety of the rest of the video.
detc=dr=2
Same as above
detc=dr=2:am=0:fr=<n>
Regardless of the number given to fr, detc interprets it as 0, making
am=0 useless.
ivtc=1
Same as detc=dr=1. First VOB is fine, never recovers from the first
VOB boundary.
pullup
pullup=::::-1:
etc...
Haven't succeeded in getting it to do anything whatsoever
filmdint
filmdint is weird; it constantly gets mildly confused in very blurry
high-movement action sequences and recovers right away. Despite the
once every few seconds 'wrong frame' choice, the output looks good.
Then is seems to settle into a rut and stops shifting between which
frame number it thinks is the dupe. By the time it hits the first VOB
boundary, it will not change its choice and it continues on dropping
the wrong frame for the rest of the video.
the fast=<n>, diff_thres=<n> and sad_thres=<n> options change the
behavior of the filmdint filter substantially, but only for the first
few minutes of video. Regardless the optional setting, it eventually
settles into its rut, loses sync at the VOB boundary and never
recovers.
divtc
The only filter that does not get stuck on the VOB boundaries and
obeys enough of its documented options that I can tune it to good
behavior. By default, it is very twitchy and chooses the wrong
telecine frame for several seconds at a time, but it always eventually
recovers.
The documentation states "Inverse telecine for deinterlaced video."
I assume there's a good reason for that, but this video was never
interlaced and this is the only filter that actually works. I didn't
try it for the longest time because it said it was for deinterlaced
video....
I realize this bug report is leaving out essential details. Contact
me, I'm happy to provide all the additional documentation needed to
debug. For the record, all these behaviors are 100% deterministic.
Monty
More information about the MEncoder-users
mailing list