Chrome causing Final Cut Pro X to slow down, freeze, and crash

AppleInsiderAppleInsider
Posted:
in Mac Software edited June 2019
Chrome is causing Final Cut Pro X to become unresponsive and crash for some users by hogging video encoding frameworks, a noted video editor has claimed on Twitter.

Final Cut Pro X
Final Cut Pro X


Felipe Baez, Creative Director and founder of Cre8ive Beast has pegged Chrome as the reason many users have been experiencing massive slowdowns within Final Cut Pro X.

It appears Chrome is to blame, hogging necessary resources which brings Final Cut Pro X to a halt.

If you use FCPX, don't use Chrome. Well, if you use any editing app, don't use Chrome. Just discovered Chrome locking down the VideoToolBox framework and making FCPX REALLY slow and crashing.

-- Felipe Baez (@baezfelipe)


"Just discovered Chrome locking down the VideoToolBox framework and making FCPX REALLY slow and crashing," Baez shared on Twitter.

Chrome at some point apparently accesses and monopolizes VideoToolBox, which is a low-level framework that gives Final Cut Pro X access to hardware-based encoders and decoders when working with video. When Chrome starts using VideoToolBox, it doesn't stop, which causes a problem for video editors.

Baez says he clocked the CPU usage at 300% and resulted in FCPX locking up and crashing. Once he quit Chrome and VideoToolBox was released, Final Cut Pro X was able to operate as normal.

This issue won't just plague Final Cut Pro X, it will apply to any video editors or transcoders that are relying on VideoToolBox for encoding, decoding, and transcoding. Chrome is a notorious resource hog, frequently occupying large amounts of RAM for Mac users.

Preliminary testing on Handbrake is showing an impact on encode times, with a first run with nothing else running but an idle Chrome and Handbrake using VideoToolKit showing approximately a 30% hit to H.265 encoding speeds versus Handbrake and Safari running. AppleInsider is continuing to look into the situation.
thefatangel
«1

