[Joe Marler]

[Jim Hart] “all browsers, firebox included, play fine on my 15 inch MacBook Pro and my MacBook Air.”

Could you please re-state what machines you’ve tested this on — the year, model and config if each machine, also what version of MacOS on each machine?

I mostly focused on desktop machines but my top-spec 2019 MacBook Pro 16 showed the problem, maybe to a lesser degree, or maybe harder to see due to the smaller screen. I will re-examine that.

It currently appears to not happen on Windows using the main browsers and only on Mac on FireFox and to a lesser degree Chrome. The fastest (though distasteful) workaround is add a note to the video description advising Mac users to play the video on Safari for the best experience.

As already discussed a partial workaround is export the video using Compressor using a 120 keyframe interval. That doesn’t totally fix it on FireFox but it lessens it.

I will try to examine this further, as it has broad implications for any producer of high quality streaming content.

[Joe Marler]

[Jim Hart] “Plays fine in Safari, play almost perfect n Chrome, Firefox is still bad.”

I just tried a 4k/60 ProRes file from a BlackMagic camera, exported from Resolve Studio 16.2.3 to 4k/60 H264, keyframe size=30, uploaded to Youtube and the jitter still happens if streamed from Mac FireFox 77.0.1 on an iMac Pro running Catalina 10.15.5.

This proves it has nothing to do with FCPX. It is a problem with Mac FireFox and (to a lesser degree) Mac Chrome. Whether the fault is in the app itself or how the app is using MacOS APIs or MacOS itself is unknown.

Obviously this is a major issue for any streaming content producer who wants consistent high quality presentations across various platforms. The entire goal of browser standardization is to avoid directives to use one type of browser or platform.

At this point there are three steps to take: (1) Try to find a workaround, (2) Further examine problem bounds on various platforms, e.g, does it happen on Chrome/FireFox on iPad? Does it happen on MacOS before Catalina? (3) Report the bug to Apple OS support (not FCPX), Google and FireFox.

I haven’t looked so far, but it can probably be seen on various Youtube material people have uploaded, if played by Mac FireFox. There is nothing unique or incorrect about what FCPX or Resolve are doing on the encode side.

[Joe Marler]

[Jim Hart] “I think certain Mac hardware might be my issue.PC’s play fine. My MacBook Pro and MacBook Air play all browsers fine as well I just discovered…it is my 2017 iMac and my 2020 iMac Pro that play jittery in all browsers but Safari. WTH?”

This is a complex issue. I don’t think FCPX is doing anything wrong. There is a performance deficiency in the video decoding in Mac FireFox and Chrome. FireFox is worse, and it happens during local disk playback by the browser, not just during streaming. IOW you will see it in FireFox by just doing File>Open and playing the clip – before uploading it. However it must be 1080p as FF apparently can’t play a local 4k H264 clip with good performance.

It’s not hardware specific as I tested a 2017 10-core Vega 64 iMac Pro, a top-spec 2017 iMac 27 and a top-spec 2019 MacBook Pro 16, and it happens on all of them, all running Catalina 10.15.5.

I then tried exporting the same 4k/60 file using Resolve Studio 16.2.3, and it seemed to not happen. Inspection of the file header shows Resolve used a keyframe interval of 120 frames, whereas FCPX used 30 frames.

I then sent the same timeline to Compressor and created a custom preset for a keyframe interval of 120, and it seems to work better (maybe not perfectly) in FireFox, including after upload and transcode by Youtube.

FCPX is not doing anything wrong, but this might be a workaround. The larger keyframe interval may be making the decode easier. If you have Compressor you can create a similar preset and use that. In Compressor under Video Sharing Services, right-click 4k and pick “duplicate”. That creates a duplicate preset you then modify.

Select that new preset in the left sidebar and at the right, select the video tab, for Data rate pick “computer playback”, for Key Frame Interval pick “Every” and enter 120 frames.

Then in FCPX do File>Send to Compressor and in Compressor drag/drop your new preset on top of the project in the middle pane, then click the Start Batch button at the bottom. When it finishes upload it to Youtube and test the playback in FireFox.

[Joe Marler]

