Hitfilm Pro 13 - 'hangups'

Since 13.0 I seem to get regular short hang-ups of 5-10 seconds with the busy cursor. I wondered if it was related to AutoSave, which I have set to 10 minutes, although I don't recall this with earlier versions. A normal File/Save does seem to take longer now.

I am doing a lot of experimentation with the new Tracker, maybe that's the cause.

Anyone else notice this?

John

CPU i7-6700K 4GHz
RAM 32GB
GPU GTX 1660 Ti
Windows 10 64-bit Version

Comments

  • Can you provide some more on what your doing, eg comp work, particle engine, effects?

  • edited August 13

    That's the strange thing, I can't really tie it down to a particular action. I'm working on comps using the new Tracker, but the 'hang-ups' occur when I modify other layers within the comp. I noticed that File/Save takes 15-20 seconds, and the hangups are a similar time, that's why I wondered about Auto Save. Maybe I should switch it off and see if it's better.

  •  Just before I finish for the day: I switched off Auto Save and so far I don't seem to have had hangers any more. I'll do more tests tomorrow

  • Stargazer54Stargazer54 Moderator
    edited August 12

    @pinthenet ; Thanks for the update.  Good call on suspecting Auto Save, you might have spied a bug.  Tagging @Ady.  One thing to note, do not rely on Auto Save as your method to save your work.  You should always save incremental copies manually as you work through a project (apologies if preaching to the converted).  So turning off Auto Save shouldn't be a deal breaker but sounds like it needs to be looked at.

    I would suggest putting in a support ticket with FXHome and share your work file with them so they can run the issue down.  https://fxhome.com/questions/submit

     

  • Triem23Triem23 Moderator

    @Stargazer54 @pinthenet I suspect it's not a "bug" as such - more the tracker generating huge amounts of data. For sake of argument and testing I'd say open up a project with the tracker (where you've already set up a solved camera and your track nulls), delete the active tracker effect (clearing its data) and save the project to a new file name. Play around in the project for 10-15 minutes (long enough for autosave to go by). Then go into file explorer and compare the two projects.

    My guess will be autosave doesn't hang as long as the project file without an active tracker will be much much smaller. 

    For reference, the one Foundry track I've done is giving me a 250MB project file. I've got one 18 second mov clip and one 3D model. Nothing to generate that much data, so I'm assuming it's the tracker. 

    I note while I told the tracker to track 200 features and I refined my track to eliminate bad tracks, looking at the tracker data, some frames are tracking 700 features. My guess is the tracker grabs what it can, then uses the number of features value to grab the top X features (most accurate) from the cloud to calculate a solve. 

  • Hi, 

    Totally agree with triem23. I experienced the same freeze and only when I solved camera with the foundry tracker. And I agree the project file is huge.  Even when I do manual save I experience san me freeze. 

  • edited August 12

    Just tried your suggestion @Triem23. I had a small project - 16 second clip with tracker, plane with Boris text. The file was >51MB.

    I removed the tracker effect and the file went down to <1.5MB, and saved very quickly

  • edited August 12

    Hitfilm project files are plain text XML. Plain text, relative to binary, often causes serious bloat in final output size. Looking at the Tracking data output, I would say there is serious data bloat goin on.

    I get that human readable XML is nice for support diagnostics, but this (tracking data) is a little wild. Compressed projects would be seriously smaller, but mostly Hitfilm projects are well contained. I don't think that the literal tracking data is ever human readable if you get where I am going with thought. Having that data compressed and/or output in a packed format and output in hex/uuencode would likely shrink this a ton. That way the rest of the project is still human readable. There are other applications where we get huge project bloat. 3D objects for example. The geometry is stored in the project. Again, this is not really human readable so why not compress it.

    Yes, compression adds some CPU overhead but the CPU to I/O performance ratio is really massive these days. Every app/instance is unique of course, but I have direct experience where compression was a huge performance gain in output. The CPU to I/O performance ratio was a lot closer in that era.

    Specifically this was packing, and optional compression, of object file debug information during the linking process. MS called it cvpack pack in the day. The compression was not something generic like, LZW, but basically redundancy analysis. Find redundancies and output once. I remember telling Scott I did not care about file size I wanted it fast. So skip the compression. He did that and we were slower than MS. Compression then went in and the tide turned in a huge way.

  •  Very true, I remember thinking that when XML first appeared many years ago (I think I was one of those who said 'it will never come to anything' ).

    I tried to look at an hfp file with Tracking active but I couldn't manage to read it with any Windows text editor and even after copying it to a linux box I only managed to get some basic details.

    The additional stuff that's presumably added by the tracker is all saved  to one line of 52,782,799 characters,  nicely xml-tagged. It also explains why loading the files takes so long.

Sign In or Register to comment.