Comments

  • Reply 1 of 39
    racerhomie3racerhomie3 Posts: 1,264member
    Never trust Google. #switchtoduckduckgo
    MacProandrewj5790StrangeDaysEsquireCatscat52magman1979sweetheart777mobirdgreg uvanwatto_cobra
  • Reply 2 of 39
    ericthehalfbeeericthehalfbee Posts: 4,486member
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    larryjwMacProchaickacat52xyzzy01irelandgreg uvanRayz2016watto_cobra
  • Reply 3 of 39
    larryjwlarryjw Posts: 1,031member
    ericthehalfbee said:
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    Well, the problem is Unix, Linux, MacOS seem to not be preemptive OSes in Kernel Mode, where it seems this Framework is executing. 
    cat52greg uvanwatto_cobra
  • Reply 4 of 39
    knowitallknowitall Posts: 1,648member
    Like the Adobe Flash gaffe.
    MacProolsmagman1979
  • Reply 5 of 39
    JinTechJinTech Posts: 1,022member
    racerhomie3 said:
    Never trust Google. #switchtoduckduckgo
    If only Duck Duck Go had a web browser.
    greg uvan
  • Reply 6 of 39
    knowitallknowitall Posts: 1,648member
    larryjw said:
    ericthehalfbee said:
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    Well, the problem is Unix, Linux, MacOS seem to not be preemptive OSes in Kernel Mode, where it seems this Framework is executing. 
    Handbrake (more than excellent tool by the way) seems to be doing fine.
    Google snafu so it seems.
    MacProolscat52watto_cobra
  • Reply 7 of 39
    MacProMacPro Posts: 19,727member
    I am sure the resident Google representative will soon explain everything.
    StrangeDaysEsquireCatscat52magman1979mobirdwatto_cobra
  • Reply 8 of 39
    thefatangelthefatangel Posts: 4member
    I am interested to know if this only affects Google Chrome specifically, or if it also affects other Chromium-based browsers such as Brave (my current favorite).
    cat52kestral
  • Reply 9 of 39
    MacProMacPro Posts: 19,727member
    Maybe Chrome's a Google 'wrench'.
    magman1979watto_cobra
  • Reply 10 of 39
    macplusplusmacplusplus Posts: 2,112member
    knowitall said:
    larryjw said:
    ericthehalfbee said:
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    Well, the problem is Unix, Linux, MacOS seem to not be preemptive OSes in Kernel Mode, where it seems this Framework is executing. 
    Handbrake (more than excellent tool by the way) seems to be doing fine.
    Google snafu so it seems.
    Maybe you forgot to choose Video Toolbox in the encoding menu? Try again. AI says 30% which means something.
  • Reply 11 of 39
    macplusplusmacplusplus Posts: 2,112member
    MacPro said:
    I am sure the resident Google representative will soon explain everything.
    Don’t shoot the messenger. Such things are at the discretion of only the boss and a couple of coders.
  • Reply 12 of 39
    Mike WuertheleMike Wuerthele Posts: 6,861administrator
    knowitall said:
    larryjw said:
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    Well, the problem is Unix, Linux, MacOS seem to not be preemptive OSes in Kernel Mode, where it seems this Framework is executing. 
    Handbrake (more than excellent tool by the way) seems to be doing fine.
    Google snafu so it seems.
    Maybe you forgot to choose Video Toolbox in the encoding menu? Try again. AI says 30% which means something.
    There are some variables we're still working on. Handbrake to H.265 with VideoToolbox encoding in 4K and 1080p with just about any news venue's site open in Chrome in the background or even in a tab absolutely causes the slowdown. We've also gotten some responses on social media about other folks finding the same thing.

    H.264 video doesn't seem to be as much of a problem, if impacted at all. Also, Electron apps like Slack using elements of Chrome don't seem to have any impact.
    edited June 2019
  • Reply 13 of 39
    macxpressmacxpress Posts: 5,808member
    Why people would want to use Chrome is beyond me...Safari is pretty damn good as it is.
    olsStrangeDayssteven n.radarthekatEsquireCatsmagman1979andrewj5790sweetheart777camccrosslad
  • Reply 14 of 39
    joedaman88joedaman88 Posts: 3member
    ericthehalfbee said:
    While I think it's poor coding on the part of Google to monopolize a resource, I also think Apple should make it so that an App can't monopolize any framework.

    This reminds me of the early days of Windows and co-operative multitasking where you had to rely on a program to behave and not steal all the processor time sp your other programs could also run.
    Reminds me when Woz was trying to tell Apple that Internet Explorer was the cause of OS crashes before OS X. Google's way of killing the Mac Experience.
    watto_cobra
  • Reply 15 of 39
    fastasleepfastasleep Posts: 6,417member
    macxpress said:
    Why people would want to use Chrome is beyond me...Safari is pretty damn good as it is.
    The only compelling reason I've heard is that Google Docs runs better on it. Of course my followup statement would be, why people want to use Google Docs is beyond me...
    StrangeDaysradarthekatmagman1979andrewj5790sweetheart777crossladRayz2016Gilliam_Batesdarwiniandudewatto_cobra
  • Reply 16 of 39
    osmartormenajrosmartormenajr Posts: 287member
    On the bright side, newer Mac models with north of 32 GB of RAM, will also mitigate this problem.
    I’m no web developer, and also don’t know if it would make a difference, but I’ve only ever used Safari, and I’m baffled why would people install chrome... even on windows or Linux boxes.
    sweetheart777watto_cobra
  • Reply 17 of 39
    mcdavemcdave Posts: 1,927member
    I thought Chrome caused everything to slow down, freeze & crash.
    sweetheart777docno42watto_cobra
  • Reply 18 of 39
    StrangeDaysStrangeDays Posts: 12,877member
    JinTech said:
    racerhomie3 said:
    Never trust Google. #switchtoduckduckgo
    If only Duck Duck Go had a web browser.
    What would it do that Safari doesn’t? I think his point was Google’s primary value proposition remains its search. 
    magman1979watto_cobra
  • Reply 19 of 39
    StrangeDaysStrangeDays Posts: 12,877member
    mcdave said:
    I thought Chrome caused everything to slow down, freeze & crash.
    It’s a feature, not a bug. 😎
    magman1979watto_cobra
  • Reply 20 of 39
    thttht Posts: 5,443member
    JinTech said:
    racerhomie3 said:
    Never trust Google. #switchtoduckduckgo
    If only Duck Duck Go had a web browser.
    There’s a web browser from DuckDuckGo on iOS. Maybe with Catalyst it will be available for macOS Catalina. 
Sign In or Register to comment.