Inconsistent Performance

MRemple Posts: 24 Enthusiast

Can someone explain why Hitfilm Pro has inconsistent performance?

Here's what I mean...I can open a project one day (containing ProRes and Cineform footage only), and it will play very smoothly with no stuttering/lagging. The next day, I could open the exact same project and it stutters and lags and overall just does not play smoothly.

I am not using a proxy workflow. When it plays smoothly, it's needed. It happens even if I cache the timeline. There are no background processes running. This has happened with more than one project. I have noticed it on 4 different projects so far.

Computer specs:

Ryzen 2700

Windows 11 (Version 22H2 Build 22621.674)


Radeon RX580 (8gb) running AMD Adrenalin 22.5.1 (rolled back due to previous freezing issue)

1TB M.2 System drive

Separate external hard drives (7200 RPM SATA 1TB) for all footage and project files. Cache and pre-renders files on a separate internal HDD (7200 RPM SATA).


  • Andy001z
    Andy001z Lord EarthPosts: 3,632 Ambassador

    Without knowing how computer savvy you are, have you checked your task manager to ensure nothing is popping up in background that is sucking processor time away from HF?

  • MRemple
    MRemple Posts: 24 Enthusiast

    I like to think of myself as very computer savvy. I actually stated in my post that no background processes are running.

  • Triem23
    Triem23 Posts: 20,397 Power User


    You probably should Defrag your hard drives.

    Hard drives, in general, are something I am hesitant to recommend for video editing use anymore. Hard drives are much slower than SSDs and, especially with an external drive, you can get a bottleneck in the USB interface.

    Timeline caching writes individual files for every frame of the Timeline. This needs to happen, so, if you change something in seconds 3-to-10 of a Timeline the cache isn't rewritten for seconds 1-to-3 or 10-to-whatever. Since hard drives tend not to write files sequentially, especially if you're making changes to the Timeline and parts of the cache are being rewritten, you're potentially fragmenting the drive quickly, generating cumulative lags as the hard drive is now skipping around finding individual cached frames.

    Now, a manufacturer will tell you that a hard drive can transfer 6GB/s. This is a lie. The connection bus might be able to transfer 6GB/s but the average hard drive will be doing well to transfer 80-100Mb/s. You're using ProRes and Cineform files. Knowing the exact flavor of ProRes/Cineform will be helpful, but the bottom line is the data rate of a ProRes or Cineform file can easily outpace the sustained data rate of a hard drive with a single video track. Getting into multi layer Composites - especially if you're adding in audio tracks or other stills might just be too much data for the drives. At least you're splitting media across multiple drives.

    Defrag before every editing session. That should help a bit.

    Otherwise, knowing more about your project can help - resolution of project and media, frame rate of project, etc. MediaInfo reports on your source media will tell us a lot.

    Otherwise your CPU and GPU are both aging, but not bad. Putting your project media on an SSD would likely help.

    Info on HDD vs SSD.

    Info on intermediate codes, including Cineform and ProRes, including typical data rates.

    @NormanPCN you're the codec expert. If OP's media is still at 8-bit color depth/4:2:0 is there any advantage to ProRes or Cineform, or would they be better off with h.264?

    @MRemple knowing the sources of your video will help. If you're generating Cineform and Pro Res from a cinema camera, drone or DSLR/Mirrorless that's capturing 10-bit video and/or 4:2:2 or 4:4:4 color, and/or writing internally to Cineform/ProRes, then, yes, you're probably holding image quality by editing with those formats. If you're shooting on something creating 8-bit 4:2:0 video and transcoding to Cineform or ProRes as "correct" intermediates, you might be better off with high bitrate h.264. I believe it's only certain types of h.264 that Hitfilm hardware decodes, but it's Norman - tagged above - who is the leading expert on this sort of thing.

  • NormanPCN
    NormanPCN Posts: 4,385 Expert
    edited October 2022

    NormanPCN you're the codec expert. If OP's media is still at 8-bit color depth/4:2:0 is there any advantage to ProRes or Cineform, or would they be better off with h.264?

    If the OP source media is sourced from 8-bit 4:2:0, then there is no advantage to Cineform/Prores. In other words did they transcode to Cineform/Prores from 8-bit 4:2:0 media. If the Cineform/Prores contains 10-bit and/or 4:2:2 data then one is stuck with that media in Hitfilm as implemented.

    AVC 8-bit 4:2:0 media performs best on the Hitfilm timeline with hardware decode. Though the Hitfilm HW decode implementation is quite piss poor, it is still most times better than other stuff in Hitfilm, but it can be worse. Surprisingly. I recently tested Filmora (not pro) and their timeline wiped the floor with Hitfilm (same media, same composite, you have to composite a lot of media to easily expose). Scrubbing can be better with All-I formats but a short GOP encode/transcode to AVC would perform similarly in that respect (e.g. like NormanAVC).

    Hardware decoders (Nvidia, Intel, AMD) typically support AVC, HEVC, VP8, VP9, VC-1 and recently AV1. AVC is usually restricted to 8-bit 4:2:0. Some support 4:4:4. Hitfilm chooses to support only AVC in direct HW decode. If Hitfilm uses the OS decoder, like with media containing HEVC video, then the OS decoder may use hardware decode. This is out of Hitfilm control. I don't trust this Hitfilm/OS interface right now. It is hit or miss, but some media has major problems in Hitfilm when going through the Media Foundation (MF) API. Major stutters and blinking, but other apps (basically players) known to use the MF APIs do not have problems playing the same media. This may be point to that Hitfilm is not using the APIs well or properly.'re potentially fragmenting the drive quickly, ...

    This can depend on how the APP is doing their disk writes. One can help the OS be (more) efficient in disk cluster allocation.

    The system disk cache can mask fragmentation to some degree. It all depends on the dataset size and the free ram available in the system.

  • MRemple
    MRemple Posts: 24 Enthusiast

    Thanks to both of you for the detailed responses.

    I have been editing for over 20 years. So I'm actually coming from the Premiere/Resolve/Media Composer world. So my habit has always been to transcode all source materials to an edit friendly codec as those systems handle these codecs much better than AVC media (in my experience anyways). Probably past trauma from working in Media Composer where EVERYTHING had to be transcoded to DNxHD for it to pretty much even be playable in MC! ;-) As an old school editor, I'm wary of editing with H.264 files!

    That being said, the ProRes media that I am using was generated from a Ninja V recorder. The files are 4K ProRes 422, 10 Bit from a GH4. The Cineform files were transcoded from AVC footage, from a GH4 and a DJI Mini 2. These are 4K, 8-bit 420 files. I'm pretty sure they were transcoded to Cineform High. I have attched MediaInfo reports for both the Cineform and ProRes files.

    My HFP timeline is 4k, 24p. It is not complex at all. One video track, three audio tracks. No heavy FX. Just basic color correction and some dissolve transitions. There are 3 very simple Composite Shots in the edit as well, but these are basically just titles and motion graphics. I have attached a screen capture of my timeline for reference.

    Thanks for the help thus far and I appreciate any further input!

  • MRemple
    MRemple Posts: 24 Enthusiast

    Side note, I just did a test.

    I have the original MP4 media as well. So I took some of the same clips that I used in the video and placed these on the timeline, cut them to the same length, and added the same FX. No difference in performance. These stutter and lag as well. And they stuttered even without FX added.

    Strangely, the play quite nicely in the trimmer, but not in the timeline.

  • MRemple
    MRemple Posts: 24 Enthusiast

    One last note...

    I had the project closed for a bit and just re-opened it. Once a new timeline cache was created, it plays butter smooth! Could it just be something with the timeline cache system? Perhaps the hard drive where I store the cache files (which is separate from the System drive and the footage/project drive)???

  • Stargazer54
    Stargazer54 Posts: 3,967 Ambassador

    @MRemple You might check that you have "Use Hardware decoding if available" checked as On in the File, Options, Render panel. Note that there is also a hardware decoding checkbox you can set for individual clips by going to clip properties in the Media Panel.

    When I turn off hardware decoding in Options for footage I shot with my GoPro at 4K, the playback is laggy, but clears up if I turn hardware decoding back on. The footage is HEVC/H.265 at 3840x2160, 24p (with Project Settings set to match).

    However, if I bring in some 4K GH4 mp4 footage the hardware decoding option doesn't seem to have a whole lot of effect except that starting playback with hardware decoding off results in choppy playback for a few seconds but then the system catches up and it plays fine. With hardware decoding on, then proper playback starts quicker with no issue.

    Just to compare, my system is Win 10, Intel i7-4790K @4GHz, 32 GB ram, NVidia RTX 2070 Super, 8 GB VRam. Note that playing back 4K files makes my CPU run at about 50% and the GPU at about 60%.

  • NormanPCN
    NormanPCN Posts: 4,385 Expert

    The generated timeline cache is probably AVC media. Some on this forum I remember Cedric saying that AVC was used at least at certain frame sizes. Maybe at small frame sizes they use their proprietary lossless format that is used for pre-renders. Maybe who knows.

    What the timeline cache takes out (bakes in) is primarily effects, transitions and layer/track compositing. Like having one media file, on one track on the timeline and nothing else.


    re: trimmer. From what I have observed is that the trimmer never tries to use hardware decode, if the media supports it.


    I see some media is 24.0 and some is 23.98. Your timeline is one or the other. Hitfilm is going to want to resample some media file(s). Maybe that on the fly resample is causing some overhead.

    NINJAV_S001_S001_T001 is 24.0fps.


    The listed Prores file is 665 Mbps (mega bits per second). 665 / 8 => ~ 83 MB per second. 80+ megabytes per second. Video alone, no audio or anything else. Other stuff piles on. That is tough for a spindle drive to keep up with as Triem23 stated. Then there is the Ryzen 2700 trying to keep up with decoding (in Hitfilm). I've no idea what type of (whos) decoder Hitfilm is using for Prores. Timeline ingest is a known weak point in Hitfilm.

    I once did a 4K playback+composite test in Hitfilm and posted a thread this forum. My machine at the time had a spindle HD and I had to forcibly cache the media as it was too much for the spindle drive to keep up with.


    Given the extremely high bitrate source media, you might be better off with a Quality Proxy. Hitfilm generates a full rez AVC media files for quality proxies. Not really proxies as the term is commonly used. They are basically NormanAVC like encoding settings. I recognize myself. Then assuming the AMD hardware AVC decoder interface works worth a damn in Hitfilm you should be better off with little fuss beyond the extra proxy file(s). I directly comment on what I can test in Hitfilm, which is Nvidia.

    With a proxy the original source media will be used on exports.

  • Triem23
    Triem23 Posts: 20,397 Power User

    @MRemple the Trimmer just passes through video frames. Once media is on the Timeline, it passes through the Effects/Transform processing - even if you haven't changed anything, it still checks the values. Also, Hitfilm's anti alias on export is global - and with Hitfilm being OpenGL based I suspect video media are actually textured polygons. This would allow for the 3D workspace and account for the global AA, but would make the Timeline slower than the Trimmer. Devs haven't confirmed this, but, when I've tagged one to clarify they also haven't said I'm wrong.

    Norman raises a good point about mixing 23.976/24 media. Hitfilm conforms to Timeline when media is added, but with long takes that 1-frame-per-10-seconds confirmation adds up. Maybe a transcode to unify the frame rates before edit would help?

    Norman, Stargazer and I are also old-school and my own video from 5 years ago on optimizing media for Hitfilm suggests ProRes/Cineform/DNxHD. It's only after adding hardware decode and Norman's extensive tests that we started recommending h.264 as a useful ingest format - specifically for 8-bit 4:2:0 media.

    @NormanPCN I believe proxies are AVC media, but the cache is individual image files per frame - it was in Hitfilm 2021. I have a new PC but don't actually have Hitfilm installed (or any video software since I don't have a career after moving to Ireland) to double check, but doubt it's been changed. Writing video files for the cache - especially h.264 - would basically mean a cache can never complete. I'm 99% sure it's individual image files, which would exacerbate fragmentation on a spindle drive and potentially lead to more slowdown by constantly streaming individual frames.

    I'm also Nvidia.

  • NormanPCN
    NormanPCN Posts: 4,385 Expert
    edited October 2022

    @Triem23 Yes, proxies are MP4 media files with AVC video. Timeline cache files are individual per frame and a proprietary file format but Cedric stated elsewhere that at least at some frame sizes the video data in those files is AVC/H.264. AVC has nothing to do with MP4 or any other container and visa versa. AVC does define it's own encoded data stream packet structure. Obviously if one places a single AVC frame in your own data file it is an encoded I-frame. As I understand it, decoders, like hardware decoders, do not want a video data stream as exists in container files. They want that stream parsed into individual encoded frames. At the most basic low level. You give them an encoded frame at a time. So it's really no big deal to store I-frames, and any necessary metadata, in individual proprietary files like Hitfilm seems to do for the timeline cache.

    I question if individual files would exacerbate fragmentation. Depending on the extent of what one defines as fragmentation. Those files are going to be relatively small (400KB for UHD) and each is likely to be contiguous on platter, and Hitfilm can most certainly write in such a way as to eliminate this type of in file fragmentation. Of course the files themselves can be scattered relative to each other. This is where the system cache manager can step in to help this out. File system drivers do tend to have a locality bias for files defined/created in the same folder.

    I just noticed that Hitfilm is using the Nvidia hardware AVC encoder when creating timeline cache frames. That is the second thing I have noticed. Quality proxies being the other.

  • MRemple
    MRemple Posts: 24 Enthusiast
    edited November 2022

    So here we are a few weeks later and I may have figured out the root of my playback/performance issue!

    I have been struggling with this for ahwile now and have literally tried everything (SSD drives vs. HDD, different file formats, proxy vs. no proxy, timeline caching vs. no timeline caching, etc., etc., etc.). Nothing could solve this issue where sometimes the playback would lag and stutter and other times it would not. I even upgraded my CPU from a Ryzen 5 2700 to Ryzen 5 5700x (an upgrade I was going to make anyway). That didn't help at all.

    But I think today I accidentally stumbled upon the culprit.

    "Playback Update" on scopes! Believe it or not...

    In any NLE that I edit on, I like to have live scopes turned on just to view my colour/exposure info. So, in HF, I had created a custom workspace with the scopes panel showing at all times (I use a dual monitor workflow). Well, today I needed to use my second monitor to do some other stuiff whilst still having HF open in one monitor. So I switched to the default "editing" workspace, as that is better suited to a single monitor. Well, low and behold, my project played back flawlessly! I could add effects, use the timeline cache, move clips matter what I did, it played beautifully.

    The only difference that I could see between the two workspace layouts was having scopes visible (with 'Playback Update' checked). Just to test this theory, I tried opening the scopes window while in the deault editing workspace, and boom, performance issues came back immediately!

    So, at least for me, it would seem that having scopes with playback update is not possible unless I am prepared to work with the lagging playback.

    I have been happily editing for the better part of a day now with no issues!

  • NormanPCN
    NormanPCN Posts: 4,385 Expert
    edited November 2022

    If you are not really using multiple scopes and once, and who can watch even two during playback, then operate with the one scope you are concentrating on.

    Also, consider the analysis downsample option on each scope. A downsample could/should give better performance. Ideally the downsample could/should be a playback live update thing but I digress.

    Anyway, a couple of things to try.

    If the CPU is the one doing the scope analysis, then this will be a performance bottleneck for Hitfilm. Hitfilm has always been poor at GPU readback. I have not tested in a while. For example, in this instance, Hitfilm may be doing a readback for each active scope. I've no idea, but if you see a significant diff in performance one scope to two then this is a possibility.

    Hitfilm using OpenGL can be a culprit here. GL is typically not as good at readback than other GPU compute systems (e.g. like OpenCL). Hitfilm is using GL for more than parallel compute acceleration. Using GL for everything is the implementation of their vaunted, unified 3D space renders. There are ways to work around this GL readback thing. At least some. Possibly unique per underlying GPU architecture.

  • NormanPCN
    NormanPCN Posts: 4,385 Expert
    edited November 2022

    I think the scopes stuff is done fully on GPU. No readback.

    I will say that on my Nvidia RTX 3070, a heck of a lot of GPU is being used up (70%) with two active scopes, full rez analysis, on a UHDp30 timeline. One active scope improves things. Downsample (1/2) improves things. I used a UHD timeline to stress things. A lesser GPU is going to struggle in this scenario.