Hitfilm timeline 4k performance demo video

I am putting this is a new thread to not take other threads off topic.

@logic718gmailcom commented in other threads on Hitfilm 4k performance. I post this just to show what basic 4k performance you can get in Hitfilm with different media file types. There are very dramatic differences. The viewer is at FULL.

My machine: flat 4Ghz i7 4770k, 16GB ram, GTX 980, 7200 RPM 1TB disk.

I have four sample files shown.

GH4 UHDp24 camera file. MOV renamed to MP4 for better performance. 81.7Mbps. If you want to know why I changed the file extension for performance read this thread.

A BMCC UHDp24 Prores 707Mbps MOV file. This is a harsh very high bitrate file.

A Norman fast decode AVC setting file generated UHDp30 res from a 1080p30 source. 84.8Mbps. The file is long at 5 minutes to show the time it takes for thumbnails and waveforms to display in Hitfilm. This delay mostly shows up on long media files. The thumb/waveform delay can interfere with playback at times.

Summary. All played back smoothly. Single media stream on NLE timeline test.

The GH4 camera AVC is very slow to decode compared to the others. Scrubbing and trimming is laggy. Workable?

The fast decode AVC is reasonably quick. Probably workable.

The Cineform AVI file flies. No lag. Best performance.

The BMCC Prores files is quite fast to trim/scrub. A bit heavy on decode/playback. Occasional, not repeatable, tiny hiccups. Not too surprising given the bitrate. A standard bitrate Prores file should perform better.

Comments

I want to add a comment here as I tried a multiple stream composite test.

The one line summary is that you really want to use Cineform in Pro 2017 with 4k work for absolute max performance with multi-stream compositing. Fast decode AVC did pretty well to a point. Only two streams smooth enough. DNxHD/HR was disappointing. I expected it to do better.

I tried 4 ~400Mbps UHDp30 streams and Cineform could do those pretty darn smooth, *IF* the files were cached. Hitfilm will not cause the files to be cached by itself. I was a bit shocked by this as my CPU is only 4-core. I only expected a couple of streams on a 4-core CPU with 4k material. This is an excellent performance result on 4-core.

My video files are all on a single 1TB 7200rpm drive and four 400Mbps data streams is beyond my HD throughput capability. The disk cache was handling this throughput. My machine is 16GB ram and Hitfilm was not using much memory so there was a lot of unused memory for the disk cache to use.

The GPU is not really a factor in all of the above since no effects were being used. Yes the layers needed to be composited but that does not amount to much. The point is that when adding effects, like grading, then the GPU will start to kick in. The CPU has done its major work getting the timeline rolling and then hands off to the GPU.

My machine: flat 4Ghz i7 4770k, 16GB ram, GTX 980.

If you want to see the results, and relative smoothness of playback, I have a few videos to demo. If you are interested, in the system tray you can see a few system tray bugs/icons which shows CPU (blue) and GPU (red) utilization.

First video. Cineform, AVC and DNxHR all uncached. The machine was just rebooted and allowed to settle down.

Fast Decode AVC. Norman settings. 40 seconds. Note. Hitfilm will cause AVC MP4 files to be cached. So just running the timeline a second time performs better than the first pass. Reasonable at two streams but completely falls apart at three streams.

This post mostly speaks to FxHome staff but tech heads might be interested.

I could make a case for Hitfilm having a feature/option/preference to allow media files to be cached during Hitfilm I/O. I understand why Hitfilm would do uncached reads. Video media is huge and minute 3 in play punts minute two from the cache because of this. Thrashing the cache can be wasteful.

However, when we edit we are working/looping on small regions in the NLE or composite timeline. Here caching can make sense. In 4K work for sure. How many have SSDs for everything or fast RAID setups. It is easy, heck trivial, to have a bunch of ram. Hitfilm is very efficient in its use of system memory so most times we have unused ram that the disk cache can utilize.

Even in HD work, where bitrates are "reasonable", many are on laptops and it is easy to have a bunch of ram but harder to have truly fast harddisks in laptops.

Hitfilm does let the system cache MP4 AVC files. Maybe that was unintended as most/all other codec/subsystems, on first glance, seem to stop caching.

@NormanPCN Thanks for sharing this. We do have some caches but their sizes are limited to keep memory usage limited. When working with 4k footage it is easy to max out the caches, forcing HitFilm to read the frame again from disk.

We are aware that we have some room for improvement in the performance area and are investigating some changes but we need to get this right and not make things better for some people and worse for others. These things take time and are done in parallel to other things like bug fixing and adding new features.

@CedricBonnier I guess I was not clear. What I was talking about was system disk caching. Not HF buffering media files.

I looked into this a little more since I saw some inconsistencies in results at times. Now I know why. I keep writing some posts as I play/investigate this a little here and there. My results become more complete/accurate.

It appears that Hitfilm is allowing the system to cache media file reads. There are a couple of exceptions (more later). Windows 10 seems to have some limitations on cache allocation+use by a single process. I'm sure it is relative to unused ram and this test dataset is going to take much of that on my system. These UHD files are quite large.

