How to Speed up Tracking in Hitfilm 3 Pro

Quick tip, open another window - doesn't matter what - over Hitfilm and tracking suddenly speeds up by a factor of 4-10, as it stops refreshing the screen, but is still running behind. It doesn't even need to cover the whole screen, so you can still see the little tracking bar whizzing along, and can periodically shrink the extra window to check it's... on track...then pop it back up again to carry on at top speed.

Makes tracking .MP4 files (which are fine to edit with, but deathly slow to track; e.g. 1 frame a second) actually manageable. It also speeds up other files types, but by a lesser amount, as they're already handled better.

Does seem to illustrate that the drawing of the dots and updating the console info takes up a lot more time than the actual tracking.

Comments

  • Did you try just minimizing the window?

  • No, because I want to be able to watch the progress bar moving along and periodically check it's not gone off track.

    If that works too, let us know; but I'm happy just having this method working.

  • Huh, interesting find. Seems like this might be an area of optimization for the developers, if they could completely separate the tracking from the UI and handle progress updates asynchronously. It might have the disadvantage that what you see in the UI is not exactly up to the actual progress, so if you see the tracking go off, it might already be a few frames late. But personally I think this is no problem if the actual tracking was much faster this way. I'll tag @Ady again so this gets passed on to the devs.

  • I should probably mention: I'm using a Dual monitor setup when I do this, so I pop up the other window over the render window, not the timeline window. This seems to be a similar side effect to the other issues when tracking: of having the dots on the timeline visible was making it difficult to interrupt the tracker, as that process seemed to not be letting the interface accept pause requests from the mouse; but minimising everything on the timeline made pausing possible.

    Something else possibly related. Deleting a single point from the tracking data can occasionally take several (up to about 10 seconds) before the editor allows input again. It's like the data for the points is written/read individually, and Windows is sloooow if you do that. Back in the day when I was programming: any data input functions I wrote always had a small 16 byte buffer that would read in larger chunks, and manage handing over individual bytes to the calling program. Was massively faster than calling the HDD (and all the overhead of Microsoft code) for a single byte. The HDD was supposed to be clever about pre-fetching, but I think so many other simultaneous requests were being made to it that its buffer was made instantly redundant and doing it myself was the only way to guarantee the data really was buffered.

    Another side effect: Take 4 or 5 points and parent them in a line. Then change a few values in the last one, that's attached to something with some tracking data that would be referenced all the way up the line. Sometimes it's so slow you think its crashed, and the HDD thrashes away like you asked it to defragment the drive.

    Somewhere a Microsoft library function has a dozen wrappers around it and is eventually calling an old MS-DOS INT 21h function. Badly.

  • @Palacono Does it matter which part of the HitFilm UI the other Window is over? I would expect that it shouldn't, but if it does that's really curious.

    About those side effects, actually, all that tracking data and everything else HitFilm is operating on (except media files) should really only be in RAM at the time of tracking, as the project file is only touched during project saving, so there should be no need to access the hard drive while you're making changes - except if you're low on RAM and the OS is already paging, but it shouldn't do that with stuff you're currently working on directly... I've not have this effect you're describing yet.

  • edited August 2015

    I don't know. I just pop a window (actually just a folder with the output videos in)  up over the Render (2nd monitor) window and it works. Not bothered to experiment more.

  • @Palacono, you mentioned the source files are .mp4 are you sure you haven't got a m2ts in there somewhere? These are known to cause HitFilm to randomly lock up.

  • No, I only use either the raw MP4 files if I'm feeling lazy, or Cineform'd AVIs if I've shot in Protune, as I use GoPro Studio Premium to do the colour correction, as it's got scopes, histogram etc.

Sign in to comment