One of the things Flicker Free 1.0 doesn’t do well is deal with moving cameras or fast moving subjects. This tends to result in a lot of ghosting… echos from other frames Flicker Free is analyzing as it tries to remove the flicker (no people aren’t going to stop talking to you on dating apps because you’re using FF). You can see this in the below video as sort of a motion blur or trails.
Flicker Free 2.0 does a MUCH better job of handling this situation. We’re using optical flow algorithms (what’s used for retiming footage) as well as a better motion detection algorithm to isolate areas of motion while we deflicker the rest of the frame. You can see the results side-by-side below:
Better handling of fast motion, called Motion Compensation, is one of the big new features of 2.0. While the whole plugin is GPU accelerated, Motion Compensation will slow things down significantly. So if you don’t need it, it’s best to leave it off. But when you need it… you really need it and the extra render time is worth the wait. Especially if it’s critical footage and it’s either wait for the render or re-shoot (which might not be so easy if it’s a wedding or sports event!).
We’re getting ready to release 2.0 in the next week or so, so just a bit of tease of some of the amazing new tech we’ve rolled into it!
It’s been a long time coming, so we’re pretty excited to announce that Flicker Free 2.0 is in beta! The beta serial number is good until June 30th and will make the plugin fully functional with no watermark. Please contact email@example.com to get added to the beta list and get the serial number.
There are a lot of cool improvements, but the main one is GPU support. On Windows, on average it’s about 350% faster vs. Flicker Free 1.0 with the same settings, but often it’s 500% or more. On Mac, it’s more complicated. Older machines see a bigger increase than newer ones, primarily because they support OpenCL better. Apple is doing what it can to kill OpenCL, so newer machines, which are AMD only, suffer because of it. We are working on a Metal port and that’ll be a free upgrade for 2.0, but it won’t be in the initial release. So on Mac you’re more likely to see a 200% or so increase over FF 1.0. Once the Metal port is finished we expect performance similar to what we’re seeing on Windows. Although, on both platforms it varies a bit depending on your CPU, graphic card, and what you’re trying to render.
The other big improvement is better motion detection, that uses optical flow algorithms. For shots with a moving camera or a lot of movement in the video, this makes a big difference. The downside is that this is relatively slow. However, if you’re trying to salvage a shot you can’t go and reshoot (e.g. a wedding), it will fix footage that was previously unfixable.
A great example of this is in the footage below. It’s a handheld shot with rolling bands. The camera is moving around Callie, our Director of IT Obsolescence, and this is something that gives 1.0 serious problems. I show the original, what FF 1.0 could do, and what the new FF 2.0 algorithms are capable of. It does a pretty impressive job.
You can download the Premiere project and footage of Callie here:
A couple important things to note… 1) if you’re on Mac, make sure the Mercury Engine is set to OpenCL. We don’t support Metal yet. We’re working on it but for now the Mercury Engine HAS to be set to OpenCL. 2) Unfortunately, Better AND Faster wasn’t doable. So if you want Faster, use the settings for 1.0. This is probably what you’ll usually want. For footage with a lot of motion (e.g. handheld camera), that’s where the 2.0 improvements will really make a difference, but it’s slower. See the ReadMe for more details (I know… nobody reads the ReadMe. But it’s not much longer than this email… you should read it!).
Here’s a benchmark Premiere Pro project that we’d like you to run. It helps to also have Flicker Free 1.0 installed if you have it. If not, just render the FF 2.0 sequences. Please queue everything up in Media Encoder and render everything when you’re not using the machine for something else. Please send the results (just copy the media encoder log for the renders: File>Show Log), what graphics card you have, and what processer/speed you have to firstname.lastname@example.org.
Benchmark project with footage (if you’ve already downloaded this, please re-download it as the project has changed):