I have been searching the forum for this topic, however there are still some questions I couldn't find an answer for.
1. I have been reading that Mediainfo doesn't show the correct frame rate mode when the video was converted with handbrake. But does it show the correct mode for mkv's that were ripped with Makemkv? In other words how can I be sure about the frame rate mode of the source?
2. What happens to videos that originally have a variable frame rate but where encoded with a constant frame rate?
3. Is there a way to detect whether this source for an already encoded video had a constant or variable frame rate?
I hope you guys can help me out.
+ Reply to Thread
Results 1 to 13 of 13
Apparently MediaInfo sometimes gets it wrong due to the timebase used by Handbrake, but I think I've seen it get it wrong for MKVs on the odd occasion. It only checks the first portion of video (as I understand it) and a single frame at the beginning with a slightly different duration can confuse it.
For the record MKVMerge uses a timebase that makes it accurate to the nearest millisecond, so for a video that's 23.976fps the frame duration is 41.7083333 milliseconds. Therefore MKVMerge uses a pattern of 41ms and 42ms durations to average the frame rate out to 41.7083333. I can't remember what timebase Handbrake uses (or MakeMKV for that matter) but it's that type of "jitter" that can throw a spanner in the works when it comes to MediaInfo detecting the correct frame rate and whether it's constant.
You probably can't be sure about the frame rate of the source when ripping DVDs with MakeMKV, but you can probably make sure they're handled correctly when re-encoding. Is that's where this question is heading?
If you want to look, you can open an MKV with gMKVExtractGUI, select the video track, choose the "timecodes only" option from the drop down list, and extract. It'll extract the timecodes to a text file that'll look something like this (for PAL):
PAL is easier to understand as even if the count doesn't start at zero the frames should alwys be 40ms apart (for constant frame rate). Not all timecodes are that easy to follow and it'll be a long list.
Or.... plan B.... open the MKV with MKVToolNixGUI and remux as a new MKV while specifying what you believe should be the correct constant frame rate. If the duration changes and/or the audio goes out of sync you've either specified the wrong frame rate, or it was variable.
Why are you asking the question? If MakeMKV has ripped a DVD and it's playing properly I wouldn't bother looking any further. If it's a re-encoding issue though, that's maybe a different story.
thanks for your reply. I was asking because I ripped a lot of my Blu-ray's and re-encoded them with handbrake. Recently I updated my system to Windows 10 and lost my presets. While I was setting up handbrake again I stumbled upon the frame rate option again. Now I'm not sure if I damaged the movies while reencoding. Does reencoding with the wrong frame rate mode (variable/constant) produce visual artifacts?
Handbrake uses a time base of 1/90000 for the frame rate when encoding to MP4. NTSC frame rates (24000/1001, 30000/1001) can't be exactly represented with that so Handbrake encodes as VFR (even if you specify CFR) and alternates timestamps as necessary to deliver the correct overall average frame rate.
Handbrake doesn't do this when encoding to MKV so I suspect MKV uses a numerator and denominator to deliver the exact frame rate.
I don't use Handbrake and I know many people advise using it in constant frame rate mode but I live in PAL land and I've still seen enough Handbrake'd NTSC constant frame rate encodes to be confident it's not always a good idea.
The problem with some older NTSC is the underlying frame rate changes. There's parts that Handbrake's Decomb filter would deinterlace to 29.970fps progressive (video) and parts that are IVTC'd to 23.976 progressive (film). So even if you choose "same as source" for the output, if you force a constant frame rate Handbrake converts the 23.976fps sections to 29.970fps by duplicating every fourth frame and it makes motion very "jittery". If there's only small sections of "film" it's not the end of the world, but I've seen Handbrake encodes where about 80% was film and it's not pleasant to watch.
Maybe variable frame rate is not always ideal for editing, but I'm not sure I can see any way VFR wouldn't be preferable to jittery motion in a situation like that.
Most Bluray video would be constant frame rate (it doesn't have different "underlying" frame rates) so forcing a constant frame rate wouldn't be a problem, and if you combine that with "same as source" you should be fine. If you specify a frame rate and get it wrong though, you'll force Handbrake to drop or duplicate frames which is bad.
And... I don't think it matters in the slightest whether you pick constant of variable frame rate for the output unless the Decomb filter is enabled. The Decomb filter is where the video is converted to variable frame rate. After it does it's thing it drops duplicate frames, hence the variable frame rate, and selecting a constant frame rate for the output gets Handbrake to put them back again.
If in doubt though, enable the decomb filter and use "variable frame rate, same as source" for the output. Even if the output is a bit variable, it's probably the only choice where nothing can go wrong. If you're confident your source is 100% film (or very close), you can disable the decomb filter or choose constant frame rate as the output. Leave the frame rate set to "same as source".
Last edited by hello_hello; 12th Aug 2016 at 09:07.
Thanks again. Now I am pretty sure about the settings for handbrake. Unfortunately I forgot the settings I used until now. I remember that the decomb filter was disabled and I always selected same as source. Is there a way to check if I was wrong about the variable/constant frame rate. Does handbrake leave traces in an encoded file? Or would I be able to see stutter effects with my bare eyes?
I think I provided some misinformation earlier, which I've deleted from my previous post so as not to cause confusion for anyone else.
I thought that when the Decomb filter is active it always deletes duplicate frames, even for progressive video. I ran some small test encodes though, and that appears to be wrong. I haven't done exhaustive testing but I encoded some 25i, 23.967p and 29.970p sources and the log file reported no dropped frames, so if that's what happens, and the Decomb filter is clever enough to only kick in and delete duplicates when the source is interlaced NTSC, it probably doesn't matter how you set the frame rate mode or if the Decomb filter is enable for Bluray video, as it'd be mostly 23.976fps progressive and therefore it wouldn't make any difference.
I can't at the moment, but sometime soon I'll try again on a video where I've duplicated frames myself, just to make sure the result today wasn't because the video was a bit noisy and the Decomb filter couldn't detect the duplicates. I don't think that's the case but I'll report back if the result changes.
If that is correct then the only way you could probably go wrong would be to specify the wrong frame rate, rather than "same as source", but chances are you didn't do that. Although leaving the Decomb filter enabled would probably be a good idea for NTSC sources that might be a mixture of film and video.
The way to tell if frames have been duplicated or dropped would be to step through them one at a time somewhere where there's constant motion. If there's dropped/duplicate frames, it should be easy to tell.
Last edited by hello_hello; 12th Aug 2016 at 11:10.
If that is correct then the only way you could probably go wrong would be to specify the wrong frame rate, rather than "same as source"
Ah... good news. Thanks for the effort you're putting into this.
* Unless more complex processing (e.g. frame interpolation) involved.
ffprobe -hide_banner -show_entries "frame=best_effort_timestamp_time" -select_streams v:0 -of "compact=nk=1:p=0" "temp.avi"
http://trac.ffmpeg.org/ticket/8460 (the "Off-Topic" part)
Well, you do realize “that this thread is 1257 days old”, as per the bold yellow warning below, right ? O_o
You're not even sure if the O.P. is still alive, or still living in the civilised world... For all we know he/she (sorry I can't bring myself to use those mind-bogglingly convoluted “gender neutral” pronouns) could have relinquished all possession of electronic device and went on living as a hermit hunter in the wilderness. Or he/she could have drastically upgraded his/her knowledge to the point of now being an active ffmpeg developper.
“How old was I when I said that ? [...] You're talking to me about 8 years ago... ‘You said that, at the age of 6, you liked to jerk off...’ I no longer jerk off, I'm 41. Life evolves, brother !”
– Jean-Claude Van Damme