OK, I will work on this more tomorrow. I am concerned there’s a generic problem with the stream decoder on Mac Chrome and Firefox for certain scenarios, maybe unique to certain Mac hardware types such as those with a certain version of Quick Sync on a certain MacOS version. It is subtle enough that most people wouldn’t notice it but if you care about quality to a diverse viewership, it’s not good.

[Joe Marler]

[Jim Hart] ” The jittery is only happens after being uploaded to Vimeo and YouTube. Even then, it plays perfect in Safari. It is the other browsers that are jittery.

So, to to be clear,…you want me to try and export as 1080P 60FPS, upload that to Vimeo, then download the file from Vimeo and play it on my Mac?”

First export as 1080p/60, upload to Youtube and Vimeo, and try normal streaming playback with Mac Chrome & Firefox. If shooting at 1080p/60 with your camera avoids the problem, maybe just exporting from FCPX at 1080p/60 then uploading that file will avoid it.

Re downloading the file, after upload the file is re-encoded by both Youtube and Vimeo. You are not streaming the exact file you uploaded. It seems likely there is something going wrong with the Mac version of Chrome and Firefox when streaming an uploaded 4k file — even if streamed at 1080p. However — maybe the cloud-based re-encoding process did something which exposes a bug unique to Mac Chrome and Firefox. Downloading that re-encoded file lets us investigate that locally.

With Vimeo (not Youtube) it’s possible to download that re-encoded file. If your Vimeo account has enabled downloads, you’ll see that option. However this is only available for Vimeo Plus, Pro, Business, and Premium versions.

If you have one of these versions you can download the re-encoded file and try to play it with Quicktime, VLC *and* Chrome/Firefox. To play a local file with a web browser, enter the path to the file. An easy way to get the complete path is drag/drop the file from Finder to Terminal. That will produce the complete path and you can copy/paste that file pathname from Terminal to the query box in Chrome/Firefox. It will locally decode and play the file in the browser.

If you don’t have the right version of Vimeo you could try to capture the stream using one of the available 3rd-party tools, then try to play that file. The capture tool I use is Downie, but there are many: https://software.charliemonroe.net/downie/

This could be a bug in the Mac version of Chrome and Firefox, or it could be an underlying MacOS bug which Chrome/FF are exposing.

Even if isolated to 4k/60, it is a troubling situation because you tried both ProRes and H264, and 4k/60 uploads are very common, as is playback by Mac Chrome and Firefox.

There have been so many serious bugs on Mac Chrome that I personally would not advise any FCPX user to use that, but even excepting that, the jitter problem also happens with Mac FireFox.

[Joe Marler]

[Jim Hart] “The ONLY thing I am doing differently is shooting 4k 60FPS instead of 1080P 60 FPS. All my videos shot at 1080p 60 FPS are playing perfectly as always in normal window sizes and in full screen. It is the 4K and I don’t know why!

I guess I am going to have to shoot everything over again in 1080p 60FPS “

Using your current material, can you export as 1080p and upload to Youtube instead of exporting and uploading as 4k?

If 4k files are uploaded to Vimeo, does Mac Chrome and Firefox have the playback jitter, or is it only Youtube? I think you said yes, just wanted to be sure.

What if you then download the encoded 1080p Vimeo file and play it locally with Quicktime and VLC? That would help determine whether the problem involves the streaming decoder for Mac Chrome/FireFox, or whether it happens if locally decoded by Quicktime and VLC.

[Joe Marler]

[Tim Wilson] ” Apple put a lot of effort into reshaping the top of their computing product line. They know better than anyone that these ARM chips aren’t ready for THAT.”

That was formerly my view, but as of this month the world’s fastest supercomputer is run by ARM CPUs, the 48-core ARM A64FX by Fujitsu. It will also be used in the new Cray: https://spectrum.ieee.org/tech-talk/computing/hardware/japans-fugaku-supercomputer-is-first-in-the-world-to-simultaneously-top-all-high-performance-benchmarks

The single A64FX appears to be roughly 50% to 300% faster than a dual 28-core Intel Xeon Platinum 8168, and consumes less power: https://www.fujitsu.com/global/Images/supercomputer-fugaku.pdf

