The VFR thing was actually my suggestion, so sorry about that, although Zathor implemented it for just the OneClick encoder so far, which I don't use myself, but I suspect it relies completely on the source being an MKV. If you remux the MKV as a TS file with TSMuxer and use that as the source, the problem will probably go away.
Should this be a cause for concern?
Quote:
0
33 (33 ms)
83 (50 ms)
117 (34 ms)
167 (50 ms)
200 (33 ms)
250 (50 ms)
284 (34 ms)
334 (50 ms)
367 (33 ms)
417 (50 ms)
450 (33 ms)
501 (51 ms)
|
Is the frame rate uneven because the source was telecined (pulldown flags), so instead of each frame having the same 41 point something ms duration, there's a 23.976fps frame followed by one with a 23.976fps and a half duration, or something similar....
I'm not sure if Zathor intended the VFR encoding to apply to DVD video, and I'm not sure it'd work correctly as it is anyway, as by default ffms2 and Lsmash don't honour pulldown flags, so unless OneClick instructs them otherwise......
TS files should be indexed with DGIndex and pulldown flags honoured as expected. If the repeat field argument isn't added to the script for ffms2/Lsmash by MeGUI, there's a good chance NTSC DVDs won't be handled correctly.
It probably explains the source detector thingy bitching about not being able to determine the source type in the log file. I assume it only understands 29.97fps or a constant frame rate, or something like that.
Maybe it'd be better if the indexer/decoder created the timecodes file rather than extracting with MKVExtract. I don't know about Lsmash, but ffms2 can write timecodes while indexing. I wonder if ffms2 would've written a timecodes file with more evenly spaced frames? It'd be silly if it didn't.
Edit1: I checked a few VFR MKVs and they have no default duration. For me, x264 usually writes the output to MKV and I remux with MKVToolNixGUI without specifying anything, and none of my VFR MKVs have a default duration. Maybe you should remove it.
Edit2: I just read sneaker_ger's link. Removing it might be a bad idea (and now I've thought about it, I doubt it's the problem).
Edit3: I searched old log files for "timebase", and for standard "hybrid" VFR NTSC, x264 is quite partial to a timebase of 1/1000000000. It also chose 1001/360000 on occasion. I didn't go nuts searching, but for normal VFR NTSC, I didn't see any other timebase.
While we're on this subject.....
I still don't completely understand how the timebase effects the way media players interpret the frame rate. I encode DVDs as VFR now and then (using TIVTC) and I always let x264 set the timebase. It set 1/1000 for bowlingbeeg's video, probably because the frame rate isn't a normal type of variable (combinations of 23.976fps and 29.97fps).
Here's a VFR example. If someone could help me understand what's happening it'd be appreciated. Normally for combinations of film and video, x264 sets a timebase and I'm pretty sure ReClock knows when the frame rate is film or when it's video. The example below is not a standard thing. It's a combination of 25fps and 59.94fps. x264 chose 1/199900 as the timebase. This was the timecodes file:
# timecode format v1
Assume 59.940060
0, 1213, 25
2646, 2894, 25
3020, 3155, 25
3268, 5984, 25
9604, 9668, 25
9744, 9861, 25
16850, 17178, 25
35429, 38675, 25
44475, 44889, 25
51266, 52322, 25
61777, 63079, 25
So my question is, why do MPC-HC, Reclock and ffdshow all report the video to be 25fps from start to finish? It's probably a good thing, because I recall the few times I set a timebase myself it caused ReClock to do odd things, so I'm sure x264 knows best (normally). I'd just like to understand it a bit more. MPC-HC and ffdshow count the frames at 25fps, so for the 59.94fps sections, ffdshow gives two or three frames in a row the same number. The screenshot below is from a 59.94fps section.
