Performance - am I expecting too much?

I thought I'd have a play with Javert's "Day for Night" tutorial but found playback so jerky as to be unusable (playing the completed project). Perhaps not surprising and it may be that Javert is speeding up a lot of the processes for the sake of the tutorial.

Exporting the project to the Vimeo preset takes a minute.

Creating a proxy on the timeline takes 3 minutes (and the CPU cores all stay below 30%)

Just wondering what results others are getting, whether i'm seeing the performance I should be seeing.

Oh, yes, crucial point: i7-5820 (hex core) @ 4.0GHz, 32GB RAM, R9 390x graphics, files on PCIe SSD, proxy/program files on C: drive - also SSD.

 

Comments

  • Part of the performance issues may be related to the input format. Some formats like H.264 .MP4 are less suitable for editing than other formats, as they have not been designed with 'random access' in mind, but rather with streaming. The video file supplied in that tutorial is such a file. Have not tried this myself yet, but transcoding the video should help. Here are some threads on that topic:
    http://hitfilm.com/forum/discussion/42071/hitfilm-running-slow-on-i7-gtx-1060-pc
    https://hitfilm.com/forum/discussion/41578/transcoding-to-dnxhd

    Also, I noticed some relatively simple 3D effects (e.g. extruded text) will not render real-time in Hitfilm on my machine (exact same specs as yours except for the GPU), but would be very smooth in e.g. Blender (open-source 3D software). To deal with that, I just render a lot of previews to get a better feel of the actual timing for some animations/transitions. In the end it's worth it, but of course any performance improvement would be welcome.

  • Triem23Triem23 Moderator

    Zwave raises good points. The project files were probably compressed for space, not optimized for performance. 

    Note CPU pegging isn't a good indicator of Hitfilm resource use. The CPU only does disc I/O, and video decoding/encoding. Video decoding is single threaded (one thread per media clip).

    Rendering tasks are all GPU based. 

    Proxies aren't low res files, they're full res, low compression. Since one can still work in Hitfilm while proxies render, proxies aren't using all resources, which is why the proxy render takes longer than the export. 

    Hitfilm isn't the fastest at media decoding either. 

    I might look at that project file myself. Your machine is higher spec than mine, so I'd expect my system to be a bit slower. If mine isn't for whatever reason, you may have background processes slowing things. For example any Antivirus software set to scan all files on launch would bottleneck the system. 

  • Thanks both. I hadn't considered that the downloaded footage might be a different format (Duh!). AntiVirus, whilst checking files on read and write, shouldn't be a problem after the file is opened, but I'll have a play anyway and report back.

    If most work is being performed in the GPU, I would have thought any background tasks (I'm not running any other desktop applications) are unlikely to impact upon that.

    I'd appreciate it, Mike, if you do get a chance to download and try the project at some time and report back, if you would.

     

Sign in to comment

Leave a Comment