I wrote it. Works with avisynth 2.6, possibly others. Converts a VFR video track with matroska v2 timecodes file into a CFR video track at the requested framerate. Includes customizable thresholds and dup/drop tracking so you can tell how good a job you did. Documentation and source code is included. Modified BSD license.
http://www.mediafire.com/?a51pifo438i7hdb
I've used it with grunt's ExactDedup, for which it's good for dejittering KKaptures and mupen internal captures. I've also used it with JPC dumps, Dolphin dumps (you need my a/v sync hack to get timecode files), and just plain old FFMS.
The internal Dolphin dumper on sync mode uses the same dup/drop algorithm with fixed thresholds and fixed framerate (exactly 60/1 for NTSC or PAL60, exactly 50/1 for PAL50). You can be slightly more accurate with this plugin.
Most people probably won't be interested in this.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
What does this do that ffvideosource() with the "fpsnum" and "fpsden" arguments defined doesn't?
I've used ffvideosource() on a vfr video and defined fpsnum and fpsden to convert to cfr, which seemed to work well for me. Is there something it does wrong?
What does this do that ffvideosource() with the "fpsnum" and "fpsden" arguments defined doesn't?
I've used ffvideosource() on a vfr video and defined fpsnum and fpsden to convert to cfr, which seemed to work well for me. Is there something it does wrong?
The basic operation completed is the same, but there are a number of differences.
1) My plugin works on anything with a matroska v2 timecode file, which can be from FFMS or from other sources.
2) My plugin interprets the timecode for a frame as the frame's start time, which is consistent with dedupc/exactdedup, jmd streamtools, mpc-hc playback (with file muxed by mkvmerge or x264). FFMS interprets the timecode for a frame as the frame's center time, which can cause some weirdness: http://doom10.org/index.php?topic=25.msg9997#msg9997
3) My plugin has a number of facilities to determine how "correct" the VFR->CFR conversion was. You get a listing of exactly how many dups and drops there were, a measure of the error in frame start timing, as well as a visual graph you can watch to see how the VFR times and CFR times line up. If your source was originally at some point cfr or mostly cfr, you can exactly recover that with some manual observation and TimecodeFPS. With FFMS's conversion, if you chose 60fps for a 59.94fps file, it may be difficult to determine that anything went wrong at all. Among the possible applications are use with threshhold based (non-exact) dedup to recover 23.976fps material from a dirty analog source (eg VHS tape). (Although current "interlace scanning" methods for that are pretty good.)
