Blackmagic Design Announces DaVinci Resolve 17.3

I wonder if Apple cares what any of us think.

Redifer wrote:

I wonder if Apple cares what any of us think.

Based on the last two years, concerning FCP, no.

Ben Balser: "Apple Color had MUCH MORE than simply tracking that is lacking in FCP. MUCH MORE!"

I totally agree that Color had a much better color correction workflow, however the tools to make those corrections are the same and in fact superior today.

In Color you had 10 grading levels per clip, which were set up as "rooms" but applied as layers, sort of like an adjustment layer. You had primary in and out, plus 8 secondaries, so 10 levels. However, secondaries (where you applied masks) could have both an inside and outside grade - in effect, 16 secondary corrections. Then you also had the node-based ColorFX room and a RED room for REDCODE camera raw adjustments.

The actual color correction tools were simply color wheels and curves, plus printer lights (equivalent to an overall or master hue offset wheel). Stacking color wheels, curves, color board instances onto a clip in FCP effectively gives you the same results. Minus the tracking for a shape mask.

As much as I loved the Color speed and workflow (in some ways better than Resolve), there was no real colorspace management, not much (if any) LUT support, no HDR support (non-existent back then), and performance was awful once you got bigger than 2K.

So yes, I agree that as a total package, Color was a better color correction application than FCP (given the design limitations of that time). I'm merely saying the the core tools were migrated into FCP and improved. If you carefully work with them, you can get similar results without needing to go to Resolve - IF - you don't want to.

The reason Color doesn't exist today is the same reason that Adobe dropped SpeedGrade. Both companies realized that to build a new grading app would be pointless, because they would be competing against Resolve, which BMD was now selling for free/$300. Neither Color nor SpeedGrade ever had large market traction before or after acquisition, so it made more sense to roll a lot of those tools into the NLE and pull the plug.

DR 17.3 is very very good. The only real reason my main editor is still FCP is range-based keywording, and the neatness of the timeline. I'm getting very frustrated with various things (slow clip browsing and management in events, audio mixing tools, spinning beachballs...). I've got a big project on-going in FCP and so will finish this project, but if there is little sign of progress with a new version soon, then I'm going to move over to DR for my next one.

nobbystylus wrote:

DR 17.3 is very very good. The only real reason my main editor is still FCP is range-based keywording, and the neatness of the timeline. I'm getting very frustrated with various things (slow clip browsing and management in events, audio mixing tools, spinning beachballs...)....

Are you still having those FCP crashes or did they go away? One of the last crashes you posted had the below stack trace on FCP 10.5.3 (see attached), which has been correlated with intermittent hardware failures in 3rd-party RAM. Are you using OWC or other 3rd-party RAM?

You had other crashes and hangs possibly related to 3rd-party plugins. Yes those can be very frustrating. Every plugin using the FxPlug 3 framework (which is most of the sophisticated ones) run within the FCP address space. That means any bug in any thread can crash or destabilize FCP.

Going forward that should be improved as plugin developers move their code to the FxPlug 4 framework, since those run in a separate, protected address space. I believe Neat Video and Digital Anarchy have already done this.

For a lot of common tasks such as color grading, video noise reduction, tracking, skin processing, etc, Resolve does not require plugins but that functionality is built in. Obviously that is a nice advantage, especially if working in a collaborative setting when you know all co-workers have the same functionality.

Resolve has another key feature which is ability to trim files (what they call media management) when consolidating a timeline. In a remote distributed workflow that greatly facilitates sending smaller datasets to collaborators.

OTOH when I tested that on Resolve Studio 17.1.1, it caused severe data corruption on many codecs. It seems by 17.2.2 that was fixed. Until recently Resolve had both "move" and "copy" versions of media management. I believe they "move" version was so buggy they finally removed it.

In general FCP media management is very reliable and it rarely corrupts data, even if FCP or the machine crashes.

The Resolve playback engine has been greatly improved in recent versions, but slowdowns and crashes are not unknown in Resolve. It places great demands on the GPU, especially for advanced features like video noise reduction, magic mask and skin processing. Traditionally people on Windows just get a massively powerful GPU, which is still sometimes insufficient.

What remains to be seen is how Resolve's GPU-intensive functions will perform on the upcoming new generation of M1X Macs, and how the performance, reliability and data integrity on that platform compares to FCP.

