Constant Framerate Support ( VFR Desync Issue Fix )

[Fire]

This is an issue that XSplit also suffers, which I wrote up a while ago on their forums: https://www.xsplit.com/forum/viewtopic.php?f=92&t=13711

Basically because these are considered delivery formats they're not intended to be edited, and as such the giants like Sony and Adobe have no reason to add "support" for VFR in these containers / codecs / etc. They expect CFR and that's that.

Pretty much everything is in the thread I linked, so I'll just re-iterate the important part:

x264 itself does not do any frame interpolation or duplication, that's up to the parent application that feeds into it ( FFmpeg or the XSplit mixer ). FFMpeg does frame duplication to match the fps parameter if it exists.

Frame dupe / decimation to keep a constant framerate in combination with the fps flag will fix desync issues in editors.

 

[Lain]

I was actually thinking about adding an option for duplicating and "forcing" CFR. One being the CTS issue which arises from variable framerate streams, another being exactly that, the fact that some editing programs expect only CFR. I do plan to experiment to get it working at some point. It could however cause more issues (such as more encoder work) that make it not really worth doing, I don't know, I'll have to experiment and see.

I'm fairly sure this doesn't have anything to do with desync though. The desync issues should really be an entirely different thing all together.

 

[Fire]

I was actually thinking about adding an option for duplicating and "forcing" CFR. One being the CTS issue which arises from variable framerate streams, another being exactly that, the fact that some editing programs expect only CFR. I do plan to experiment to get it working at some point. It could however cause more issues (such as more encoder work) that make it not really worth doing, I don't know, I'll have to experiment and see.

I'm fairly sure this doesn't have anything to do with desync though. The desync issues should really be an entirely different thing all together.

From my testing the desync is due to the track being shorter than expected because it's assuming all frames are of equal length ( No timestamp support ). If the framerate varies too much in the file, the video track won't even parse.

( Tested: Vegas 11, Premiere Pro CS5 )

As for more encoder work, x264 already supports CFR encoding, it just doesn't do anything to make up missing frames or drop slight overages. If memory serves, when your source is running at 60 and you then force the encoder to 30 with the fps flag, the resulting file works fine ( as long as the source never hiccups and drops below 30 ) as it's cfr'd to 30 ( I believe I have images of that on the splitmedia thread as well ).