Open Bug 1989948 Opened 1 month ago Updated 1 day ago

After I updated to macOS 26, I've noticed video lags (audio keeps playing), especially but not only on YouTube.

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 143
Type:
defect

Tracking

()

People

(Reporter: jslichter, Assigned: alwu, NeedInfo)

References

Details

User Story

STR
1.  ensure your MacOS is 26.0+
2. open a YouTube video (eg. https://www.youtube.com/watch?v=zCLOJ9j1k2Y)
   * the higher the resolution is, the easier to reproduce the error
3.  Start playing the video
4. During playback, open macOS System Settings. You can do this by pressing Option + F1, F2, F3, F10, F11, F12, F14, or F15;

Expected:
5. No stuttering

Actual results:
5. The video starts to jerk a lot, and sometimes even freezes/hangs for a while. You can observe dropped frames on the `stats for nerds`.

Note, for (4), opening Spotlight and start doing calculations on it will also cause the issue.

Attachments

(3 files)

about:support
30.76 KB, text/plain
Details
Instruments System Trace showing the VTDecoderXPCService thread being ready to run but not running
182.03 KB, image/png
Details
WIP: Bug 1989948 - WIP : promote MediaPDecoder.
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:143.0) Gecko/20100101 Firefox/143.0

Steps to reproduce:

Play any video on YouTube.

Actual results:

After a bit, the video freezes while the audio continues.

Expected results:

Video should not have frozen.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

I can reproduce the exact behaviour. It's very annoying.

In addition I realized, that as soon as my Mac has a heavy load like compiling bigger projects, Youtube-videos tend to start stuttering, too.

This is with Firefox 143.0.1 on MacOS Tahoe 26.0 on a M1 MacBook Pro.

All Youtube- and Site-blocking-relevant plugins are disabled.

Brave-Browser does not show this behaviour.

Could you help me capture a media profile by following this instruction? Thanks!

Flags: needinfo?(jslichter)
Flags: needinfo?(bugzilla)

Same problem here, it's unusable when it happens. When i will happen again i'll try to get a media profile

https://share.firefox.dev/3VHpO6o

Managed to capture it happening. Many frames dropped right at the start of the log and before ending it. Happens consistently with 1440p and 2160p 60fps YouTube videos. Zero issues like this happened in previous OSes. I had no issues playing 1440p@60 at 2x speed, with only 2160p@60 at 2x speed dropping frames (Still less frames than it drops at normal speed now).

Unfortunately, your profile is missing important logging information. Did you follow the about:logging instructions I mentioned in comment 3, or did you use the Firefox Profiler directly? We know that sometimes the Firefox Profiler has bugs that prevent logs from being captured correctly. If you didn’t use about:logging, could you please try again the next time the issue occurs?

From your profile, I do see some dropped frames, but I can’t determine the cause without the logging information. I also noticed that hardware decoding for VP9 wasn’t used, even though it should be enabled on your device. Could you also attach your about:support information?

Thanks!

Flags: needinfo?(richard)
Attached file about:support —
I enabled the profiler icon via https://profiler.firefox.com/, then set it to media preset. I triggered the recording when I noticed the video was playing via the keyboard shortcut. Is this procedure flawed? VP9 HW decoding being disabled seems incorrect to me judging by the very low CPU usage, but I may be wrong. ``

I rechecked your profile and confirmed that it did use hardware decoding for VP9—my mistake. The hardware decoding–related graphics features also appear to be enabled correctly in your about:support. At this point, we’ll just need a new profile to continue debugging the issue.

The method of using the Firefox Profiler directly is part of an older workflow. We now recommend using about:logging, which can capture Gecko internal logs.

Thanks!

Understood. https://share.firefox.dev/42kjSE3
Is this better? Major frame drops at the beginning, then only like 20 dropped frames afterwards. I can provide a longer snippet if needed, but it's sometimes hard to catch it. Classic debugging tale - happens all the time except while logging.

Flags: needinfo?(richard)

The new profile is perfect! In addition, could you also help me verify if turn off the pref media.hardware-video-decoding.enabled then restart Firefox, to see whether this issue will happen on software decoding as well? Thanks!

Flags: needinfo?(richard)