Whether and when Apple pursues a similar-level ARM CPU is unknown, but it appears there is no technical problem scaling ARM to that level or above.

The question then becomes why do the x86 Mac Pro? You could just as well ask why do any x86 Mac the past 12 months. The design of those machines began years ago, and the ARM transition was not ready and will itself be years long.

It’s not just a hardware transition but involves system software, application software, development tools, and educating and marshalling the development community. They couldn’t stop making x86 computers and wait for that to happen — Apple customers needed updated computers.

[Joe Marler]

[Cal Thorley] “If FCPX can handle 4K XAVC-I without being a slug then it’ll be doing better than PP.
I know H.264 isn’t much fun to unpack so if I need to transcode any footage off my Sony A6300, drone, or gopros then I can live with that. It’s always going to be a small percentage compared to the FS7 material which is still my main camera.

If I have to transcode the XAVC-I then I may as well just stick with Premiere.”

In my tests you likely won’t need to transcode XAVC-I. XAVC-S and -L are another matter — at least on current Macs, although there is some variation.

The current limitation is efficiency of hardware-accelerated decoding and how that’s used by the NLE. For these codecs Premiere does a horrible job on current Mac hardware. FCPX is a lot better, but on the iMac Pro which apparently uses T2 decoding, it’s still sluggish. On 2017 and later iMacs it’s somewhat smoother, and the 2019 iMac and MBP 16 seem a little better still. This is probably from incremental improvements to Intel’s Quick Sync. Resolve is also pretty good.

Longer term I think the new ARM-powered Macs may have a big advantage, but nobody knows for sure. At least Apple will gave total control over hardware accelerators and the ARM design favors greater use of these due to the smaller chip real estate consumed by the CPU core.

[Joe Marler]

[Jim Hart] “…shoot all my video in 4K60FPS….export as H.264, then upload to Vimeo, YouTube…run buttery smooth in a normal window and at full screen in Safari, but have a slight jitter in Chrome and Firefox. The jittery is really pronounced in full screen.”

If I run them full screen at 1080p/60, I do see some jitter, esp. on FireFox 77.0.1. If I right-click and select “Stats for Nerds” it shows both FireFox and Chrome are using Google’s VP9 codec, whereas Safari is using AVC (ie H.264). This is on a 10-core Vega 64 iMac Pro on Catalina 10.15.5, with Comcast hard-wired 350 mbps, 8 millisecond ping and 1.9 millisecond jitter.

My first guess was it’s a VP9 issue but I used this Chrome extension to force use of AVC, and it still happened: https://blog.kylemanna.com/media/force-youtube-to-stream-h264-avc-with-h264ify/

I don’t have a Windows machine but I tried it using the latest Windows 10 on VMWare for both Windows Chrome and Edge. It still happened there, but that could be VMWare.

As a test I suggest exporting as ProRes 422 (not HQ) and uploading directly to Youtube. That at least removes one encode/decode step between Long GOP codecs. Yes the file is big but this is only a test. If needed just do 1/2 the timeline.

If you have access to an actual Windows machine it would be interesting to see how Chrome, Edge and FireFox behave on that.

Make sure all your original media is truly 60 fps, the timeline is 60 fps and the exported file is 60 fps. If there is any frame rate mis-match, the FCPX rate conforming process can inject motion cadence issues. I don’t think that’s the case here (else you’d see it on Safari), just mentioning it.

[Joe Marler]

[andi no] “I want to make all those selected clips to have the same out point at the red playhead. So fcp should trim/extend those clips to the playhead.”

Blade all layers at current playhead or skimmer location: SHIFT+CMD+B: https://support.apple.com/kb/ph12724?locale=en_US

Extend all layers of selected clips: CTRL+ D and set a longer duration (type +10 for 10 frames, or +10. for 10 sec), make sure all layers are selected, then OPT + ] will trim all your clips to the playhead.

At 3:00 into this video, T. Payton shows how to do this a layer at a time. It’s a little slower than just selecting all and doing OPT+] but it’s still pretty fast: https://www.youtube.com/watch?v=9WjnjQXUEHI

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.