The crashes I was having are much much less since doing a system reinstall (in place) and stripping out all the plugins (except Neat). The beachballs I'm having is with very simple stuff, like hitting shift F on a clip, or opening an event with a fair few clips in it. I can sit for 10 seconds waiting which kills the flow. I do have a lot of clips in this project, but I just don't find any issues like this in Resolve with larger projects....

nobbystylus wrote:

...The beachballs I'm having is with very simple stuff, like hitting shift F on a clip, or opening an event with a fair few clips in it. I can sit for 10 seconds waiting which kills the flow. I do have a lot of clips in this project, but I just don't find any issues like this in Resolve with larger projects....

I've edited large documentaries with over 8,500 4k clips, 220 camera hours and 130 multi-cam 4k interviews on a 2017 iMac 27, and it mostly ran OK. Media was on a 32 TB 4-drive RAID-0 OWC Thunderbay 4, and library was on a separate SSD.

Before that I edited a doc which had about 5,000 1080p clips in a single event, and it mostly worked OK.

Since each project is a separate SQLite database, if you have a large # of projects or snapshots in an event, that can slow down opening the event. There is no hard limit but as you go above approx. 30 it may become noticeable, depending on the hardware and whether the library and cache are on SSD.

If the media is on a single drive vs RAID or on a non-optimized NAS (esp. gigabit vs 10-gig), if library and cache are not on SSD, all those things can contribute to slowdowns.

However in general a beachball doesn't indicate a normal slowdown, but that the app is not responding for several seconds to the MacOS "window server", which then raises the beachball to indicate that. A well-written app should normally never fail to respond for 2-4 sec. E.g, when FCP is exporting, it doesn't cause a beachball, the app produces a progress clock or progress bar. 

Sometimes a beachball is caused by a plugin which improperly hogs the CPU or a system-layer issue such as I/O taking too long. If those things happen in a software code path where the app is not checking for a timeout or producing a progress indicator, the beachball can happen.

Even though I second you that FCP needs much improvement I must say that it is definitely capable of editing more than YouTube videos. See: Q into the storm, the banker and the recent Netflix movie I have edited with it: Blood Red Sky. I am too frustrated with some shortcomings, but is still think even those things are missing it is the superior NLE when you focus on the editing part of it. Yes we definitely need better Audio tools and they need to fix support for Pro Audio Plugins from Waves and Izotope. And I am eagerly waiting for Trim tools that are at least  on par with FCP7. Avid is still trimming champ.... As for the development. Almost all the things added over the last few years only cater to Pro needs and are probably of no use to any YouTuber. None of it was really of interest to me on the other hand, but we should not forget that we are a demanding but minuscule minority.

I still love FCP but I hope it is not victim of Ape’s “good enough” strategy. Pages and Numbers, for example, are mature apps which are “good enough” that nobody really updates them beyond compatibility and a few new features once in a blue moon.

FCP is great but could be much better, and I would argue is in a different category of apps and Apple should treat it as such. The pro team should be a great, innovative place to be, not the graveyard of bug fixes and “good enough.”

noah.leon wrote:

I still love FCP but I hope it is not victim of Ape’s “good enough” strategy. Pages and Numbers, for example, are mature apps which are “good enough” that nobody really updates them beyond compatibility and a few new features once in a blue moon.

FCP is great but could be much better, and I would argue is in a different category of apps and Apple should treat it as such. The pro team should be a great, innovative place to be, not the graveyard of bug fixes and “good enough.”

 

I wouldn't mind some bug fixes for Audio plugins....

The database is too slow with large amounts of clips - I’m running a decent spec system and drives and using proxies and just don’t find searching and working with clips in events tolerable. Having said that I tested my partners M1 MacBook Air with my project and was blown away…

The M1 (while nice) is not that fast overall IF the comparison is using FCP proxies on a top-spec recent x86 Mac, such as a 2020 i9 iMac 27. The M1 *is* a lot faster at decoding certain difficult codecs, esp. 4k 10-bit 4:2:2. However that should not be an issue if using regular 50% ProRes proxies. It might also be the "clean new machine" syndrome, since the M1 doesn't have any pre-existing plugins or kernel extensions. It would be interesting to try your difficult library and project on a clean, late-generation x86 i9 iMac 27.

