[Bug] Hitfilm has problems with framerates

edited June 7 in Pro Support

Hitfilm 2017 has more problems with the buggy VFR output from Handbrake than Hitfilm 4 used to. That seemed to read the intended framerate, take that as Constant and ignore the variations and it worked out fine. While that was actually a bug, it cancelled out the Handbrake bug.

tl;dr; Hitfilm's new way of handling VFR files shows up a Handbrake bug because when it incorrectly rounds up 23.976 to 24fps: video and audio lose sync.

The fact that people have been using Handbrake to transcode files before means that if they do so now, or open HF4 projects with Handbraked clips in them: they're in for problems with video and audio sync.

Thanks to @NormanPCN who confirmed it wasn't just on my PC that Handbrake was playing up.

This was using a clip from Tobias's (Surfaced Studio on YouTube) recent tutorial on Hitfilm tracking, where he evidently also discovered the Text bug when you can't actually type > or < into the text box and provided a .PNG file for the arrow. You can cut'n'paste > or < in there though.

As his provided clip performed brilliantly in Hitfilm and scrubbed and played like velvet, I wondered what had been used to produce it and also if it could be improved even further in Handbrake.

After trying many, many settings that only ever produced VFR output, I discovered that even doing absolutely nothing in Handbrake (not even changing the Main Profile, as in the video) would always produce VFR output. And that output did not perform well in Hitfilm. Playing with other fast decode settings etc. only made the file bigger and it still didn't perform as well as the original. I want whatever Tobias used to export that clip. :)

So with Handbrake being completely useless: I wondered how Hitfilm coped with the CFR>VFR output that Handbrake insisted on providing. Answer: Not as well as you'd hope.

Note: The two clips have the same average bitrate, are nearly identical in size, but one plays as smooth as butter, the other...doesn't, so it's not just bitrates and files sizes and profiles that make a difference to performance. However the alphabet salad of settings that Handbrake provided did nothing useful.

https://www.youtube.com/watch?v=4bYpLAGXlTc

Comments

  •  Update: Even forcing the properties of the Handbraked file that Hitfilm thinks is 24fps to 23.976fps, deleting all the composite shots, setting the project settings explicitly to 23.976, creating a composite shot with the real 23.976 original file in it and dragging in the forced-to-23.976 HB file in it and setting Blend:Difference produces: Out of sync audio and video.

    So once it's wrong, it stays wrong.

  • edited June 7

    I'll add some nerdy tech details here.

    Handbrake (HB) does seem to have an issue generating a proper constant frame rate (CFR) AVC file at 23.976 (24000/1001). I know it has no such issue at 29.97 and in this test instance I tested 24.0 and that was fine as well. I tested ffmpeg and it has no issue transcoding a 23.98 CFR AVC source to a 23.98 CFR AVC result.

    What did HB do? HB generated frame timings with a repeating pattern that oscillated around the ideal/perfect CFR frame timing. The file time base was 90000 and the pattern group was 1 frame with a delta of 3753 (23.9808) and 3 frames with a delta of 3754 (23.97442). So the Goldilocks frame timings were one frame a little slow and others a little fast and the net result is just right every 4 frames.

    Which is why something like Hitfilm (HF) 4 which assumes CFR can work with files like this from Handbrake. They are effectively CFR. As long as HF uses the proper CFR framerate all should be fine.

    edit: You may still get some short sync issues when slicing the media up but these time diffs within a 4 frame group are super tiny.

    VFR video goes out of sync normally because the variation in the frame timings does not oscillate around some ideal value. Say a phone or computer screen capture app is trying to render 30.0 fps. The encoder often cannot keep up with real time and the video must be real time so the encoder lets the frame rate slip from ideal to maintain real time. So the instances where the encoder slows the frame rate cause a cumulative sync issue if an app reading said file uses CFR for the file timing.

    2017 supports VFR but seems to have an issue here with the Handbrake output in this case.

  • AdyAdy Staff

    @Palacono - Bug logged.

Sign in to comment

Leave a Comment