2065262 - Firefox performance degrades during repeated seeking with VP9 video.

Status: RESOLVED FIXED

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

Description

[Meliss]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:154.0) Gecko/20100101 Firefox/154.0

Steps to reproduce:

Open YouTube in Firefox.
Start playing video (https://www.youtube.com/watch?v=idFqSSbpXcA&t=5201s).
Seek forward and/or backward several times.
Continue watching the video.

Actual results:

After seeking several times, video playback becomes increasingly laggy and starts to stutter.

YouTube may automatically reduce the video quality. Eventually, playback may stop completely and YouTube displays an error such as:

An error occurred. Please try again later. Playback ID: XXXXXXXX

The problem appears to occur after repeatedly seeking through the video.

Expected results:

Video playback should remain smooth after seeking, with no unexpected quality degradation or playback errors.

Comment 1

[Meliss]

Attachment: 2026-08-17-175147.mp4

Comment 2

[Meliss]

The issue can be avoided by disabling VP9 and WebM playback in Firefox. With these settings disabled, YouTube uses other codecs such as AV1 or H.264, and the browser behaves stably during video playback.

The following preferences are currently disabled as a workaround:

media.mediasource.vp9.enabled = false
media.webm.enabled = false

When VP9/WebM playback is enabled, YouTube playback may become laggy and eventually fail after seeking. With VP9/WebM disabled, playback using AV1 or H.264 remains stable.

Comment 3

[BugBot [:suhaib / :marco]]

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.

Comment 5

[Meliss]

The problem can be observed in Firefox 153, 154, 155, and 156. In general, VP9 playback at 1440p and 4K is affected: the video quality often drops dramatically to 480p or even 144p.

This looks like a real Firefox-side defect in handling repeated seeks with VP9/WebM. The most likely areas are the decoder lifecycle, MSE/WebM buffering, and the hardware VP9 decoding path.

The fact that switching to AV1 or H.264 completely eliminates the issue is a very strong differential test and strongly suggests that the problem is specific to the VP9/WebM playback path in Firefox.

Comment 6

[Meliss]

Attachment: zapis-2026-08-22-132129_CQEDLkat.mp4

Comment 7

[Meliss]

I noticed the same issue, and it doesn't seem to be limited to a specific video format. As a temporary workaround on my PC, setting media.webm.enabled = false prevents the problem for me.

I also tested Firefox on Android 16, and interestingly, videos can crash there as well when repeatedly seeking/rewinding. This makes me think the issue may be related to Firefox's media playback/seek handling rather than being specific to Windows, NVIDIA drivers, or my PC hardware.

Comment 8

[Jim Mathies [:jimm]]

Could you help us out by trying to capture a Firefox performance profile when this happens? Visit https://profiler.firefox.com/ for more information and to enable the profiling toolbar button. When capturing a profile, please follow these steps -

1. Navigate to about:logging
2. In the logging preset drop down, select 'Media playback' and then click 'Set Log Modules'
3. Click 'Start Logging' and conduct your testing. Keep this part short. Capture the issue well.
4. Upload the resulting performance profile and post the url provided to this bug.

Thanks!

Comment 9

[Jim Mathies [:jimm]]

In the capture video, I do not see dropped frames. The crash at the end appears to have to do with avc content. Please try to capture any of these issues in a good Firefox profile!

Comment 10

[Meliss]

@Jim Mathies [:jimm]
https://profiler.firefox.com/public/jsfvgv13408wmm59a9avftxgbm6swgn8janavs8/calltree/?globalTrackOrder=0ed61c7bw84235&hiddenGlobalTracks=1wc&hiddenLocalTracksByPid=17032-0wors~18292-0w5~21384-01~17816-01~4460-0w2~13708-01~5304-0w5~9360-0w4~19960-0w5~10324-0w5~4908-0wf~8096-0w7~15532-0w5~4512-02wacwfhwkmwr~3224-0w46wilmowtvx1wx3x5x8wxnxqwxs&thread=za&v=17

Comment 11

[Meliss]

with this video(https://www.youtube.com/watch?v=idFqSSbpXcA&t=5201s).

https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=0dwb856a297341&hiddenGlobalTracks=1wb&hiddenLocalTracksByPid=17032-0wknwp~17816-01~21384-01~13708-01~4460-0w2~9360-0w4~4908-0wn~19308-0w5~16348-0w6~20044-0w5~13216-0w5~15532-0w5~4512-02w8awcfwkmwr~3224-0w46w8awikwtvwx4x7x8xaxcwxvy2wy4&thread=z3&v=17

Comment 12

[az [:az]]

I think this might be related to Bug 1341228.

Could you please try this build and let me know if it fixes the issue? Thanks!

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QcUDmcqyRrK5qVqgvW6AAg/runs/0/artifacts/public/build/target.zip

Comment 13

[Meliss]

I tested this build with several different videos and repeated seeking, and everything seems to be working well. I can no longer reproduce the issue.

Thanks! Should we expect this fix to make it into the stable Firefox branch?

Comment 14

[az [:az]]

Thanks for checking and reporting back! The fix will have to go through review first, but since it's not a major change I'm hoping it'll be part of the 156 release.

Comment 15

[az [:az]]

Attachment: Bug 2065262 - Part 1: Stop the WebM init segment boundary running into a following init segment. r?kinetik

Comment 16

[az [:az]]

Attachment: Bug 2065262 - Part 2: Add tests for the WebM init segment boundary across back to back init segments. r?kinetik

Comment 17

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1341228

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2359f15d090b
https://hg.mozilla.org/integration/autoland/rev/62c5b7dbc9e4
Part 1: Stop the WebM init segment boundary running into a following init segment. r=kinetik,media-playback-reviewers
https://github.com/mozilla-firefox/firefox/commit/6738d6d18e49
https://hg.mozilla.org/integration/autoland/rev/970eb072a2e9
Part 2: Add tests for the WebM init segment boundary across back to back init segments. r=kinetik,media-playback-reviewers

Comment 19

[Alastor Wu [:alwu]]

If the fixes are not risky, should we uplift them to Fx155? Given that this affects video resolution on Youtube?

Comment 20

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/62c5b7dbc9e4
https://hg.mozilla.org/mozilla-central/rev/970eb072a2e9

Comment 21

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/62c5b7dbc9e4
https://hg.mozilla.org/mozilla-central/rev/970eb072a2e9

Comment 22

[Ryan VanderMeulen [:RyanVM]]

This isn't a new issue in 155, so I'd rather let this bake for a couple weeks and ride 156 instead. We probably should consider an ESR153 backport eventually, though.

Comment 23

[az [:az]]

Attachment: Bug 2065262 - Part 1: Stop the WebM init segment boundary running into a following init segment.

Original Revision: https://phabricator.services.mozilla.com/D321725

Comment 24

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Reduced YouTube performance / resolution including videos stopped entirely with playback errors.
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: Included in bug if needed
• Risk associated with taking this patch: low
• Explanation of risk level: Targeted patch affecting a single line of code reviewed by expert in area
• String changes made/needed?: N/A
• Is Android affected?: yes

Comment 25

[az [:az]]

Attachment: Bug 2065262 - Part 2: Add tests for the WebM init segment boundary across back to back init segments.

Original Revision: https://phabricator.services.mozilla.com/D321726

Comment 26

[az [:az]]

Just finished the uplift requests before seeing this, happy to let them bake then. Let me know if you need anything else from my side and I'll be happy to help (or obsolete the current ones in the queue if needed), thanks!

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Yeah, please go ahead and drop them. BTW, does this depend on a Nestegg update too? I see the bug dependency but didn't see that included in the stack.

Comment 28

[az [:az]]

I don't think it relies on a nestegg update - pinging :kinetik to make sure.

Comment 29

[Matthew Gregan [:kinetik]]

Yeah, this fix doesn't rely on nestegg changes so is fine to uplift standalone.