The fact that the FCP on M1 is fast on that project implies there isn't an inherent deficiency with FCP handling large libraries.

The new upcoming M1X-based Macs should be at least 2x faster on CPU and 4x faster on GPU than the M1. How well the various NLEs leverage that remains to be seen, but FCP will probably do a good job.

Thats interesting that the M1 is better at the 10bit 422 decoding. I have a lot of Panasonic GH5 10 bit 422 and, although they work fine, they're definitely a sludge on my iMac 5K 2017 (4TB SSD, 64GB RAM) - although I proxy everything so I assume this isn't the reason for my slowdowns and beachballs.

If you use the default 50% ProRes Proxies, the decode aspect should not slow down your 2017 iMac 27. Likewise the M1 Mac's decode efficiency on Long GOP codecs should not be the difference.

However if only some of those clips are proxies, it could still slow down the x86 Mac but not the M1 Mac. In previous versions of FCP you couldn't make a mistake on that because there was no "proxy preferred" option -- any non-proxy clips would show as red. With current versions we have "proxy preferred" so it will silently try to use the original clip if proxies aren't available. If those clips are Panasonic 10-bit 4:2:2, that will be slow on x86 and fast on M1.

You can check that by doing "View>Proxy Only" rather than "View>Proxy Preferred".

If you have compute-intensive effects such as Neat Video, etc, that may cause timeline slowdowns, even in proxy mode.

However you report slowdowns from simply searching for clips in events. I don't know why an M1 Mac would handle that vastly faster, if presented with the same library and the same # of projects. Those are simply SQLite database operations. If on the M1 the library was located on an SSD and on the x86 iMac it was on rotating storage, that could account for it.

There is also SQLite overhead in opening each event and project database, so FCP will try to defer that in libraries with tons of events and projects. When you click on a project it may then try to open those in the background, causing a slowdown. If your test case on M1 was just the project and related media -- not the entire library with many snapshots and alternate projects, that could be a difference.

In the past there were some cases where AVCHD .mts files were removed from the bundle and imported with "leave files in place" which would poison overall database performance -- even if only a small % of files. If anything like that has happened it's conceivable the M1 has some kind of decoding or I/O efficiency which handles that better.

The M1 is also resistant to buggy FCP plugins since on Apple Silicon those must be re-written to use FxPlug 4, and all previous MacOS kernel extensions must be re-written to use the new "system extension" framework. 

Some or all of these factors could account for why when testing your same library, FCP on the M1 avoids the problems seen on x86. If FCP was inherently buggy or incapable of handling a large library with many thousands of clips, it would also be slow on M1.

Ok - very interesting. I am indeed using proxy preferred so will check if thats the difference.

joema wrote:

The M1 is also resistant to buggy FCP plugins since on Apple Silicon those must be re-written to use FxPlug 4, and all previous MacOS kernel extensions must be re-written to use the new "system extension" framework.

I had (have) huge beachballing issues when using audio plugins that aren't re-written for Apple Silicon. One reason is that Apple has a service (you can watch it work in activity Monitor) which emulates x86 for audio plugins. This uses a LOT of RAM sometimes, and if you only have 8 (or even 16GB) it can really tax the system. If you have some slowdowns or issues, I would try removing the plugins in your /Library/Audio/Plugins folder and putting them back one-by-one, seeing which ones slow down the system. In doing this I was able to trace my problem to the iZotope RX 8 Audio Denoise plugin (which is not supposed to be supported in FCP anyway, but it does work most of the time). Once I removed this plugin everything was very responsive. 

Anyway, take the time through deduction to figure out where the problem is and you won't be sorry.

FWIW - Over successive versions of recent FCP updates (all running on Intel Macs), I've seen increased issues with third-party audio plug-ins. Some work well, but the UI doesn't look right. Others take a long time to load. Some simply don't work or crash the app. Bear in mind that these same plug-ins work perfectly well in Logic Pro on the same Macs. They also work fine in the Adobe apps and Resolve. So for now, I would simply caution anyone using third-party audio plug-ins in FCP - Intel and M1. Some seem to be optimized for FCP and others haven't been. It's not just a matter of being AU-compatible.

I'm not using any audio plugins inside FCP, although I do have native instruments Reaktor installed as an AU for my music work (use it in Ableton and Logic Pro). Thats about it for audio plug ins though...