Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
19th December 2013, 09:14 | #1 | Link | |
Registered User
Join Date: Sep 2013
Posts: 7
|
HandBrake wrongly setting VFR
I usually use ffmpeg to encode videos with x264, but I tried out HandBrake recently because I'm lazy. Still has all the x264 options, but it's easier in some ways.
Anyway, I notice that some of the videos produced by HandBrake are identified by mediainfo as Variable Frame Rate. Frame rate : 23.976 fps Minimum frame rate : 23.974 fps Maximum frame rate : 23.981 fps I found this on Handbrake's website: Quote:
|
|
19th December 2013, 14:46 | #2 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
I'm pretty sure the video is actually constant frame rate, but it's some Handbrake/MP4 oddness I don't really understand, and not being a Handbrake user or a fan of MP4 I've not tried too hard to work it out. Maybe something to do with the way the first couple of frames are muxed..... I'm not sure.
If you check Handbrake's log file it'll tell you it's outputting a constant frame rate...... and if the problem is the one I think it is, it'll go away if you switch to MKV as the output container instead of MP4. DVDs can be a mixture of film (23.976) and NTSC (29.970), which would make the frame rate variable. Hence filters for AVIsynth such as TIVTC, as with AVISynth you pretty much have to use a constant frame rate. If you use a constant frame rate and the video happens to be a hybrid, I've no idea how Handbrake decides which frame rate it's going to use. I assume your quote from Handbrake's website is telling you if Handbrake outputs variable frame rate and your player doesn't like it, try forcing a particular frame rate. I don't fully understand how Handbrake's filters work in relation to each other, and I live in PAL-land anyway, but there's more info here: https://trac.handbrake.fr/wiki/Telecine https://trac.handbrake.fr/wiki/DeinterlacingGuide |
19th December 2013, 16:26 | #3 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
The handbrake devs say this has to do with the timebase handbrake uses for the timecodes. It's always 90000 and thus there is a slight jitter when trying to achieve constant 23.976 (24000/1001)fps. This is supposedly also true for DVDs, Blu-Rays and some other digital formats which means calling their framerates "constant" would be a simplification (I don't know if this is actually the case and I wouldn't be surprised if devices were to round them back to the constant rates).
90000/3753 ~= 23,981 90000/3754 ~= 23,974 You see that with 90000 as a base for the timecode calculation you cannot achieve exact 24000/1001 fps, so in the stream it switches between these two, i.e. the file uses a variable framerate, strictly speaking. |
19th December 2013, 18:18 | #4 | Link |
Registered User
Join Date: Sep 2013
Posts: 7
|
Sneaker, your answer could explain why this is happening, but why in the world would they pick a number like 90000? Never heard of such things.
hello_hello, DVDs can be a mix of those two framerates as you say, but not within a single title. So I don't think that's relevant to their claim that DVDs are "inherently VFR" |
19th December 2013, 18:25 | #5 | Link | ||
Registered User
Join Date: Oct 2008
Posts: 114
|
Quote:
Quote:
Last edited by JohnAStebbins; 19th December 2013 at 18:29. |
||
19th December 2013, 18:54 | #6 | Link |
Registered User
Join Date: Oct 2008
Posts: 114
|
Let me clarify something with regard to DVD. The DVD video stream can be thought of as "constant framerate". The output from the decoder is a series of interlaced fields at either 60hz (NTSC) or 50hz (PAL). In order to achieve 24fps progressive output (film), certain fields are repeated some number of times. These repeated fields can either be explicitly flagged in the bitstream (soft telecine), or they can be repeated prior to encoding (hard telecine).
In mixed framerate DVD content, these repeats are just enabled and disabled as needed to change the framerate. The process of converting the repeated fields back to film rate is called detelecine. The simple version of this simply repeats the fields exactly as specified in the stream. But this does not reproduce the original film rate very accurately. In telecined content, every other frame has a different duration (one frame is 2 field durations, and the next is 3 field durations). A smarter detelecine will reproduce the film rate more exactly by giving each frame an equal duration of 2.5 fields. Since a field duration is 1501.5 90khz ticks (NTSC), 2.5 fields is 3753.75 ticks. Since this is not an whole number, it introduces another form of variable framerate. The actual duration will be rounded up to 3754 ticks for 3 frames, then rounded down to 3753 for 1 frame. Hope this helps. |
19th December 2013, 18:57 | #7 | Link | |
Registered User
Join Date: Sep 2013
Posts: 7
|
Quote:
I realize shows were captured with multiple frame rates, and they still are, but I don't believe they are ever mastered as such, because it's not supported in the DVD spec. Would you happen to have any examples of a disc that is encoded with VFR? |
|
19th December 2013, 22:27 | #13 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
I don't know why, but I'd be willing to bet if you switch to MKV, MediaInfo will report a constant frame rate.
http://forum.videohelp.com/threads/3...=1#post2262501 Quote:
Video tends to be either one or the other, and for video which contains both it tends to be mostly one or the other. I tend not to think of it as variable frame rate either, but more as two different constant frame rates, however the way Handbrake's Telecine filter works, at least the way I understand it after having skimmed over the info in the page I linked to, it can cause the output frame rate to vary unless you specify a particular, constant frame rate. This article gives Handbrake a mention near the end. http://www.pagetable.com/?p=484 |
|
19th December 2013, 22:39 | #14 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
While MediaInfo will probably report a constant rate practically all 23.976 fps mkv files will also have jitter. Additions to the mkv spec to work with timebases for files without jitter have been made "recently" but I don't know any software that can actually create files using those (and in turn there's probably no player that could read them correctly).
|
20th December 2013, 11:58 | #15 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
I remember using ffdshow's on-screen display to check frame rates a few times and found it interesting the way they varied according to the muxing program used (when specifying a frame rate while muxing). They all seemed to have a different way of doing it. If I remember correctly, for 23.976 MKVMerge would alternate between frame durations of 41ms and 42ms in some sort of repeating pattern.
I looked at an AVI after remuxing it as an MKV while specifying a 24000/1001 frame rate, and the frame duration displayed by ffdshow changed according to the splitter/player used. MPC-BE with Haali splitter: frame durations alternated between 42ms and 41ms using a pattern something like 2:1,3:1. MPC-BE with internal splitter: constant 41.7083ms frame durations. MPC-HC with Haali splitter: constant 41.7083ms frame durations. MPC-HC with internal (LAV) splitter: constant 41.7029ms frame durations (which doesn't make sense to me). Now I'm more confused than ever. After extracting the timecodes from the MKV, it would appear the combination of MPC-BE and Haali splitter is the one which displayed the video using the original frame durations, although given that's not constant, maybe it's not a good thing. Why the frame durations change according to the combination of splitter and media player used, I have no idea. The timecodes looked like this: # timecode format v2 0 42 83 125 167 209 250 292 334 375 417 459 500 And to confuse me even more, after remuxing the same AVI without specifying a frame rate, the MPC-BE/Haali combination resulted in a constant 41.7083ms frame duration, even though when I extracted the timecodes they looked exactly the same as above. |
Thread Tools | Search this Thread |
Display Modes | |
|
|