By the way, could anyone provide me with a specific video link? I’m also wondering if this issue might be related to a particular video codec. I wasn’t able to reproduce it on my Apple M1 Max running macOS 26.0. However, I did notice that frame drops seem to occur more frequently than before. While they aren’t visually noticeable in my case, I confirmed them through the “Stats for Nerds.”

Duplicate of this bug: 1991956

From bug 1991956, there is a STR I can also reproduce the issue.

I also noticed that the video starts to jerk and stutter if I open it full screen, open Spotlight, and start doing calculations on it.

Severity: -- → S2
Priority: -- → P1

The new profile is perfect! In addition, could you also help me verify if turn off the pref media.hardware-video-decoding.enabled then restart Firefox, to see whether this issue will happen on software decoding as well? Thanks!

Tested in the latest dev version of Firefox — 144.0b8. Yes, the problem still exists even after switching "media.hardware-video-decoding.enabled" to "false".

User Story: (updated)

I also noticed that the video starts to jerk and stutter if I open it full screen, open Spotlight, and start doing calculations on it.

In Chrome and Safari, in this case, there are no problems either! 🤷‍♂️

I updated the STR in the user story. From my observation, the VTDecompressionSessionDecodeFrameWithOptions got blocked whenever a new macOS layer was created (e.g., opening System Settings, Finder, or other applications). This suggests that layer creation may interfere with how our decoded texture is handled.

Currently, the texture is shared through a MacIOSurface. I suspect there may be an issue related with that—either the renderer is doing something incorrectly, or the surface isn’t being set up correctly.

Attached is a graphic + media profile for reference. In addition, this issue will happen on both sw and hw decoding, and it seems MacOS 26 only.

Jeff, Brad, do you have any thought about this? Thanks!

Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bwerth)

There are two profiles for SW ffvpx decoding on AV1 [1]. In both, the decoding pattern looks similar, with ~20% of the time spent in mozilla::layers::MacIOSurfaceImage::SetData. I haven’t noticed anything clearly suspicious yet. However, one abnormal behavior stands out: there are some significant janks in the Privileged Content process (pid: 5160) when the issue occurs, which appears to be related to the display list?

[1]
Bad (stuttering) : https://share.firefox.dev/474silA
Good : https://share.firefox.dev/4pSgH0y

On macOS 26 (Tahoe), we’re observing playback stutters that appear compositor/renderer-related rather than decoder-specific. The problem reproduces consistently across VideoToolbox playback, WebRTC, and WebGL canvases.

Notably, when the Settings app is opened, Firefox’s rendering appears to block, which suggests that our renderer/compositor may be synchronously waiting on Core Animation/WindowServer operations (e.g., layer commit, drawable acquisition, or IOSurface release).

One working hypothesis is composition back-pressure: the new Liquid Glass feature may increase WindowServer/CA load, causing IOSurface-backed frames to remain “in use” longer. This could delay frame recycling, leading to starvation in decode and present paths.

Given that the issue reproduces beyond media playback, it may be worth having the graphics team investigate from a compositor/WindowServer interaction perspective.

Bob, could you find someone in the graphic team to help investigate this issue as well? Thanks!

Blocks: gfx-triage
Flags: needinfo?(bhood)

Haven't updated to Tahoe yet -- waiting to finish landing some important patches -- but when I do, I'll replicate and take the Bug.

I'd like to add that I've confirmed this happening on any quality videos, not just high rest 60fps. I've had it happen on 1440p30 and 1080p30 on YouTube. All VP9 HW decode. Hope it helps

Flags: needinfo?(richard)

I tried reproducing 26.0.1 and couldn't. Can anyone else reproduce the problem on 26.0.1? (I didn't try 26.0)

I discussed this with Jeff offline, we can now both reproduce this issue on 26.0.1.

Can confirm the issue persists on 26.0 and 26.1 DB1 (25B5042k)

I'm not sure this is related, but it might give more insight into what's happening:

As of MacOS version 26.0.1 (not tested 26.0.0) I've noticed that when you're playing a video in Firefox (Youtube in my case) and you launch an iOS Simulator using Xcode (Xcode 16.4, iOS version 18.6 in case it matters), you start to get weird audio crackles that persist until you close the simulator again. The audio crackles appear to be coming from Firefox, as there doesn't have to be audio playing in the simulator for them to happen, just keep the Youtube video playing for them to occur.