My initial thing took my sample media and with a batch copied it three more times for the composite test of four unique streams. Well, the copy is a different process and preloaded the media files into the cache. I later decided to write a post with some results and my paranoia kicked in before pressing "post comment". I wanted to verify before clicking post. No verify. So then I wrote a quick program to read those files into cache and I reproduced my initial results. Well, again a separate process and Windows was okay caching that honking data set between the two processes accessing them. My pre-reader and Hitfilm. I had previously seen HF open a file non cached so maybe that was it. Maybe I could make a case for HF allowing caching. I try a simple single file thing and WTF? it gets cached. Play with a few more things and come to a conclusion Windows is messing with me and appears to have single process restrictions.

Nothing we can do about the OS allocating file cache resources.

Okay, the two exceptions that someone there may want to look into.

MPEG-2 in MP4 files do not seem to cache up in Hitfilm. My test was a 70Mbps HD file, 457MB, so with 10+ GB free unused ram it should cache.

Video for Windows, in my case MagicYUV codec, does not seem to cache. I see a CreateFile is used with flag for non buffered reads in process monitor so that may be related. I know VfW in HF kinda sucks relative to Qt and Mainconcept.

Anyway those two won't cache up for whatever reason and the others will under circumstance the OS deems reasonable.

Strange we tested it in Power Director and it beat all other intermediate codecs hands down. Heard from the author yesterday. He working on a conversion utility as most video converters don't support MYUV. Once converted the AVI files work on the timeline of most NLEs that support VFW. I edit 4k on my i5 using it and we developed a batch converter still used by many Cyberlink users. It is an amazing codec. I tried a clip in Express. It imported and previewed OK but couldn't add it to the timeline as it's limited to HD.

@FishyAl To refresh my memory, I just tried a MagicYUV UHDp29.97 video. The same as used for the other tests. MYUV has a lot of options. I chose RGB since one is likely using MYUV because they want lossless so something like a 422 encode still incurs a chroma loss.

Massive file. 1.2Gbps bitrate. One will need an stout I/O subsystem to handle that even single stream.

Hitfilm cannot do even a single stream of this file anywhere remotely near real time. I looped a 10 second region, which can fit in the disk cache, and that would never stabilize/improve in performance, therefore I/O bandwidth is not the only limiting factor.

I had previously noticed some curious anomalies (relative) in Hitfilm VfW usage. I logged all disk access of Hitfilm. Not with MYUV but the same thing might be happening here. Then again, maybe not.

@FishyAl Yes, GoPro studio only accepts limited formats. AVC stuff in MP4/MOV which covers DSLRs and digicams. Of course, if Hitfilm can read the camera source then it can transcode. Not exactly drag and drop but it works. Vegas/Movie studio should be able to transcode anything. Again, not drag and drop except maybe with Vegasaur. Something else like VirtualDub can do a Cineform transcode.

I placed two media files on my SSD. Samsung 850 EVO, 512GB, Sata 3, 6Gbps. The top media file is set to 25% opacity.

As you can see the performance is not very good. I have the viewer set to half. As previously stated, I've seen Hitfilm using some curious file access with VfW at least relative to what I see with native MP4 and Quicktime MOV disk access in Hitfilm. With the media on an SSD I'm not sure how much that affects things. Probably not much if at all.

I rendered my MagicYUV files via Vegas 14 through Video for Windows. If you state that Vegas via the Video for Windows MagicYUV installed codec is doing something wrong then make your case and be specific.

Your file "MAGY" is from the original free 1.x version of the codec. At least the transcode tool is using that. 1.x used the same fourcc for all colorspaces MagicYUV supported. RGB and YUV. The current 2.x version, which purchased and have installed, uses a different fourcc for each colorspace supported. Apps that support smart rendering don't like it when an AVI I-frame codec has multiple colorspaces on the same fourcc. The smart rendering barfs since the output and input are not really the same.

The fourcc you see from my file is for the RGB colorspace. For example if I select 422 YUV output the fourcc is M8Y2. For reference, here is a MI report of that file.

@NormanPCN&nbsp;my mistake. I didn't know your workflow or read your post thoroughly. Just assumed you were using the free codec to test it. I understand your problem and it sucks. Maybe contact the author for more info. I'll delete my post and contact him as well.

@FishyAl The same MagicYUV file performs well in Vegas. I only tried one stream.

Hitfilm is slow in basic timeline playback relative to most if not all other video editors. Vegas (personal tests). Premiere and FCPX from forum reports. From your report we can maybe add Power Director to the list. Hitfilm needs help on the input media end of things. A transcode.

MagicYUV seems fast but does need capable I/O bandwidth, especially in RGB colorspace. For whatever reason, it just does not perform in Hitfilm. For the lossless video crowd this is unfortunate. It may be due to how Hitfilm does I/O on Video for Windows codecs. I wonder about that since an SSD tends to "cure" most all I/O ills. Still a MYUV stream is pushing things hard so there might be something there.

@NormanPCN - I deleted my post as I just found out the converter we developed is not compatible with MYUV ver 2.0. I deleted my post with the converter info to avoid confusion. My work is all 8 bit so ver 1.2 still works great for me and I'll continue using it with our converter.

I was obviously surprised at your poor MYUV performance with Hitfilm when our results showed it was significantly faster than even cineform with AVC UHD 8 bit test clips. I asked the MYUV author to have a look at your thread and results. His initial reaction was:

" According to what he's experiencing, I believe it to be an issue with Hitfilm-VFW communication or Hitfilm. 1.2 Gbps is 150 MB/sec, an SSD can easily pull that off (most operate at around 400-500 MB/sec). Moreover the video is only 30 fps, so definitely the codec can decode that fast enough (given a not too archaic CPU), the logfiles written by the codec can be used to check decoding performance, so I'm certain the issue is somewhere inside Hitfilm."

So maybe we shouldn't write MYUV off yet as a potential transcoding solution for 4k in Hitfilm.

You obviously have a good understanding of codecs. Quick question please. You renamed your GH4 clip from MOV to MP4. I thought re-wrapping a codec is not the same as just changing the file type?? What is the original camera codec?

Thanks for the reply - I'm still a bit confused so please bear with me. All I know about capture codecs is there are too many camera formats to deal with.

We used MYUV 1.x from the beginning for decoding AVC 4k to MYUV AVI with no problems but our converter was developed specifically for 1.x including batch conversion. It retains original filenames. I believe Magic are developing a new GUI converter for the 2.x codecs.

GH4 is a great camera (wish I had one). I don't know the camera codec but assume the codec is supported for import into Pro as MOV or MP4. Camera can also shoot UHD MP4 so why are you using MOV? Is your camera file 8bit or 10bit? Please add the source file MediaInfo in your first post.

Would your playback test results be any different if your source was the more common standard AVC UHD MP4 vs the GH4 codec.

I read your link re QT. When the problems arose, DaVinci Resolve did what Apple should have done and wrote their own 64 bit QT for Windows - comes with free Resolve so I've never worried about VFW vs QT. I thought QT is better for 10bit+ color than VFW - but I'm not sure.

I have always used converters to re-wrap h.264. I currently use free Smartffmpeg to re-wrap Resolve QT h.264 MOV to mp4 for easy playback on most devices. There is a difference in file sizes so I assume it's doing more than just renaming the file type. I've also used it to re-wrap MTS/M2TS to MP4 to convert Sony to Cineform using GoPro Studio which only accepts GoPro formats. Since MYUV I've stopped using Cineform.

As I said, I know little about the dark and mysterious world of codecs so please correct me. Was Hitfilm originally Apple?

I do not own a GH4. I have a Canon DSLR and GoPro. I have collected misc camera sample files from around the net for testing. About 20. The GH4 and GH5 being a couple of them since they are so popular.

The file I downloaded was in MOV. My Canon DSLR always outputs MOV. Historically DSLRs output MOV. DSLRs outputting an MP4 container in addition to MOV is a recent thing.

"Is your camera file 8bit or 10bit?"

Look at the GH4 specs. There are plenty of reviews on the NET. Google is your friend.

That said it is 8-bit. What information are you looking for? Also, Hitfilm does not support 10-bit video via the native AVC decoder. Neither does the Quicktime AVC decoder AFAIK.

There is no critical info there that my minimal terse specs list in my first post did not outline. What were you looking for? If you are really interested in GH4 then download a same from the NET somewhere.

"Would your playback test results be any different if your source was the more common standard AVC UHD MP4 vs the GH4 codec."

GH4 outputs the AVC/H.264 video codec. GH4 does not have a unique codec ("GH4 codec"). No camera does. They are all using off the shelf systems. GH4 does output common standard video files.

The point of that post was that the Quicktime AVC decoder sucks in performance. The camera source media was unchanged. Renaming the extension was a way to get Hitfilm to use the internal native (mainconcept) AVC decoder bypassing Quicktime. Kinda like what Vegas and others do by default without the extension rename.

"DaVinci Resolve did what Apple should have done and wrote their own 64 bit QT for Windows - comes with free Resolve so I've never worried about VFW vs QT"

I have severe doubts Blackmagic wrote their own "Quicktime". It would violate copyrights and maybe patents.

"I thought QT is better for 10bit+ color than VFW - but I'm not sure."

Not true, but it is limited to AVC video in MOV/MP4 containers. AVC 8-bit 4:2:0 to be specific AFAIK. That said, it does not like a GH5 AVC 8-bit 420 UHDp60 MP4 I downloaded. Quicktime does complain about an invalid sample description.

Hitfilm can transcode the GH5 files to Cineform just fine.

"Was Hitfilm originally Apple?"

WTF?

If you have general codec questions it would be best to start a new thread on that, to not pollute this thread on Hitfilm 4k performance.