When one transcodes a standard commercial DVD or transcodes a file containing older codecs (e.g. h.263, and low-quality '.flv' videos from YouTube, etc),to a destination of h.264, and chooses 'same as source' (the normal default) for 'Framerate' drop-down,the resulting output file will become "VFR". [VFR='variable frame rate']

I see this behavior on both Linux-version and Windows-version of Handbrake, and have been seeing thison the normal versions available over the past six months.

My 'question/issue' is:

Is this a possible 'bug' or is this a 'feature'? (or stated another way)Is this what users want and would expect?

I would have thought that 'same as source' would/should result in a 'CONSTANT' framerate, for the output,since the source was a constant framerate.

EDIT: Maybe better wording would have been "variable:<= to src", rather than "same as source".

But, to ACHIEVE a constant framerate on the destination, I've recently learned that one MUST'force' a constant framerate, by adjusting that 'Framerate' dropdown in the 'Video' tab to oneof the non-default 'specific' values, such as "29.97(NTSC Video)", or whatever.

[I wasn't sure whether to post this in one of the other forums. Feel free to move it, as needed.]

TIA...

S Slim

Last edited by Sarasotaslim on Mon Apr 04, 2011 8:10 pm, edited 1 time in total.

You would be surprised how many sources are variable frame rate. DVDs *are* VFR for example. The framerate that you think it is just designates a nominal rate. The real rate is completely defined by timestamps in the stream. And there is a timestamp per frame. The granularity of those timestamps is 1/90000 seconds. In order to faithfully reproduce those timestamps, you have to do VFR output.

If your source truly is CFR, the VFR output will match it timestamp for timestamp. So the timing won't be any different. It's just header information that informs the decoder ahead of time that it *may* encounter variable frame timing.

FPS: Some newer transcoding software will do variable framerate (VFR) if you don't specify a hard framerate. Veetle's player can sometimes run into issues playing back VFR smoothly. You should set the final framerate to be the same as the source framerate.

Note at beginning, they say you need to specify a 'hard framerate', but then later say to use 'same as source'.

After some discussion among broadcasters in a forum post there, we finally concluded that no one canrecall seeing such any lack of smooth playback on Veetle from any pre-transcoded files that we NOW notice DO have VFR coded into them. That thread is at this URL:http://forums.veetle.com/forums/viewtop ... f=8&t=2792

Hi,the VFR topic is also important to me. I've already encoded a lot of DVDs with 0.9.5 and the "Same as Source" setting.Thankfully my BD-Player LG BX580 has absolutely no problems playing these files. But I also heard that most other players have problems.That concerns me, because I want to be sure, that my next players in the future will play these files as well.

I understand now that MediaInfo shows only the nominal fps and not the real. It reads the header of a file. Would it be possible to remove the VFR flag in the header of the MKV file without encoding? MKVmerge also changes the header when remuxing but there is no option to remove a vfr flag. Do you know a way to do it?

The VFR information is encoded in the h.264 SPS VUI num_units_in_tick, timescale and fixed_frame_rate fields. For handbrake's VFR output, these are set to:num_units_in_tick=1time_scale=90000*2fixed_frame_rate=0

For CFR they should be (assuming 23.976fps nominal frame rate):num_units_in_tick=24time_scale=1001*2fixed_frame_rate=1

The SPS (and PPS) is encoded into the mkv in the track private data portion of the track header. So you would need to find (or write) a program to extract and modify this. Keep in mind that doing so creates an invalid stream. In the future you may find you'll have more trouble playing a stream modified in this way then you would have if you just left it alone.

For handbrake's VFR output, these are set to:num_units_in_tick=1time_scale=90000*2fixed_frame_rate=0

Is this the location where MediaInfo is looking for VFR or CFR?

Other files not created by handbrake are not recognised by MediaInfo as VFR. Even the vob and m2ts files of commercial DVDs and BDs don't show a VFR information, at least I never saw it. Why? Are these tracks invalid as you mentioned?

What was different with 0.9.4 that MediaInfo didn't see the VFR Information?

I really like handbrake and I don't know a better program for encoding my DVDs. But because of the compatibility issues with many players I don't know what the best setting is to ensure best compatibility for many years? Using a specific framerate setting without VFR? At least I never noticed any stuttering or async when using a specific fps CFR. (In contrast I noticed stuttering with 'same as source' + deteline on.)

For handbrake's VFR output, these are set to:num_units_in_tick=1time_scale=90000*2fixed_frame_rate=0

Is this the location where MediaInfo is looking for VFR or CFR?

Since I haven't looked at MediaInfo's source code, I don't know what they look at. But this information from the SPS seems like the most likely candidate.

Other files not created by handbrake are not recognised by MediaInfo as VFR. Even the vob and m2ts files of commercial DVDs and BDs don't show a VFR information, at least I never saw it. Why? Are these tracks invalid as you mentioned?

DVDs are mpeg2 and don't have these exact fields. But there are similar flags to indicate whether the stream has multiple frame rates. In either case, the authors may be taking some liberties with the specification. I can't find anything in the specs that define what should be flagged if the media is mostly CFR but has a few splice points that result in short or long frames. These flags are provided primarily as an aid to the decoder so that it can manage buffer levels properly. If the variance from true CFR is small, flagging it as CFR wont break the decoder.

What was different with 0.9.4 that MediaInfo didn't see the VFR Information?

0.9.4 set the SPS fields as if it were doing CFR output at the nominal frame rate we detected in the input stream. One of the problems with this is that x264 doesn't do proper rate control if you don't tell it you are giving it VFR input. That means it doesn't hit it's target bitrate or RF factor. This is probably less of a problem for BD sources than for DVD. I've never seen a BD source that switches back and forth between NTSC telecine and interlaced sequences the way many DVDs do. But we can't predict what the characteristics of the stream are going to be without scanning the whole stream which would be time consuming. FYI, a DVD that is telecined can properly flag that it is constant frame rate, while the output HandBrake will generate will still be VFR. A telecined sequence when detelecined results in 24fps progressive frames, while a interlaced sequence when deinterlaced results in 30fps. So a DVD that switches back and forth between telecine and interlace can be correctly flagged as 30fps CFR, but result in VFR after filtering. This happens all the time with DVDs.

I really like handbrake and I don't know a better program for encoding my DVDs. But because of the compatibility issues with many players I don't know what the best setting is to ensure best compatibility for many years? Using a specific framerate setting without VFR? At least I never noticed any stuttering or async when using a specific fps CFR. (In contrast I noticed stuttering with 'same as source' + deteline on.)

Stuttering with 'same as source' + detelecine could be an indication of another problem and may have nothing to do with VFR. You should test that encode on a player that doesn't have a problem with VFR before placing the blame.

I encode everything with VFR and just won't buy any broken players. There are plenty of good ones to choose from. I'm very happy with my boxee box.

Stuttering with 'same as source' + detelecine could be an indication of another problem and may have nothing to do with VFR. You should test that encode on a player that doesn't have a problem with VFR before placing the blame.

I tested it with VLC/ WMP Classic and it stuttered. This is always the case when the detelecine filter is active and I don't choose the nominal fps. I don't know if VFR on or off makes any difference. If I choose 'same as source' the average fps indicated by MediaInfo is something like 22,65. It seems to me that the detelecine filter drops too many frames without replacing the gaps. But set to a nominal fps (e.g. 25) the resulting video is playing smoothly.

I encode everything with VFR and just won't buy any broken players. There are plenty of good ones to choose from. I'm very happy with my boxee box.

Plenty? I asked in another forum (hifi-forum.de) some users of different common BD-Players (Panasonic, Philips) to check out a sample MKV-file flagged as VFR. They couldn't play it. Also users with other modells reported problems with Samsung BD-Players. Furtunately my LG is playing it, but I don't want to stick to LG only because of this VFR issue. Interestingly my 'Samsung Wave II' mobile phone is playing it too, but its a little bit stuttering compared to CFR flagged videos.

If you know plenty modells that support VFR flags, please give me a list.

Stuttering with 'same as source' + detelecine could be an indication of another problem and may have nothing to do with VFR. You should test that encode on a player that doesn't have a problem with VFR before placing the blame.

I tested it with VLC/ WMP Classic and it stuttered. This is always the case when the detelecine filter is active and I don't choose the nominal fps. I don't know if VFR on or off makes any difference. If I choose 'same as source' the average fps indicated by MediaInfo is something like 22,65. It seems to me that the detelecine filter drops too many frames without replacing the gaps. But set to a nominal fps (e.g. 25) the resulting video is playing smoothly.

I also find the detelecine filter to be unreliable.But setting a hard framerate is a hacky workaround; detelecine is still dropping too many frames, but CFR is duplicating some of the frames that are left to maintain the target framerate (or, if detelecine doesn't drop enough frames, CFR will drop additional frames).Sometimes the result may end up even less smooth than with detelecine + Same as source.

I personally find that decomb + Same as source (i.e. detelecine off, telecine artifacts treated like interlacing artifacts) can be an equally suitable workaround for PAL sources or NTSC sources that are mostly 23.976 fps (e.g. Stargate SG-1).

Your detelecine issue sounds like it could be a bug. Needs looking into. But it would help to have a source I could reproduce it with. I haven't seen it.

List: boxee (and anything else based on Intel CE4100 platform), any apple device (adds a dozen items to the list), WDTV, acer tablets (and anything else based on nvidia tegra2 which adds dozens more to the list), xoom, samsung tablets. My dad has an old tvix that's always amazed me in it's ability to play anything I through at it give how old it is. These are just items I have personal experience with.

JohnAStebbins wrote:List: boxee (and anything else based on Intel CE4100 platform), any apple device (adds a dozen items to the list), WDTV, acer tablets (and anything else based on nvidia tegra2 which adds dozens more to the list), xoom, samsung tablets. My dad has an old tvix that's always amazed me in it's ability to play anything I through at it give how old it is. These are just items I have personal experience with.

The PS3 doesn't support MKV. And the other devices/ HTPCs on your list don't have a BD-drive, afaik. That's bad for me, because I store my files on BD-R's.I know of the 'HDI Dune HD' having a BD-drive, but I don't know if it's supporting VFR flags. The WD TV V2 is reported to have an issue with Audio Sync during playback with any MKV files encoded with the VFR flag (klick here).

Some sources are not sufficiently decombed/deinterlaced when only using custom decomb without detelecine.

JohnAStebbins wrote:Your detelecine issue sounds like it could be a bug. Needs looking into. But it would help to have a source I could reproduce it with. I haven't seen it.

I will look if I find a source file.

Edit:Do you know a tool with which I can scan a DVD or a file to determine how many percent of it are VFR or CFR? So I could decide which encoding settings in handbrake to choose. It would be nice to implement such optional feature in handbrake.

Archivar wrote:Edit:Do you know a tool with which I can scan a DVD or a file to determine how many percent of it are VFR or CFR? So I could decide which encoding settings in handbrake to choose. It would be nice to implement such optional feature in handbrake.

I was going to say that sounds like an expensive way to store movies. But a quick price check shows the cost per GB is pretty much the same as a 2TB HDD. Media prices have come down since I last checked that option. I like the convenience of having everything online on HDD. But to each their own I suppose.

Are the sources that you have detelecine problems with all PAL? If so, I think I can find something to reproduce the problem with. I just don't usually enable detelecine on PAL sources because it's a known problem and usually isn't needed.

25GB BD-Rs (Verbatim) here in Germany are still nearly twice the price per GB than a 2TB HDD (Samsung Story).But the price was never a crucial point for me. I have bad experiences with crashed HDDs and loss of many important files.So I decided to store every important file, such as favorite video files, on DVD-R DLs and BD-Rs. If a disc one day becomesunreadable, I have a minimum risk and loose only a small part of my collection...

Almost all of the sources that I encode with handbrake are PAL 25fps. There is a big number of films which benefit of the detelecine filter even with PAL (eg. The Little Rascals/Our Gang comedy series), but I have to make sure to choose a hard framerate to prevent stuttering and low nominal fps in the encoded file.

Archivar wrote:Edit:Do you know a tool with which I can scan a DVD or a file to determine how many percent of it are VFR or CFR? So I could decide which encoding settings in handbrake to choose. It would be nice to implement such optional feature in handbrake.

Not as far as I know.

Correction: there is a way to check this. Encode as CFR in HandBrake and look in the log for "CFR/PFR" - that line will tell you how many frames HandBrake had to drop or duplicate to reach the specified CFR. This isn't exactly a percentage, bit it'll give you an idea of how far the source is from the target framerate. Of course that information is only available at the end of the encode.

There isn't any "VFR" or "CFR" flasg in mp4, but only frame durations. MediaInfo checks the durations of all frames and then says some stupid things.HandBrake always uses a timescale of 90000, so this means that a 23.976fps video track can't have the same duration for all frame, the only way to have the same duration for all frames is to use a different timescale.