(In reply to René Vlugt from comment #24)

I'm not sure this is related, but it might give more insight into what's happening:

As of MacOS version 26.0.1 (not tested 26.0.0) I've noticed that when you're playing a video in Firefox (Youtube in my case) and you launch an iOS Simulator using Xcode (Xcode 16.4, iOS version 18.6 in case it matters), you start to get weird audio crackles that persist until you close the simulator again. The audio crackles appear to be coming from Firefox, as there doesn't have to be audio playing in the simulator for them to happen, just keep the Youtube video playing for them to occur.

This is a long standing macos coreaudio bug that has nothing to do with firefox

I looked some more at the profiles. One thing that stands out to be me is that it seems like all of our threads are being prevented from running. (i.e. the profiling is missing samples for the region where we drop frames)

I don't know why this would be. I tried looking in Instruments briefly but wasn't able to figure anything out.

I'll update to Tahoe see if I can replicate and move this forward.

Flags: needinfo?(bwerth)

Any news on this issue? Right now Firefox is in semi-unusable state due to this.

We're waiting another round of investigation from graphic perspective, set NI on Brad so he can keep tracking this when he's back.

Component: Audio/Video: Playback → Graphics
Flags: needinfo?(bwerth)

I hope this issue gets resolved soon. I also encountered this problem on M1 and stopped using Firefox, switching to Chrome instead. I want to go back to Firefox!

I've updated to Tahoe. I'll try to reproduce.

Assignee: nobody → bwerth
Flags: needinfo?(bwerth)
Flags: needinfo?(bhood)

(In reply to Brad Werth [:bradwerth] from comment #31)

I've updated to Tahoe. I'll try to reproduce.

Not reproducing for me with FF Nightly 146.0a1 (2025-10-17) running on macOS 26.0.1 (25A362). Audio sounds great to me, with no stuttering. Is it still happening for you?

I've also had this issue occur and there was never any audio stuttering, just video stuttering.

FYI, this is still happening on Firefox 144.0 (Mac OS 26.0.1, running on a MacBookPro18,2.)

Flags: needinfo?(jslichter)

(In reply to jslichter from comment #34)

FYI, this is still happening on Firefox 144.0 (Mac OS 26.0.1, running on a MacBookPro18,2.)

If you would, please try on FF 146 (Nightly) and see if it is still occurring.

Flags: needinfo?(jslichter)

(In reply to Brad Werth [:bradwerth] from comment #35)

(In reply to jslichter from comment #34)

FYI, this is still happening on Firefox 144.0 (Mac OS 26.0.1, running on a MacBookPro18,2.)

If you would, please try on FF 146 (Nightly) and see if it is still occurring.

FF 146 works great! Ran a video that hung in FF144 and no issues. Thank you!

Flags: needinfo?(jslichter)

(In reply to jslichter from comment #36)

FF 146 works great! Ran a video that hung in FF144 and no issues. Thank you!

Wonderful! If you are willing to do the extra work, it would be very helpful for you to run mozregression to identify which code fixed this problem. That way, we could add that code to other versions of Firefox, including in the ESR releases. I just tried to run it myself but I still can't reproduce even with FF143.

Flags: needinfo?(jslichter)

I don't think it's fixed.
Using 146.0a1 I reproduced this issue in seconds just opening fresh browser with no addons and watching youtube.
Any info I can provide to troubleshoot this?

On FF 144 i always notice the problem when doing projects builds. Maybe this info can helps to reproduce it again if the problem is still there on the newest versions

Yes, I can also reproduce with a heavy cpu load, which I get by compiling a big project in the background. I'll record a profile using about:logging, as Alastor suggested in comment 8.

I had a look at this again. When I get hardware decoding I encounter much worse behaviour where the hangs can be very long and recovery doesn't happen. In these cases I end up stuck waiting on a condition variable in VTDecompressionSessionDecodeFrameWithOptions

Flags: needinfo?(jmuizelaar)

It seems like an Instruments System Trace can give us information about what threads are running and why.

Quick update — after talking with Jeff offline, we suspect the issue might be related to process or thread priority. I did a quick test, and it seems to work. I’m doing more testing to confirm, and I’ll submit a patch and a try build soon so others can help verify the fix.

If everything works well, will the current stable version (144) get an update that includes this patch?

(In reply to 5silentrain from comment #44)

If everything works well, will the current stable version (144) get an update that includes this patch?

We do that (an "uplift") whenever it is possible and safe. Once the patch is ready for landing, we'll do that if we can.

Thanks!

Summary: After I updated to Mac OS 26, I've noticed video lags (audio keeps playing), especially but not only on YouTube. → After I updated to macOS 26, I've noticed video lags (audio keeps playing), especially but not only on YouTube.
See Also: → 1994431
See Also: → 1979283

I'm still working on a fix, will submit one ASAP.

Assignee: bwerth → alwu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 1995638

Another quick update — bug 1995638 will likely improve the situation significantly, which uses the similar way to promote threads. We decided to go with that way first as we also heard some non-media related issues happening on MacOS 26. My patch will only affect media-related threads.

However, from my testing, the issue could still occur, but with much milder symptoms. The severe frame drops we saw before are now very rare, though we still occasionally notice an audio pop accompanying minor frame drops. As my testing was done with a debug build, the performance impact and behavior might differ on a Release build.

We’ll continue monitoring to see whether the issue persists or if any new problems appear after bug 1995638 lands.

I tested this video on my Apple M1 Max on the latest Nightly. The issue has been significantly mitigated — only minor frame drops (~3–5 frames for a 60 fps video) can occasionally be observed, and there’s no audio pop sound anymore.

We can definitely continue investigating ways to further optimize performance, as ideally there shouldn’t be any frame drops when opening other applications.

Could anyone help verify the results on their devices as well? Thanks!

As the issue has been mitigated, lower its priority and severity.

Severity: S2 → S3
Component: Graphics → Audio/Video: Playback
Priority: P1 → P2

Can everyone who's been seeing this problem try out Firefox Nightly to see if the problem is fixed or still happening there?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #54)

Can everyone who's been seeing this problem try out Firefox Nightly to see if the problem is fixed or still happening there?

It appears to be fixed, for me. I can no longer reproduce it.

No longer blocks: gfx-triage

(In reply to Alastor Wu [:alwu] from comment #52)

I tested this video on my Apple M1 Max on the latest Nightly. The issue has been significantly mitigated — only minor frame drops (~3–5 frames for a 60 fps video) can occasionally be observed, and there’s no audio pop sound anymore.

We can definitely continue investigating ways to further optimize performance, as ideally there shouldn’t be any frame drops when opening other applications.

Could anyone help verify the results on their devices as well? Thanks!

chrome:
https://cdn.bsky.app/img/feed_fullsize/plain/did:plc:cxuu72skkfto7ar2bvcsvaau/bafkreihocx444lt5suyfwlujjj67j5phbnlvs74whidhvnpnd2u5afhvay@jpeg

firefox nightly:
https://cdn.bsky.app/img/feed_fullsize/plain/did:plc:cxuu72skkfto7ar2bvcsvaau/bafkreicmlj2lcvq5d56vur4r5jsaizcmimp3agov46togsy3prcgus2k6u@jpeg

I'm an M1 Mac mini user, so AV1 acceleration doesn't work, but as you can see, Chrome shows a much lower drop rate even with the same video.

I don't know if this is related to this bug, but I noticed that in Firefox Developer Edition version 145.0b5, there's a noticeable delay when zooming in/out on an image opened in a new tab. For example, if I open this small image and, while holding down the Command key, press and hold the Plus/Minus key to zoom in/out, there's a strange delay that doesn't exist in the current stable version (144).

(In reply to 5silentrain from comment #57)

I don't know if this is related to this bug, but I noticed that in Firefox Developer Edition version 145.0b5, there's a noticeable delay when zooming in/out on an image opened in a new tab. For example, if I open this small image and, while holding down the Command key, press and hold the Plus/Minus key to zoom in/out, there's a strange delay that doesn't exist in the current stable version (144).

Please open a new Bug on this issue.

Okay. I'll create a new bug report about this now.

Here is a link to this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1996144

Nightly release works well now. Side by side the same video is a slide show in release version, smooth in nightly.

Please ask one of the developers to look into this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1994376

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: