Processor bottleneck when compositing

When compositing the program is much slower and I can see that I use around double the processing power compared to when using the edit-timeline, even though I have the exact same videos on both timelines.

Am I doing something wrong, or is this just how it is with composite shots?

My specs:

CPU: i5-6400

GPU: Nvidia GTX 960, 2gb

RAM: 16GB DDR3

Hard Drive: SSD

 

Video file:

 1080p, 29fps, mp4(converted from MOV using WinRar)

Comments

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador

    @MalteBraelignder When you say slower, I am assuming that you mean it is slower to scrub the timeline?   That is to be expected since you are now asking your system to compute multiple streams on the fly.

    Any NLE will drag at some point after you add multiple layers to a shot. The doubled edged sword is that HF does not require you to "pre-render" to scrub, so you'll get a slow down because nothing is rendered yet. 

    One workaround is it put your layers in multiple composite shots and do a proxy render on the comps that you are done tweaking.  That will help speed up things.  At least until you bump something in one of those comps and have to do the proxy again.

  • MalteBraelignder
    MalteBraelignder Posts: 21
    edited November 2016

    @Stargazer54

    Thank you,

    I guess that will work.

    The thing that bugs me is that even when I have only one layer in the composite shot it is noticeably slower than the same one layer on the editing timeline - can this be right?

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador
    edited November 2016

    Hmm. . no that doesn't sound right.  Your systems specs look fine.  I assume you are on a PC?  Win 7, 8 or 10?  If you're on a laptop, there are known issues with Dells.

    Next thing to look at maybe would be to make sure your GPU drivers are up to date.

    Also, in the viewer window make sure you have resolution set to Full or Half.  And if you still have trouble, you might consider posting a screen shot of your timeline.

     

  • MalteBraelignder
    MalteBraelignder Posts: 21
    edited November 2016

    @Stargazer54

    I am on an HP Envy Desktop. My GPU is up to date. My resolution is set to Full in both timelines.

    Here are some screenshot of the settings and so on: imgur.com/a/kSOG9

    EDIT: Oh yeah, you should note that I am using .avi and not .mp4 in these screenshots because that is the format I will most likely use

     

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador
    edited November 2016

    @MalteBraelignder Hmm... so if you just have one video stream on the timeline and it is sluggish, then it could be one of two things (or both). 

    First the codec for the avi may be something HF doesn't deal with well.  Or second, your avi is variable frame rate. 

    As a troubleshooting step, try converting to either mp4 or mov at a constant frame rate and see if that improves things.   Probably not what you want to hear but at least that could narrow down the issue.

  • MalteBraelignder
    MalteBraelignder Posts: 21
    edited November 2016

    @Stargazer54

    Hmm...

    My files are already at a constant framerate - They are stopmotions. The original files were uncompressed, but even after trying all available codecs in both Handbrake and my stopmotion-software (and making sure that they were at a fixed framerate) they only made compositing even more CPU-demanding.

    I am really sorry to keep bothering you, but I really don't understand what is going on.

    The program is not really sluggish when I only have one layer in the composite shot - it is just using way more CPU-power than the same one layer in an editing timeline (approximately 3x as much). This means that when I do have multiple layers in a composite shot it is really slow

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador

    @MalteBraelignder Yeah, that's not making a whole lot of sense.   Do you have the same problem with video files from other sources.   Say another 1080P .mov or .mp4?

    I hate to say it maybe your i5 is under powered (at least for HF)? I downloaded a 1080 clip (Autumn_leaves_9.mp4) from here: http://all-free-download.com/free-footage/autumn_leaves_234_download.html and on my office laptop with an i5 and a crappy Radeon 7570M GPU, the clip is indeed sluggish on both HF4 and HF2017.   Although I attribute that to it being variable bit rate (with the avg. bitrate being 13.1 Mbps).  I'll be interested to see if converting to DNxHD will help it.

    On my edit system which is an i7 and GTX980 I am able to scrub the timeline real time on a 1080 clip.  So hardware does come into play. 

    Although I did notice that if I render out the original clip to an mp4 output by HF and brought that back into the editor, then response was better.  Funny thing is MediaInfo says the rendered file is 15.5 Mbps and is still variable bit rate.

    So you might try another test and render out one of your files to the native mp4 that HF uses and bring it back into the timeline. 

    Maybe @NormanPCN or @Triem23 have some other suggestions

  • NormanPCN
    NormanPCN Posts: 4,134 Enthusiast

    The first thing I would want to know is what are the contents of the media file. A MediaInfo (free util) report would be nice. You can copy+paste the text printout from MediaInfo directly to a post here. This "1080p, 29fps, mp4(converted from MOV using WinRar)" does not make much sense especially the WinRar reference. If you are using AVI then report that.

    Also, when you add multiple simultaneous layers of unique media files the playback most certainly can get slower. It is a fact of life. Two layers is asking twice as much from the CPU. Realtime speed can only be maintained if the CPU was below half capacity on a single file/layer.

    An i5 6400 is 4-core, 4-thread. If the video file decode overhead is low enough this should be enough for a couple of simultaneous layers. AVC video, if that is what you have, can have a reasonably high overhead and Hitfilm is not so fast and can need help in the video file decode department. This help by transcoding to a lower overhead video file. The MediaInfo report will let us know what you actually have.

    @Stargazer54 Variable bitrate video is pretty much never a problem for performance. Only if the bitrate absolutely skyrockets temporarily. Like going from 15Mbps to 100Mbps. Few encoders can provide that kind of freedom to bitrate. x264 can in CRF mode but not average bitrate mode which all other encoders operate in. CRF was an x264 invention.

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador

    @NormanPCN I stand corrected. I was confusing variable bit rate for "variable frame rate".

  • Triem23
    Triem23 Posts: 20,574 Ambassador

    Saw the tag, but I think @Aladdin4d might be a better person for this issue. Although Norman is possibly the most tech-savvy person on the forum, and Stargazer is no slouch. 

    I got nothing other than speculation that HF seems pretty brute force on the render chain, and going into a composite shot might automatically be more overhead than a video clip on the Editor Timeline. It's possible that in a Composite Shot Hitfilm always has to look at extra things (is that layer 2D or 3D?) that could eat up a few processor cycles before render. 

  • @NormanPCN

    Here is the information from Mediainfo - Is this what you were asking for?

    ID : 0
    Format : RGB
    Codec ID : 0x00000000
    Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
    Duration : 2 s 500 ms
    Bit rate : 1 194 Mb/s
    Width : 1 920 pixels
    Height : 1 080 pixels
    Display aspect ratio : 16:9
    Frame rate : 24.000 FPS
    Bit depth : 8 bits
    Bits/(Pixel*Frame) : 24.000
    Stream size : 356 MiB (100%)

     

    I tried downloading the file that @Stargazer54 linked to, but I had the same problem there - a composite shot used at least double the CPU compared to the same file in an editing timeline.

    I was also the same after exporting and importing again.

    After having used multiple different files I began suspecting that it might not be something to do with the files that I am using. I therefore tried just creating a new plane(Black, 1920x1080, ratio:1.0) and using that as a test. Playing an editing timeline with only the plane on it only took 2-4% of my CPU, while a composite shot containing only that one plane took 26-30%

    I tried the same thing on my laptop (which is not for editing) Here i used 20% in an editing timeline and 25% in a compositing timeline. I guess this sort of difference is to be expected.

    It seems to me like the problem on my editing PC is either some setting in the software or some problem with my PC.

     

  • [Deleted User]
    [Deleted User] Posts: 1,995 Just Starting Out

    Perhaps theres a bitrate limit for the editor timeline but not the comp? 

    Ill try this later and see if I get the same result.

  • NormanPCN
    NormanPCN Posts: 4,134 Enthusiast

    I've not used that codec. I can probably create a test case with Vegas to try on my machine. What I can say is that is one massive bitrate. 1.2Gbps. Yes, giga bits per second.

    It is a basic uncompressed Windows bitmap so there is no CPU decode to speak of. Just a serious I/O burden but you state the media file(s) are on a SSD so that helps. With multiple similar media streams from the same SSD things can get harder. SATA 3 is 6Gbps, SATA 2 is 3Gbps. Those are theoretical wire speeds. No overhead is taken into account. 

    For AVI like that, Hitfilm goes through the Video for Windows (VfW) subsystem. I am not sure how well VfW keeps up with such high bitrates. 

  • Aladdin4d
    Aladdin4d Posts: 2,481 Enthusiast
    edited December 2016

    @NormanPCN

    "I've not used that codec"

    You've never used that codec before because it isn't a codec. That's just an uncompressed AVI. On Windows uncompressed video = BMP image sequence. That's also why the bitrate is 1.2 Gbps. 

    @MalteBraelignder I'm curious as to what else is going on when you're using HitFilm. In the first image you have showing the composite timeline HitFilm is using 20% of the CPU but the total CPU utilization is 37%. What's using the other 17%? The second shows the editing timeline and HitFilm is only using 10% of the CPU but the total CPU utilization is 24%. What's using the other 14%?

  • [Deleted User]
    [Deleted User] Posts: 1,995 Just Starting Out

    Maybe moving the mouse cursor around, and perhaps thats shown even more if the mouse polling rate is set to a high number like 500 or 1000?

    Thats my wild guess.

  • NormanPCN
    NormanPCN Posts: 4,134 Enthusiast
    edited December 2016

    I created an uncompressed AVI via Vegas. My bitrate was 1.4Gbps at 29.97 framerate.

    My machine is reasonably stout: HD 7200 RPM 1TB, SSD Samsung 850 EVO 512GB, 4Ghz i7 4770k, GTX 980. The SSD is SATA3 in an SATA3 port.

    Vegas is not able to play that back smooth when coming from my HD (~16fps). From the SSD it was smooth. Vegas has a playback framerate display so this is not a subjective statement. I tried 2 streams stacked in Vegas. Top stream was 50% opacity to cause Vegas to composite the two. Vegas was still smooth. With 3 streams Vegas was no longer real time playback but it was close (~29.1 vs 29.97).

    Hitfilm. Not smooth from HD. Smooth from SSD one stream. Smooth with two streams. Still visually smooth at three streams. This in a comp timeline but I doubt that matters. I can only do a subjective eval here.

    Each media data stream was a unique file. Not being smooth from the HD is expected given the massive bitrate. Similar CPU utilization at three streams in Vegas and Hitfilm. About 25%, so approx two logical cores fully loaded for my 8-logical core CPU.

  • @NormanPCN

    Thank you for your response, but I am really quite certain that the problem is not the file.

    I tried exporting the .avi  as an .mp4 through Hitfilm like @Stargazer54 recommended, but using this instead I actually used even more of my CPU while compositing.

    Here is the Mediainfo sheet for the new file:

    Format : MPEG-4
    Format profile : Base Media / Version 2
    Codec ID : mp42 (isom/mp42)
    File size : 3.52 MiB
    Duration : 2 s 539 ms
    Overall bit rate mode : Variable
    Overall bit rate : 11.6 Mb/s

     

    In an editing timeline I am able to play back more than 5 layers of the uncompressed (1.2Gbps) file without any noticeable slowdown. This uses around 40% of my CPU

    In a composite shot even 2 layers of the uncompressed file uses 50%

     

    This has made me think that the problem is not the file, but something in either the program or my hardware.

     

    @Aladdin4d

    When using just Hitfilm the top 3 other processes are System, System Interrupts and dwm.exe

    In the screenshot Chrome was also open, which probably contributes to some of the extra CPU used.

    Anyway my question was not really how to minimize CPU-usage (although that is always nice to know) but why my compositing takes up so much more of my CPU strength than just editing does.

  • Aladdin4d
    Aladdin4d Posts: 2,481 Enthusiast

    @MalteBraelignder  Oh I understand your question it's just that sometimes things can interact in strange ways hiding the real cause of a problem. In other words it might be another process that's actually causing HitFilm's CPU usage to go up on the compositing timeline. I know it sounds far fetched but I have seen similar situations and even stranger things before.

  • NormanPCN
    NormanPCN Posts: 4,134 Enthusiast

    @MalteBraelignder The mediainfo report of the MP4 is very incomplete. I am assuming you transcoded to an AVC MP4 file and AVC can have a high CPU decode overhead. You need to use correct settings to lower AVC overhead. That said, 11Mbps is reasonably low so that encode should be reasonable.

    "In an editing timeline I am able to play back more than 5 layers of the uncompressed (1.2Gbps) file without any noticeable slowdown. This uses around 40% of my CPU"

    Five instances of the same file in time sync, or 5 unique files or same file but not in time sync. Hitfilm is smart about layers of the same media in time sync.

    Also, if you want to equate my report to your CPU you must double my CPU % utilization since my CPU has 8 logical cores.

  • @NormanPCN

    Mediainfo did not give me any more information than what I listed here (At least I don't think so), but yes it was an AVC MP4

     

    "Five instances of the same file in time sync, or 5 unique files or same file but not in time sync. Hitfilm is smart about layers of the same media in time sync."

    I originally used 5 instances of the same file in sync, I did not know Hitfilm was that smart about resources.

    I just tried with multiple different files and this did significantly lower my performance. This, however, does not seem to help me in understanding why compositing is way more resource demanding than editing no matter what files I use.

    I really don't want to seem rude, because I am very happy for all of your help, but I don't see how the type of file matters, when I have the same problem using only the built-in plane.

  • MalteBraelignder
    MalteBraelignder Posts: 21
    edited December 2016

    @Aladdin4d

    Oh I see, yeah I guess it could be relevant.

    I took some screenshots of some more of the process list while playing different versions of both editing and compositing timelines.

    I hope this can help in figuring out the problem

    Link to imgur

  • Stargazer54
    Stargazer54 Posts: 3,755 Ambassador

    Just a thought, but what "size" do you have your video track set at?  i.e. if you have it set to anything other than small, then you wind up with thumbnails on the timeline and that will slow things down if you're on the edge, performance wise.

    That can be changed by clicking on the little triangle at the bottom of the Tracks window, just to the right of the scale slider.

  • @Stargazer54

    Oh cool, I have been wondering how to change that. It did not increase my performance by any noticeable amount, but it is definitely nice to have a cleaner timeline.

    Thank you

     

This discussion has been closed.