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

Steps to reproduce:

I can reproduce by following these steps:

1. Start Firefox/Firefox Beta (Dev Edition)/Firefox Nightly with a new profile without Sync by clicking on the desktop icon
2. Press Ctrl+T to open a new tab
3. Paste https://www.youtube.com/watch?v=BniAT8-mVC8 in the address bar and press Enter
4. Log into your YouTube account
5. Set the video to 4K or 1440p
6. Click on any timestamp of the video
7. Wait til the video reaches the end of the "gray buffer area"

Actual results:

1. Clicking on a timestamp in the video and waiting till the video reaches the end of the "gray buffer area" results in: infinite buffering, meaning the video shows the loading sign and won't load, regardless of how long you wait.
2. Another behavior is after clicking on a timestamp in the video and waiting till the video reaches the end of the "gray buffer area" results in: the video playing forward a couple of seconds/10 seconds, thus skipping chunks of the video.
3. Yet another behavior is after clicking on a timestamp in the video and waiting till the video reaches the end of the "gray buffer area" results in: the video shows compression artifacts for 1-2 seconds, then freezes for ca. 5 seconds simultaneously playing the sounds from the video in a stuttery way.

Expected results:

The video plays smoothly in 4K or 1440p regardless of which timestamp of the played video I click on.

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.

Andreas, would you mind attempting to reproduce this while capturing logs as shown in this demonstration video: https://paul.cx/public/about-logging-presentation.webm ? If you can then upload them (top right) and paste the link here, or send the profile privately, saved locally, to <[email protected]>, it would be great.

This behaves as expected for me, so I think we need more info. For starters, the video is continuously downloaded so I don't know how to reach the end of the buffered region. Maybe I should heavily throttle my connection speed to buffer? Is your internet slower than the 1440p or 4k bitrate? Does the youtube javascript not download the video segment for you or something?

Can you also share the raw data of about:support, to see if there's anything strange with your computer ? I think we can rule out any problem caused by an extension, since you've helpfully reproduced on a new profile.

(In reply to Paul Adenot (:padenot) from comment #2)

Andreas, would you mind attempting to reproduce this while capturing logs as shown in this demonstration video: https://paul.cx/public/about-logging-presentation.webm ? If you can then upload them (top right) and paste the link here, or send the profile privately, saved locally, to <[email protected]>, it would be great.

This behaves as expected for me, so I think we need more info. For starters, the video is continuously downloaded so I don't know how to reach the end of the buffered region. Maybe I should heavily throttle my connection speed to buffer? Is your internet slower than the 1440p or 4k bitrate? Does the youtube javascript not download the video segment for you or something?

Can you also share the raw data of about:support, to see if there's anything strange with your computer ? I think we can rule out any problem caused by an extension, since you've helpfully reproduced on a new profile.

Hello Paul, thank you for your response and provided support. I did the logging in a new profile and here is the permanent link to the logs:
https://share.firefox.dev/3SStdOY
The bug is "seen" in the whole last minute (I know that, because I set a timer) and it shows problem number 1 (from actual results) the "infinite buffering".
My internet connection should be enough for said resolutions, because I cannot replicate these problems neither in Microsoft Edge nor in Google Chrome (I was using the latter for over 10 years now and wanted to try something else). I sadly can't say anything about the javascript.
I will upload the raw data file under "Attachments" on this page.

I've been having this EXACT issue for the last couple of days. I've tried the video linked in the original report, and am experiencing the same results. I've been running into the same issue when trying to play certain YouTube videos. While other videos work fine, the ones where I do run into the issue I cannot get to play properly no matter what I do (I've tried closing and reopening Firefox, rebooting my computer, and Troubleshoot mode; the only "solution" that worked was dropping the quality to 1080p or lower).
The same videos play fine in Edge, so I don't think it's an issue with the internet connection.

Some info that might be relevant:

• I'm not using an adblocker with YouTube. I do use Enhancer, but I don't think it has an adblocker and since I'm paying for premium I don't think it should be an issue anyways.
• For me, the issue seems to happen repeatedly on videos uploaded to certain channels--one example being https://www.youtube.com/@TechnologyConnections

Thanks Andreas, that has all the information I need to see what's going on. In your profile, we can see that Youtube's javascript eventually stop making requests to fetch new media segments, and that Firefox runs out of media, and then the spinner is shown. I don't see a request that gets unanswered, or an error, the network request is simply not made. I'm not entirely sure why that would happen, and youtube clearly knows it doesn't have data because it shows its own spinner. Maybe a bug on Youtube's side. Nothing obvious in the support data as well, everything looks very standard. Is that recent, or maybe you did just start to use Firefox so it would be impossible for you to know. We know this generally works well (we would know otherwise, it's not like it's a small website), so this is quite confusing. Any particular channel this happens on, have you noticed a pattern?

korkev00, is that recent, you seem to say, "last couple of days" ? Can you link me to a particular video with you can reproduce on, if it seems video-specific? Do you mind capturing logs like I explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c2, alongside your about:support, like Andreas did in comment 3?

(In reply to Paul Adenot (:padenot) from comment #6)

Thanks Andreas, that has all the information I need to see what's going on. In your profile, we can see that Youtube's javascript eventually stop making requests to fetch new media segments, and that Firefox runs out of media, and then the spinner is shown. I don't see a request that gets unanswered, or an error, the network request is simply not made. I'm not entirely sure why that would happen, and youtube clearly knows it doesn't have data because it shows its own spinner. Maybe a bug on Youtube's side. Nothing obvious in the support data as well, everything looks very standard. Is that recent, or maybe you did just start to use Firefox so it would be impossible for you to know. We know this generally works well (we would know otherwise, it's not like it's a small website), so this is quite confusing. Any particular channel this happens on, have you noticed a pattern?

korkev00, is that recent, you seem to say, "last couple of days" ? Can you link me to a particular video with you can reproduce on, if it seems video-specific? Do you mind capturing logs like I explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c2, alongside your about:support, like Andreas did in comment 3?

Hello Paul, it took me a little longer to answer this time, because I started to actively use Firefox to watch YouTube to find out which channels are the problematic ones. You are right, I didn't use Firefox before, because I used Google Chrome for some 10 years. So, I don't know if that is recent behavior or not. I found the channels where the problems happen are those who offer 4K and 1440p videos, so nothing new to report. Channels like these, which I follow:
JayzTwoCents
Топлес
Techquickie

This is a relatively new issue (it's been around for a few months), but it affects years-old versions of the browser, so it's an issue that was introduced by youtube. Nevertheless, it doesn't seem to affect, Chromium, or at the very least it's not as frequent.

I can reproduce the issue pretty reliably with some videos, such as: https://www.youtube.com/watch?v=DxL2HoqLbyA
I switch to a resolution above 1080 as soon as the player loads, the video plays for a few seconds and then stops indefinitely.

Here is the captured log/profile: https://share.firefox.dev/3wvhEom and an attached video of what I see.

Extremely helpful both of you, thanks a lot for following up. I might have a better understanding of what's going on.

It might well be https://bugzilla.mozilla.org/show_bug.cgi?id=1882132, or it might be something else, but I'm investigating.

If folks that can routinely reproduce this bug could check with a Firefox Nightly build (https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly), and tell us if it still reproduces, it would be great. I fixed a bug recently that could be the cause of this.

I can still reproduce it on 20240228100509.

Ok good, thanks for verifying quickly, that one has the patch.

It's likely we'll contact YouTube directly on this one, your video + logs makes it clear that there's no media left in the buffer, the "waiting" event has been dispatched, and YouTube should be fetching new media segments, but that doesn't seem to happen.

I took a quick look on the profile provided in the comment 8, and found some weird points.

First, in this profile, only ONE seek was performed at 13.047s to the position 2327000, then I started observing what happened after that. I noticed some unusual calls for RemoveFrames in the MediaSupervisor threads. Usually, the frame removal would be done either by (1) website's decision via calling MSE API, or (2) remove old frames which we no longer need when appending new frames. However, those RemoveFrames calls were removing the frames we just appended, which seems suspicious.

Eg.
From 13.932s to 14.186s, we appended vp9 continuously from [2127000, 2189000] to [2753000, 2795000]. Then we appended a [0,0] frame in 14.198s, which also looks super suspicious. Also insert a [3462000, 3504000] at 14.367s. Then the frame removal was triggered immediately at 14.367s to remove [3.462000, 417000].

I'm guessing this issue would probably be caused by two possible reasons. (1) the video has incorrectly gap in between due to bad muxing, or (2) that [0,0] causes some unexpected frames removal, because that is unexpected to website, it would never know that they need to re-append those missing data.

Anyway, this issue does require more investigation. Leave NI on myself for a further investigation.

(In reply to Paul Adenot (:padenot) from comment #10)

If folks that can routinely reproduce this bug could check with a Firefox Nightly build (https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly), and tell us if it still reproduces, it would be great. I fixed a bug recently that could be the cause of this.

Just tried it on my original video and it's still happening.

This might also be happening with other, smaller, resolutions.
I'm not sure what changed, but interacting with the timeline leads very quickly to "stuck in throbber-mode" situations.

Setting media.prefer-non-ffvpx:true makes the playback fail differently. The video still skips ahead on its own, but when stuck, some times it recovers. Captured log/profile: https://share.firefox.dev/3Kz4GJT. (Note: if you're seeing any seeking in the profile, that's yt skipping ahead on its own; I didn't interact with the page after I changed the resolution.)

By the way, I'm under the impression that this affects only VP9 videos. YT seems to prefer VP9 in >1080p resolutions, which might explain the reports. I had definitely had this issue with lower resolutions, but it's less common.

Also, it seems that videos get stuck at the same exact points every time.

Indeed it happens in vp9 only. Issue starts from 1080p and gets more extreme (video is unwatchable) at 1440p & 2160p. Some video skip few seconds ahead since the start and some only after some minutes and scrolling the timeline will inevitably stuck loading or/and skip few seconds ahead and repeat the bug cycle. After reloading the page the video will still get stuck in the same spots in the timeline and by lowering the resolution to 720p the buffer bar have a strange behavior (loading a bit and emptying completely the buffer a few times in cycle until it recovers somehow and finally loads the whole bar).
The issue is present at all resolutions but somehow it is not messing up enough the buffer at 720p and lower to get stuck or skip.

https://www.reddit.com/r/firefox/comments/1dbxuqf/youtube_buffering_issue_since_4_months/
We are not alone.

I've also run into this issue increasingly often the last few months. Latest Nightly in safe mode still has the same issue. Some videos have it more often than others. One of the worst examples I've seen so far is https://www.youtube.com/watch?v=45CvTHmt_dI

A profile of the above video player in nightly https://share.firefox.dev/3VkXQwu
Playback stopped 24 seconds into the video. Then after about 10 seconds it continued. Buffer was properly full according to the playback bar

Please address this bug, Mozilla. It's a blocker for 2k/4k and sometimes even for 1080p videos on YT.

This problem has been haunting me for about a week now, it's impossible to watch most videos as they will stop after 10-15s and buffer for anywhere between 10 and 30 seconds - sometimes they come to a full stop without any progress.
Forwarding manually can resolve it for a hot minute, then it starts all over again.

I am having this issue at home AND at work with the newest FF version. First i thought this might be related to ublock, but after uninstalling it and deleting the default profile & creating a new one, nothing changed. The problem persists on 1440p and 1080p and even sometimes 720p. I can rule out that it is related to ping or bandwidth since I have 10Gbit/s wired fiber at work. In contrast, using Edge or Chrome - everything works flawlessly.

I'd kindly ask all the new users who come in following a link on Reddit to remind themselves of the rules everyone accepted when signing up, particularly:

No pointless comments. Limit comments on a bug to information which will help with resolving it. Unless requested, additional "I see this too" or "It works for me" comments are unnecessary. Constructive conversations unrelated to the topic of the bug should go in the appropriate discussion forum.

Unless you have something substantial to add that is not covered in this bug yet, do not comment "me too"s. Thank you.

I got a profiled result from an anonymous user for the same buffering issue. By debugging it, the problem seems caused by incorrect audio clock. In this profiled result, there are two main section where the playback should be started, the first one is around 22-29s and another one is after 50s.

Let's check the first section. That part loaded a Youtube video, and at 28.944s the MDSM started playback. At 29.065s, we already had 11 video frames in MDSM's video queue. However, the playback wasn't started properly, the video should be still stuck. When checking the audio clock, I found that the audio clock wasn't forward at all. We can observe same situation at 50.848s where user seems seeking video to another position, but the playback still stuck because the audio clock stuck as well.

Paul, Matthew, do you have any thought about that? I suspect that the one of the possible root causes of this problem is related with either cubeb or audio IPC. Thanks!

Interesting, https://share.firefox.dev/4bNUych shows that no callback are firing, this is on linux. There is a message to start a new stream, but then all the get_position calls return 0 (which is logical). I don't know right now why there is no callbacks firing at that moment.

Would you mind to follow this instruction to capture a profiled result again? This allows us to capture debug logs. Thanks!

(In reply to markus_austria from comment #23)

This problem has been haunting me for about a week now, it's impossible to watch most videos as they will stop after 10-15s and buffer for anywhere between 10 and 30 seconds - sometimes they come to a full stop without any progress.
Forwarding manually can resolve it for a hot minute, then it starts all over again.

I am having this issue at home AND at work with the newest FF version. First i thought this might be related to ublock, but after uninstalling it and deleting the default profile & creating a new one, nothing changed. The problem persists on 1440p and 1080p and even sometimes 720p. I can rule out that it is related to ping or bandwidth since I have 10Gbit/s wired fiber at work. In contrast, using Edge or Chrome - everything works flawlessly.

If this is a regression happening recently and can be reproduced easily, would you mind to use mozregression to see if you could find the culprit? Thanks!

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

Would you mind to follow this instruction to capture a profiled result again? This allows us to capture debug logs. Thanks!

I made these two logs from this video, which has a 50 percent chance of causing the bug.
https://www.youtube.com/watch?v=MLc2I1btGTI

without ublock (includes ad break)
https://share.firefox.dev/45ph8Fy

with ublock
https://share.firefox.dev/3VGxVky

Bug 1901630 shared this profile: https://share.firefox.dev/3Xh2oXh

Profiled results for this problem on clean new profile without any plugins.

https://share.firefox.dev/4b0De2s ; YT debug: https://i.imgur.com/0R6CINs.png

https://share.firefox.dev/3VCDeRU - audio skips at ~10s, then video freezes few seconds later. spinning wheel on player.

https://share.firefox.dev/3VBEHrz - video freezes at ~2s, audio plays in background, video is playing again at last seconds

Video: https://www.youtube.com/watch?v=y5EazNziymk (plays fine at start, freezes when skipping to some part of video)

Had this problem for months, mostly on live streams >1440p on VP9 (Sometimes they play correctly for 15 minutes and suddenly problem starts). Recently also on standard videos.

All videos work fine on forced h264 in FF (1080p limit) or VP9 on chromium based browsers.
Speedtest >800Mbps. Latest AMD GPU drivers(6700xt).

Paul, Matthew, there are more media profiles indicating the issue is caused by unstable audio clock.

Eg 1 (comment 29, with ublock)
At 28.192s, the last time video sink received a new frame, it still had 4 frames in the queue, and the queue constantly had 4 frames most of the time, which indicates that the decoding speed is stable. By checking MFR, we can know 23,232,000μs is the last video frame. In video sink, we can also observe that when video sink rendered the last frame, we still had 4 frames in the queue.

However, at 28.347s MDSM suddenly entered the buffering state due to OutOfDecodedVideo. That was very unreasonable, where were those 4 frames in the queue? So I checked the audio clock and noticed that audio clock grew incorrectly! At 28.347s audio clock was Getting position from the Audio Sink 23.270520, but at 28.348s it suddenly became Getting position from the Audio Sink 23.283500. It increased 0.01298s within 0.001s, which was 10 times larger than what it should grow. I think that made video sink to discard remaining 4 frames in the queue because they are already "LATE" to the audio clock.

Eg 2 (comment 29, without ublock)
You can observe same situation here. At 18.833s and 18.834s audio clock grew 0.018208s within 0.001s, which is also 10 times more than it should grow.

Eg 3 (comment 32, the second profile)
Same situaition here, at 12.194s and 12.199s, the audio clock grew 0.03715s within 0.005s.

There is quite a coincidence that gets me into posting here as well in case it helps analyzing the issue: Starting in january or february I observed as well videos on YouTube seeking several seconds into the future once they hit the end of the current shown buffer below the video. This issue occurs quite rarely here (around 1-5 times a month).

However, the issue appeared at the very exact day after I installed an update of the VP9 Video Extensions from the Microsoft store. Since YouTube was also testing major design changes around that time (permanent PBM with basically switching designs here and then after a restart) I was just assuming it was an issue on their normal design as well due to possible parallel changes since I doubted that an update to the VP9 Video Extensions could cause to alter the delivering logic of the video as I observed it back then. But now after it has been figured out that the audio clock acts suspicious I wonder if this could actually be a possible case (but maybe there are non-Windows users or Windows users without installed VP9 Video Extensions affected as well).

Can folks that can reproduce this try this build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JBJqruebTVybL4vFZaWAWA/runs/0/artifacts/public/build/target.zip ? Just unzip and run firefox.exe.

The bug is marked as tracked for firefox127 (release). However, the bug still isn't assigned.

:jimm, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

(In reply to Paul Adenot (:padenot) from comment #39)

Can folks that can reproduce this try this build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JBJqruebTVybL4vFZaWAWA/runs/0/artifacts/public/build/target.zip ? Just unzip and run firefox.exe.

It behaves the same way, I'm afraid. Here's a profile of this build playing a 4K 30 fps VP9 video, seeking the video still induces the buffering issue very quickly: https://share.firefox.dev/4cbbZmW

I had to change YouTube settings "Playback and performance" page's AV1 settings to "Prefer AV1 for SD" for the VP9 version of the video to be served, since that's the (only?) codec that seems to be affected by this bug on YouTube.

The video I used for testing was mentioned here before: https://www.youtube.com/watch?v=45CvTHmt_dI

(In reply to Paul Adenot (:padenot) from comment #39)

Can folks that can reproduce this try this build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JBJqruebTVybL4vFZaWAWA/runs/0/artifacts/public/build/target.zip ? Just unzip and run firefox.exe.

https://share.firefox.dev/4cl1TQp - video froze after resume from pause, audio is playing, video resumes after ~5-7 seconds

https://share.firefox.dev/3VqHVNe - video&audio skips frames in last few seconds of log

Live streams:
Stream freezes(audio+video) with spinning wheel after few seconds https://i.imgur.com/QmmnZcS.png
https://share.firefox.dev/3Vn7sqO - freeze in last few seconds of log

At the same time same stream plays fine in Edge https://i.imgur.com/hM2bSLI.png (this is my main problem for 3+ months; only on vp9, smooth when switched to h264; standard video problem is recent thing; )

(In reply to TexlGyTrail from comment #41)

(In reply to Paul Adenot (:padenot) from comment #39)

Can folks that can reproduce this try this build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JBJqruebTVybL4vFZaWAWA/runs/0/artifacts/public/build/target.zip ? Just unzip and run firefox.exe.

It behaves the same way, I'm afraid. Here's a profile of this build playing a 4K 30 fps VP9 video, seeking the video still induces the buffering issue very quickly: https://share.firefox.dev/4cbbZmW

Sorry, I only just read Comment 27's instructions for a media playback profile and created one for the same build, since it's more appropriate: https://share.firefox.dev/3Xj727m

This issue also affects linux users. The video I am using for testing is from an affected Linux Mint user. But he is not able to do some debugging, so I can only provide windows logs.

results from the "https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JBJqruebTVybL4vFZaWAWA/runs/0/artifacts/public/build/target.zip" build:
(still buffering)
without ublock
https://share.firefox.dev/3RwBfMr

with ublock
https://share.firefox.dev/3ViKilg

Could you try disable the pref media.hardware-video-decoding.enabled and then restart Firefox to see if this fixes the problem for VP9? As the problem is related with the audio clock causing all decoded video frames discarded unexpectedly, if this issue only happens on VP9 but not AV1, then it probably means VP9 is decoded by HW and AV1 is decoded by SW. For HW decoding, we won't queue too many video frames on Windows and Linux. So when using SW AV1, even if the video frames get discard unexpectedly, we might still have enough frames in the video queue. Thanks!

In addition, could anyone help me add a new pref media.video-queue.hw-accel-size and set its value to 10 to see if this fixes the problem? Thank you!

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

Could you try disable the pref media.hardware-video-decoding.enabled and then restart Firefox to see if this fixes the problem for VP9?

I could still reproduce the issue with hardware decoding disabled, but it may be occurring less frequently (not 100% sure):

https://share.firefox.dev/3xpd4bS - Firefox 127.0 VP9 with HW Decoding disabled

https://share.firefox.dev/4enEwaz - Test build from Comment 39 VP9 with HW Decoding disabled

if this issue only happens on VP9 but not AV1, then it probably means VP9 is decoded by HW and AV1 is decoded by SW.

My PC has a GPU with hardware AV1 decoding capability, but AV1 does not seem to have this problem at all, I could not reproduce this bug with either hardware or software decoded AV1. As a side note, I had to force AV1 through the "Always use AV1" setting in YouTube's playback and performance settings page, since seeking the video too aggressively with the "Auto" setting led to YouTube randomly falling back to VP9.

"media.hardware-video-decoding.enabled = false"

https://share.firefox.dev/4b8NRjQ

"media.video-queue.hw-accel-size = 10" (and media.hardware-video-decoding.enabled = true)

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

These two logs catch a another symptom of this bug that I have rarely observerved.
In these two cases, the video is re-buffered in an endless loop. This can also happen with a normal Firefox profile.
The result is a choppy video with many freezes.

Hi. I try firefox 115.12.0esr (64-bit), seams the same. The audio is working abut the video image is skipping frames.
If I go back with the mouse to seek before the freeze the image is getting freeze again, the frames are gone and is not trying to buffer them again.

https://share.firefox.dev/3VnuSMA - Video on #1897616

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

In addition, could anyone help me add a new pref media.video-queue.hw-accel-size and set its value to 10 to see if this fixes the problem? Thank you!

All tests on build from comment #39,

media.hardware-video-decoding.enabled - false

( it was harder to trigger this bug without HW decoding )

VP9 Live streams:

https://share.firefox.dev/3z3Qg23 https://i.imgur.com/l9a44RM.png - plays fine 1080p, switching to 1440p, freezes after ~5s
https://share.firefox.dev/3XnylgU https://i.imgur.com/2bzBySq.png - freezes shortly after clicking play(choppy ~20ms/1s audio bursts), dropped frames +1000/s in YT debug

media.hardware-video-decoding.enabled - false media.video-queue.hw-accel-size - 10

VP9 Live streams:
https://i.imgur.com/GpHJ2UQ.png https://i.imgur.com/GpHJ2UQ.png - freezes shortly after clicking play(choppy ~20ms/1s audio bursts),

VP9 Standard video:

https://share.firefox.dev/4c39XFU https://i.imgur.com/cbm7FLp.png video&audio skips forward 1/3s at the end of log.

https://share.firefox.dev/4c39XFU - video runs off buffer health, spinning wheel. Never resumes, fast forward needed. (fine for 10-20s and same issue)

https://share.firefox.dev/4eh6eGd https://i.imgur.com/LPlXDZ9.png - spinning wheel, but with buffer at 11s health.

media.hardware-video-decoding.enabled - true media.video-queue.hw-accel-size - 10

VP9 Live streams:

https://share.firefox.dev/4b2mPe6 https://i.imgur.com/gQj8ACU.png - spinning wheel after ~50s of playback & video in buffer

VP9 Standard video:
https://share.firefox.dev/4c02g31 https://i.imgur.com/4FrEOsk.png - freezes, spinning wheel with healthy buffer;

Thanks! I can confirm that the profiles about buffering from comment 47, comment 48 and comment 50 are still caused by the same issue, the unstable audio clock. The audio clock still grew too fast even if we had more video frames in the queue.

But the comment 49 and frozen video from comment 50 are another issue, which is caused by the decoding is not fast enough so Firefox froze the video and kept audio playing. That is something could possibly be fixed by bug 1893427. Currently on Windows, Firefox uses Media Foundation for the hardware decoding, but we've received many reports claiming that the VP9 hardware decoding performance is bad. Therefore, we're planing to use ffmpeg decoder to utilize DXVA API directly in order to have better performance.

Same thing here at the end: https://share.firefox.dev/4ejIeC9
Video : Freeze / Audio: OK

Video ID / sCPN - y5EazNziymk / YVTY FJW6 4TAD BE9H H6A0
Viewport / Frames - 1264x711 / 163 dropped of 2221
Current / Optimal Res - 1920x1080@24 / 1920x1080@24
Codecs - vp09.00.51.08.01.01.01.01.00 (248) / opus (251)
Color - bt709 / bt709
Connection Speed - 76258 Kbps
Network Activity - 0 KB
Buffer Health - 22.43 s
Mystery Text - SABR, s:4 t:446.79 b:0.000-87.588,412.913-469.220 P pbs:1530

Now I get more Image Freeze but the audio working. One time I the to buffer but I was not logging it.

I can replicate one of these issues with 100% consistency (sometimes video freezes audio continues, sometimes video jumps then freezes a few seconds later, sometimes just jumps, sometimes just stops loading completely and buffers) on many but not all VP9 2K/4K videos. If it happens on a video it will always happen, if it doesnt happen on the video then it will never happen on that video. It never happens on grvBNip77tY but always happens on oUZttxRcPZw (and seemingly many but not all newly uploaded (not AV1 yet) music videos). The issue does not happen with AV1, however as mentioned in comment 45 it seems AV1 is being SW decoded on my system despite having a RTX 3080. It also happens identically in the build shared in comment 39. (sorry, can't work out how to hyperlink comments)

Setting the video to 1440p then back to 4K and manually scrubbing to the beginning of the video sometimes fixes the issue and allows the full video to play correctly, in the case of the video I shared I cant seem to make it work regardless of what I try.

Something I've noticed is that when I play the problematic video in Edge it will buffer smoothly for the first few seconds (exactly the same amount as firefox does before it appears to stop), and then edge will pause for a second and jump a little before buffering again, but slightly stuttery buffering. This all happens while the video is playing smoothly within the initially smoothly buffered section.

Setting media.wmf.dxva.d3d11.enabled = false makes the issues persist into the rest of the video, when set to true it generally only effects the start and the video jumps, where I usually get video freezing with audio continuing with it set to false - however in the same place as the jump occurs.

Log with buffering stopping ~7s into video, followed by jump followed by freeze 24s into the video (I click just after the freeze occurs and it keeps playing, buffer bar is filled until 44s, clicking shortly before the part it stalls causes it to stall in the same place again. Returning to the start of the video will cause it to stall in other earlier places, in the case of this video it stalls at 2s if you tell it to play from 0s after the jump has happened): https://share.firefox.dev/3Vhjt0E

Can't edit but added context, a few attempts later I got a jump where it freezes around 24s into the video in the log I linked, making me think the two are directly linked if it wasnt clear already.

Here has freeze completely, Video and Audio and straight to Buffer: https://share.firefox.dev/3VHIQdx
Not sure what happened to FF, this was not happened before and I use it from ages.
Has YouTube break something?

I can get the 2 Behavior (Video Stuck, Audio OK / Stuck Completely).
Can reproduce with https://www.youtube.com/watch?v=y5EazNziymk, not every time (Randomly seams to me).
On two systems.

1. WIndows 10 22H2
   Intel i5-4440 with Intel HD 4600

2. Windows 10 21H2
   Intel i5 9600KF with Intel HD 1060 6GB

(In reply to Marian from comment #55)

Here has freeze completely, Video and Audio and straight to Buffer: https://share.firefox.dev/3VHIQdx
Not sure what happened to FF, this was not happened before and I use it from ages.
Has YouTube break something?

I can get the 2 Behavior (Video Stuck, Audio OK / Stuck Completely).
Can reproduce with https://www.youtube.com/watch?v=y5EazNziymk, not every time (Randomly seams to me).
On two systems.

1. WIndows 10 22H2
   Intel i5-4440 with Intel HD 4600

2. Windows 10 21H2
   Intel i5 9600KF with Intel HD 1060 6GB

Also not in 4K, just in 1080p quality like my above post

(In reply to Marian from comment #55)

Not sure what happened to FF, this was not happened before and I use it from ages.
Has YouTube break something?

I have been experiencing this exact issue consistently for many months, its not a new issue. I hoped it would be fixed but it seems not, it does seem to have gotten worse in the past short while, perhaps youtube is pushing more vp9 content.

It never happens on this VP9 video: XCv4Y_JGqJE
It always happens on this video without "always prefer AV1" enabled in youtube settings: nFYwcndNuOY

That one behaves strangely, it buffers the first 10s, then video freezes for about 0.3s when it gets to it and the buffer skips immediately to 19s, when it reaches 19s it seems to have a serious decoding issue with colourful macroblocks, and then jumps from 19s to 22s and completely stalls and I get a spinning wheel at 22s with buffer showing filled to 28s. After a long while it continues but stalls a few seconds later. Full log: https://share.firefox.dev/3VnEuqE

Unfortunately the log is too large to upload with hidden threads enabled, this is all I can provide.

I am using a 12700K and RTX 3080, surely computing power is not at fault here.

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

Could you try disable the pref media.hardware-video-decoding.enabled and then restart Firefox to see if this fixes the problem for VP9?

I almost feared it and indeed due to the rarity the seeking into the future issue is happening here I was not able to reproduce it with unaltered settings so I can't tell if enabling/disabling hardware acceleration would make a difference.

Interestingly, using yt-dlp to download and play this affected 4K 30 fps VP9 video locally (with Ctrl+O) does not show any playback issues whatsoever when seeking the video aggressively. I have no idea what that could mean, but I recorded a profile anyway, in case it helps:

https://share.firefox.dev/4cmH9b6 - downloaded YT VP9 video with HW Decoding enabled, no playback issues

Please ignore this comment if this was already known.

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

Could you try disable the pref media.hardware-video-decoding.enabled and then restart Firefox to see if this fixes the problem for VP9? As the problem is related with the audio clock causing all decoded video frames discarded unexpectedly, if this issue only happens on VP9 but not AV1, then it probably means VP9 is decoded by HW and AV1 is decoded by SW. For HW decoding, we won't queue too many video frames on Windows and Linux. So when using SW AV1, even if the video frames get discard unexpectedly, we might still have enough frames in the video queue. Thanks!

I can confirm almost exactly the same behaviour with SW VP9 decoding; initial buffering stops at the same place (~9-10s), video freezes or jumps at the same place (11s), and then freezes again at 24s. https://share.firefox.dev/3XmC1zm

Again, 100% consistency on affected videos for me.

Some users have just reported on Reddit that disabling HTTP3 by setting network.http.http3.enable to false seems to improve the situation for them.

(In reply to Thomas Wisniewski [:twisniewski] from comment #61)

Some users have just reported on Reddit that disabling HTTP3 by setting network.http.http3.enable to false seems to improve the situation for them.

I personally see exactly the same behaviour at the start of the video in the version of nightly posted earlier in this thread with a fresh profile and network.http.http3.enable = false: https://share.firefox.dev/3XmUZ92 (the video starts playing in 1080p before I manually switch to 4K)

I ran mozregression (on Linux) two times and ended up with the same result. However, in order to get youtube running at all in those old versions, I had to disable the content process sandbox, the rdd process and edit the user agent string to a newer version. This is the result: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e842238034cd847ede178b4e65ea07704e4ffe6&tochange=5836a60614764631436bf5030c5baa34c676c7a2

Can anyone else who can reproduce this try playing an affected video in YouTube's "embed" player? For me, the buffering issue is a lot rarer when doing this, but I could still get it to happen eventually.

To play a video in YT's embedded player: Click the "Share" button below the video → Click "Embed" → Play the video that loads up.

(In reply to TexlGyTrail from comment #64)

Can anyone else who can reproduce this try playing an affected video in YouTube's "embed" player? For me, the buffering issue is a lot rarer when doing this, but I could still get it to happen eventually.

To play a video in YT's embedded player: Click the "Share" button below the video → Click "Embed" → Play the video that loads up.

Uh... It plays flawlessly in the small embedded player at 4K for me. I can't replicate the bug in that player, it appears to be buffering completely normally - it even still has the start of the video buffered for me when I go back to it which is nice. Here's a log of a flawless run, perhaps useful in comparison to my other bugged examples (which still exhibit the same behaviour): https://share.firefox.dev/45uCYrA

(In reply to pkmnmina from comment #65)

(In reply to TexlGyTrail from comment #64)

Can anyone else who can reproduce this try playing an affected video in YouTube's "embed" player? For me, the buffering issue is a lot rarer when doing this, but I could still get it to happen eventually.

To play a video in YT's embedded player: Click the "Share" button below the video → Click "Embed" → Play the video that loads up.

Uh... It plays flawlessly in the small embedded player at 4K for me. I can't replicate the bug in that player, it appears to be buffering completely normally - it even still has the start of the video buffered for me when I go back to it which is nice. Here's a log of a flawless run, perhaps useful in comparison to my other bugged examples (which still exhibit the same behaviour): https://share.firefox.dev/45uCYrA

I could only get it to happen after seeking the video very violently, something a regular user watching a video would never do. Either way, the difference is certainly night and day compared to the normal YouTube player. Hopefully this helps get closer to a solution.

(In reply to TexlGyTrail from comment #66)

(In reply to pkmnmina from comment #65)

(In reply to TexlGyTrail from comment #64)

Can anyone else who can reproduce this try playing an affected video in YouTube's "embed" player? For me, the buffering issue is a lot rarer when doing this, but I could still get it to happen eventually.

To play a video in YT's embedded player: Click the "Share" button below the video → Click "Embed" → Play the video that loads up.

Uh... It plays flawlessly in the small embedded player at 4K for me. I can't replicate the bug in that player, it appears to be buffering completely normally - it even still has the start of the video buffered for me when I go back to it which is nice. Here's a log of a flawless run, perhaps useful in comparison to my other bugged examples (which still exhibit the same behaviour): https://share.firefox.dev/45uCYrA

I could only get it to happen after seeking the video very violently, something a regular user watching a video would never do. Either way, the difference is certainly night and day compared to the normal YouTube player. Hopefully this helps get closer to a solution.

Even Edge and Chrome get confused when I try really really hard, so I don't think thats somewhat unrelated. Played aboout with it some more and it seems that every problematic video works fine in the embedded player, its still playing the same VP9 video stream too, I thought perhaps it was using a "hidden" AV1 stream but it seems not. Really strange that it works. Very nice find, though!

FWIW I also tried hosting a downloaded VP9 webm of the problematic video on a local server and viewing it through a regular html5 video tag and it played properly, but that probably isnt relevant.

(In reply to tgn-ff from comment #63)

I ran mozregression (on Linux) two times and ended up with the same result. However, in order to get youtube running at all in those old versions, I had to disable the content process sandbox, the rdd process and edit the user agent string to a newer version. This is the result: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e842238034cd847ede178b4e65ea07704e4ffe6&tochange=5836a60614764631436bf5030c5baa34c676c7a2

Thanks! bug 1497951, https://hg.mozilla.org/mozilla-central/rev/80643ce074f6, and bug 1494073 are in that range.

By the way, it’s very similar to my case! 😲

Videos on YouTube do not play normally if the ad blocker is turned off (uBlock Origin)

Maybe Google decided to lure Firefox users to itself in such a cunning way, actually forcing them to use Chrome? 🤔 LOL!!! 😅

Here is a video that freezes for me (infinite buffering) starting from the 5th second: https://www.youtube.com/watch?v=rIYBi97ZKF8

Screenshot: https://i.imgur.com/Nsy814Q.png

And this is after formatting the SSD drive and a clean installation of the operating system (I have macOS Sonoma 14.5 (23F79) installed on a Mac mini on an M1 chip). Firefox, of course, was also installed from scratch.

For me, this issue seems to occur most commonly when watching videos in 4k or 1440p. I've had it occur on both Windows and Linux (using nvidia-vaapi-driver for hardware acceleration).

It can manifest in any of the following ways:

• The video freezes for a few seconds, and will freeze consistently in the same place when seeking back, even if I seek into the middle of the frozen portion of the video.
• The playback position instantaneously jumps forward by a few seconds. This seems to often be accompanied by the buffered portion of the timeline flickering between what seems to be the correct buffer duration and a longer or shorter duration while it plays back. (Edit: It can sometimes jump multiple times in quick succession, and as comment 73 mentions, when the first jump happens, my volume will change presumably to 100%)
• Most rarely, the video will just get stuck buffering permanently.

It's worth noting that I have the MSE video buffer size set to 150MiB, per Bug 1760529. This may help to prevent that permanent buffering issue from occurring, but I'm unsure if that's the case.

I only started having these issues pretty recently, but by running mozregression on Windows, I've confirmed that I have issues in builds from as far back as July of last year. I wonder if something could have changed on YouTube's side to cause these issues to appear so suddenly?

And it also happens to me that the volume on YouTube, because of this bug, suddenly increases to some prohibitive level 😱 🫨 📢 I’m even afraid that because of this, the speaker(s) of my favorite expensive in-ear headphones will burn out 🫣

(In reply to Zaggy1024 from comment #72)

For me, this issue seems to occur most commonly when watching videos in 4k or 1440p. I've had it occur on both Windows and Linux (using nvidia-vaapi-driver for hardware acceleration).

It can manifest in any of the following ways:

• The video freezes for a few seconds, and will freeze consistently in the same place when seeking back, even if I seek into the middle of the frozen portion of the video.
• The playback position instantaneously jumps forward by a few seconds. This seems to often be accompanied by the buffered portion of the timeline flickering between what seems to be the correct buffer duration and a longer or shorter duration while it plays back. (Edit: It can sometimes jump multiple times in quick succession, and as comment 73 mentions, when the first jump happens, my volume will change presumably to 100%)

Can you check whether you are able to reproduce the issue in the embedded player as per comment 64 ? I've never experienced the volume jump but the other problems seem consistent with what I am experiencing. If you can upload a log ( comment 27 ) it may be a helpful datapoint for people who know what to look for, since the people having this bug seem to have it manifest in subtly different ways.

Perhaps someone with more brainpower than I can write a tampermonkey script to replace the player on vp9 videos with the embedded one if it appears to be a consistent workaround as a temp fix, but thats probably a discussion for somewhere else.

I'm also having this issue occur but now it's despite the resolution that I have the video set to. I'll click a video, and it will end up buffering for 1 to 3 minutes at the start of the video before finally loading, playing 3 seconds, and then buffering against for a couple minutes at a time. And no matter what modification I make, what extension I use, or not use any extension, it won't work.

The video I attempted is this: https://www.youtube.com/watch?v=_uDtDX-Hrzg

The log file is attached.

The about:support data is attached.

I'm on firefox V127

https://share.firefox.dev/45trxAd
Started logging with MediaSource:5 and https://www.youtube.com/watch?v=rIYBi97ZKF8 @ 1440p paused about half way through. Then seeked back to the beginning and played. There may have been a brief hiccup in the video at the beginning, but the video froze for several seconds soon after 26s (perhaps 28s) into the video. Some decode steps are taking 5 seconds:

12.423
LogMessages — (MediaDecoder) MediaDecoderStateMachine[7f6f997cc200] Decoder=7f6f58ff1700 MaybeStartPlayback() starting playback

21.294
LogMessages — (MediaSource) MediaSourceDecoder[7f6f58ff1700] ::GetBuffered: ranges=[(0.000000, 10.745000), (17.584000, 28.029000), (34.034000, 91.092000)]

22.490
LogMessages — (MediaSource) TrackBuffersManager[7f6f598e8600] ::InsertFrames: Inserted video/vp9 frame:[(28.028000, 33.067000)], buffered-range:[(0.000000, 4.704000), (4.705000, 5.538000), (5.539000, 5.972000), (5.973000, 7.540000), (7.541000, 7.707000), (7.708000, 9.976000), (9.977000, 11.177000), (11.178000, 11.978000), (11.979000, 12.245000), (12.246000, 15.081000), (15.082000, 15.982000), (15.983000, 18.017000), (18.018000, 18.451000), (18.452000, 18.651000), (18.652000, 18.818000), (18.819000, 20.653000), (20.654000, 23.022000), (23.023000, 33.067000), (34.034000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 60.760000), (60.761000, 91.092000)], mHighestEndTimestamp={33067000,1000000}

22.505
LogMessages — (MediaSource) TrackBuffersManager[7f6f598e8600] ::InsertFrames: Inserted video/vp9 frame:[(28.061000, 28.461000)], buffered-range:[(0.000000, 4.704000), (4.705000, 5.538000), (5.539000, 5.972000), (5.973000, 7.540000), (7.541000, 7.707000), (7.708000, 9.976000), (9.977000, 11.177000), (11.178000, 11.978000), (11.979000, 12.245000), (12.246000, 15.081000), (15.082000, 15.982000), (15.983000, 18.017000), (18.018000, 18.451000), (18.452000, 18.651000), (18.652000, 18.818000), (18.819000, 20.653000), (20.654000, 23.022000), (23.023000, 33.067000), (34.034000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 60.760000), (60.761000, 91.092000)], mHighestEndTimestamp={33067000,1000000}
LogMessages — (MediaSource) MediaSourceDecoder[7f6f58ff1700] ::GetBuffered: ranges=[(0.000000, 91.092000)]

39.587 0.133s
DecodeFrame FFmpegVideoDecoder(61) 2560x1440 sw,vp9,yuv420p,depth=8,range=Limited,space=BT.709, MSEDecoder-290301-1
Sample start time:
28,395,000μs
Sample end time:
28,428,000μs

39.720 5.210s
RequestDecode:V:1080<h<=1440:sw,vp9,
Sample start time:
28,395,000μs
Sample end time:
28,428,000μs

39.720 5.210s
DecodeFrame FFmpegVideoDecoder(61) 2560x1440 sw,vp9,yuv420p,depth=8,range=Limited,space=BT.709, MSEDecoder-290301-1
Sample start time:
28,562,000μs
Sample end time:
28,595,000μs

https://share.firefox.dev/4ciDqeo includes MediaSource:5,FFmpegVideo:5.
https://www.youtube.com/watch?v=rIYBi97ZKF8 @ 1440p again, but the symptoms are different.
Started logging from about 7 seconds before starting playback from the beginning.
Video freezes about 19-20 s into the video, and does not resume.
Audio keeps playing.

At 15.968, GetBuffered() becomes more pedantic about reporting small gaps, despite no such corresponding changes in what is buffered.

At 26.746 the next sample to be played is discovered evicted, in response to earlier ranges being replaced with somewhat different ranges.

7.628
LogMessages — (MediaDecoder) MediaDecoderStateMachine[7f09881b3600] Decoder=7f0984639f00 MaybeStartPlayback() starting playback

14.213
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Processing 1 video/vp9 frames(start:0 end:0)
InsertFrames - Processing 1 video/vp9 frames(start:0 end:0)
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Inserted video/vp9 frame:[               ], buffered-range:[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.029000)], mHighestEndTimestamp={34034000,1000000}

15.952
LogMessages — (MediaSource) MediaSourceDecoder[7f0984639f00] ::GetBuffered: ranges=[(0.000000, 28.029000)]
15.966
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::EvictData: currentTime=8008062 buffered=28392kB, eviction threshold=102400kB, evict=-73751kB canevict=3150kB
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Processing 6 video/vp9 frames(start:28028000 end:28229000)
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: partial overwrite of frame [27995000,28029000] with [28028000,28229000] trim to [27995000,28028000]
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: overridding start of frame [28028000,28028000] with [28028000,28229000] dropping
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing frames from:840 for video/vp9 (frames:1) ([0.000000, 0.000000))
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing [] from bufferedRange [(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.029000)]
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Inserted video/vp9 frame:[(28.028000, 28.229000)], buffered-range:[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.229000)], mHighestEndTimestamp={28229000,1000000}
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::NeedMoreData: 

15.968
LogMessages — (MediaSource) MediaSourceDecoder[7f0984639f00] ::GetBuffered: ranges=[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.229000)]

25.590
LogMessages — (MediaSource) MediaSourceDecoder[7f0984639f00] ::GetBuffered: ranges=[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 33.633000), (33.634000, 50.001000)]

25.594
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::ProcessFrames: Discontinuity detected.
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Processing 5 video/vp9 frames(start:10744000 end:10910000)

25.595
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: overridding start of frame [10744000,10777000] with [10744000,10910000] dropping
...
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: overridding start of frame [10877000,10910000] with [10744000,10910000] dropping
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing frames from:322 for video/vp9 (frames:205) ([10.744000, 17.584000))
RemoveFrames - Removing frames from:322 for video/vp9 (frames:205) ([10.744000, 17.584000))
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing [(10.744000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.584000)] from bufferedRange [(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 33.633000), (33.634000, 34.467000), (34.468000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 37.270000), (37.271000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.206000), (40.207000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 43.276000), (43.277000, 50.016000), (50.017000, 52.053000)]

26.540 0.208s
DecodeFrame FFmpegVideoDecoder(61) 2560x1440 sw,vp9,yuv420p,depth=8,range=Limited,space=BT.709, MSEDecoder-347056-0
Sample start time:
19,319,000μs
Sample end time:
19,352,000μs
LogMessages — (FFmpegVideo) FFVPX: Got one frame output with pts=18952000 dts=18952000 duration=33000

26.572 0.201s
DecodeFrame FFmpegVideoDecoder(61) 2560x1440 sw,vp9,yuv420p,depth=8,range=Limited,space=BT.709, MSEDecoder-347056-0
Sample start time:
0.000μs
Sample end time:
0.000μs
LogMessages — (FFmpegVideo) FFVPX: Got one frame output with pts=18985000 dts=18985000 duration=33000

26.315
LogMessages — (MediaSource) dom::SourceBuffer[7f0984624f40] (video/webm; codecs="vp09.00.51.08.01.01.01.01.00")::GetBuffered: intersection=[(0.000000, 14.447000), (17.584000, 52.053000)]
LogMessages — (MediaSource) dom::SourceBuffer[7f0984624f40] (video/webm; codecs="vp09.00.51.08.01.01.01.01.00")::GetBuffered: currentValue=[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.177000), (11.178000, 11.244000), (11.245000, 11.344000), (11.345000, 11.444000), (11.445000, 11.978000), (11.979000, 12.178000), (12.179000, 12.545000), (12.546000, 12.612000), (12.613000, 12.812000), (12.813000, 12.912000), (12.913000, 13.079000), (13.080000, 13.179000), (13.180000, 13.446000), (13.447000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.247000), (14.248000, 14.447000), (14.448000, 14.714000), (14.715000, 14.814000), (14.815000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 17.450000), (17.451000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 50.016000)]

26.744
LogMessages — (MediaSource) MediaSourceDecoder[7f0984639f00] ::GetBuffered: ranges=[(0.000000, 17.250000), (17.584000, 50.001000)]
26.746
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Processing 10 video/vp9 frames(start:17251000 end:17585000)
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: overridding start of frame [17584000,17617000] with [17251000,17585000] dropping
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing frames from:517 for video/vp9 (frames:163) ([17.584000, 23.022000))
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Next sample to be played got evicted

26.747 0.26s
DecodeFrame FFmpegVideoDecoder(61) 2560x1440 sw,vp9,yuv420p,depth=8,range=Limited,space=BT.709, MSEDecoder-347056-0
Sample start time:
0.000μs
Sample end time:
0.000μs
LogMessages — (FFmpegVideo) FFVPX: Got one frame output with pts=19152000 dts=19152000 duration=34000

26.749
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: Removing [(17.584000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000)] from bufferedRange [(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.244000), (11.245000, 11.344000), (11.345000, 11.611000), (11.612000, 11.711000), (11.712000, 11.811000), (11.812000, 11.978000), (11.979000, 12.178000), (12.179000, 12.245000), (12.246000, 12.445000), (12.446000, 12.545000), (12.546000, 12.912000), (12.913000, 12.979000), (12.980000, 13.179000), (13.180000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.447000), (14.448000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 15.615000), (15.616000, 16.449000), (16.450000, 16.983000), (16.984000, 17.083000), (17.084000, 17.183000), (17.184000, 17.250000), (17.584000, 17.650000), (17.651000, 18.017000), (18.018000, 18.184000), (18.185000, 18.551000), (18.552000, 18.651000), (18.652000, 18.818000), (18.819000, 19.018000), (19.019000, 19.452000), (19.453000, 20.086000), (20.087000, 20.386000), (20.387000, 21.020000), (21.021000, 21.187000), (21.188000, 21.654000), (21.655000, 23.022000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 33.633000), (33.634000, 34.467000), (34.468000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 37.270000), (37.271000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.206000), (40.207000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 43.276000), (43.277000, 50.016000), (50.017000, 52.053000)]
26.750
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::RemoveFrames: After removing frames, video/vp9 data sz=1387, highestStartTimestamp= 52019000, bufferedRange=[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.244000), (11.245000, 11.344000), (11.345000, 11.611000), (11.612000, 11.711000), (11.712000, 11.811000), (11.812000, 11.978000), (11.979000, 12.178000), (12.179000, 12.245000), (12.246000, 12.445000), (12.446000, 12.545000), (12.546000, 12.912000), (12.913000, 12.979000), (12.980000, 13.179000), (13.180000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.447000), (14.448000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 15.615000), (15.616000, 16.449000), (16.450000, 16.983000), (16.984000, 17.083000), (17.084000, 17.183000), (17.184000, 17.250000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 33.633000), (33.634000, 34.467000), (34.468000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 37.270000), (37.271000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.206000), (40.207000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 43.276000), (43.277000, 50.016000), (50.017000, 52.053000)], sanitizedBufferedRanges=[(0.000000, 17.250000), (23.023000, 52.053000)]
LogMessages — (MediaSource) TrackBuffersManager[7f098b36be00] ::InsertFrames: Inserted video/vp9 frame:[(17.251000, 17.585000)], buffered-range:[(0.000000, 5.538000), (5.539000, 9.175000), (9.176000, 9.342000), (9.343000, 9.976000), (9.977000, 10.076000), (10.077000, 10.176000), (10.177000, 10.243000), (10.244000, 10.610000), (10.611000, 10.910000), (10.911000, 10.977000), (10.978000, 11.077000), (11.078000, 11.244000), (11.245000, 11.344000), (11.345000, 11.611000), (11.612000, 11.711000), (11.712000, 11.811000), (11.812000, 11.978000), (11.979000, 12.178000), (12.179000, 12.245000), (12.246000, 12.445000), (12.446000, 12.545000), (12.546000, 12.912000), (12.913000, 12.979000), (12.980000, 13.179000), (13.180000, 13.613000), (13.614000, 13.913000), (13.914000, 13.980000), (13.981000, 14.080000), (14.081000, 14.180000), (14.181000, 14.447000), (14.448000, 15.081000), (15.082000, 15.181000), (15.182000, 15.448000), (15.449000, 15.615000), (15.616000, 16.449000), (16.450000, 16.983000), (16.984000, 17.083000), (17.084000, 17.183000), (17.184000, 17.250000), (17.251000, 17.585000), (23.023000, 24.190000), (24.191000, 24.257000), (24.258000, 24.724000), (24.725000, 24.824000), (24.825000, 24.891000), (24.892000, 24.991000), (24.992000, 25.191000), (25.192000, 25.625000), (25.626000, 25.725000), (25.726000, 25.825000), (25.826000, 25.992000), (25.993000, 26.359000), (26.360000, 26.459000), (26.460000, 26.826000), (26.827000, 27.460000), (27.461000, 28.628000), (28.629000, 29.262000), (29.263000, 29.362000), (29.363000, 29.729000), (29.730000, 30.196000), (30.197000, 30.997000), (30.998000, 33.099000), (33.100000, 33.633000), (33.634000, 34.467000), (34.468000, 35.268000), (35.269000, 35.735000), (35.736000, 36.202000), (36.203000, 36.736000), (36.737000, 37.270000), (37.271000, 38.104000), (38.105000, 38.538000), (38.539000, 38.638000), (38.639000, 39.205000), (39.206000, 40.206000), (40.207000, 40.640000), (40.641000, 41.474000), (41.475000, 41.741000), (41.742000, 43.276000), (43.277000, 50.016000), (50.017000, 52.053000)], mHighestEndTimestamp={17585000,1000000}

26.752
LogMessages — (MediaSource) MediaSourceDecoder[7f0984639f00] ::GetBuffered: ranges=[(0.000000, 17.585000), (23.023000, 50.001000)]

26.773
LogMessages — (FFmpegVideo) FFVPX: FFmpegDataDecoder: draining buffers
LogMessages — (FFmpegVideo) FFVPX: Got one frame output with pts=19186000 dts=19186000 duration=34000
...
LogMessages — (FFmpegVideo) FFVPX: Got one frame output with pts=19319000 dts=19319000 duration=33000
LogMessages — (FFmpegVideo) FFVPX:   End of stream.

By the way, I noticed this problem on YouTube in Firefox last year, but then it was not so pronounced, plus somehow its occurrence was minimized by the uBlock Origin extension. But now nothing helps, and this problem now occurs in Firefox all the time!

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

Update some finding, I haven't found the real root cause yet, but the problem seems related with MSE buffered data, it's still unclear whether the problem is on Youtube's side (serving bad muxed VP9) or Firefox's side.

There are two different problems, (1) video enters buffering unexpectedly (2) video isn't recovered from buffering

(1) is caused by the unstable audio clock, which I've explained in the comment 33.

(2) is the real problem we need to handle. In normal situation, Firefox should get enough data from the buffering state, and resume the playback quickly. But when the issue happens, Firefox is not able to recover from the buffering state, because Firefox doesn't get the data. I will use one profile I captured on my Nightly as an example.

First, we found some weird parts for Youtube's VP9 stream, such as Invalid ID element size (the maximum should be 4 per spec), incorrect timestamp (many discontinuity, overlapped frames, duplicated frames). But I still need to investigate if those behaviors are allowed by the spec.

Then when the problem happens, it usually happens when Youtube starts serving overlapped frames + duplicated frames. Eg. at 60.771s there are two duplicated frames, [519269000, 519311000], and they also overlapped with the previous frame [519144000, 519186000]. When we received the second duplicated frame [519269000, 519311000], it also caused recreating the demuxer.

Here is the problem, we didn't store any demuxed frame into our buffered range since then, we can see here and found out that we only had the range (519.144000, 519.270000) even if those data did exist in the appended data. In addition, when we processed frames, there was a huge gap between 60.816s and 62.439s. The data between 519311000 and 525525000 somehow disappeared!

What I am guessing is that, we would fail to get next data due to that big gap. So the media format reader would never get the next data, and we don't trigger any decoding as well.

But it's still unclear to me, (1) why those demuxed data weren't added to the buffered range? (2) what is the expected behavior when dealing with bad muxed data. In addition,there might be not only situation causing this bug, I also encountered another situation different from above on my own build m-c. I will keep investigating this and update more information later.

Matthew, as you're familiar with webm dexmuer, I wonder if you could see any unusual thing in my profiled result (it contains MediaDemuxer:5,MediaSourceSamples:5)? or if you can try to reproduce on your side, on Windows it's fairly easy to reproduce that. I use this video in 4K, and try to play it for a while, or randomly perform seeking. Sometime the issue can be reproduced quickly, but sometime I need to seek many times (usually < 10). Thanks!

okay I have found the root cause of this problem, and this build [1] fixed the issue for me on Windows 11. If anyone has free time, please free feel to help me verify whether this build works for you as well. I will post another comment to explain the problem tomorrow.

[1] unzip it, and run firefox.exe:
Windows : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bFTUsHxIRyyVG45aI3c8Ig/runs/0/artifacts/public/build/target.zip
Linux : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ry3snO0YTsO8GOFPZ3DH_g/runs/0/artifacts/public/build/target.tar.bz2
MacOS : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/IUGl-OAPTdCAo1fNWIm2YA/runs/0/artifacts/public/build/target.dmg

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

okay I have found the root cause of this problem, and this build [1] fixed the issue for me on Windows 11. If anyone has free time, please free feel to help me verify whether this build works for you as well. I will post another comment to explain the problem tomorrow.

[1] unzip it, and run firefox.exe:
Windows : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bFTUsHxIRyyVG45aI3c8Ig/runs/0/artifacts/public/build/target.zip
Linux : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Ry3snO0YTsO8GOFPZ3DH_g/runs/0/artifacts/public/build/target.tar.bz2
MacOS : https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/IUGl-OAPTdCAo1fNWIm2YA/runs/0/artifacts/public/build/target.dmg

I can confirm that this build fixed the issue for me as well, on Windows 11. A 4K 30 fps VP9 video on YT which I tested before plays pretty much flawlessly now.

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

okay I have found the root cause of this problem, and this build [1] fixed the issue for me on Windows 11. If anyone has free time, please free feel to help me verify whether this build works for you as well. I will post another comment to explain the problem tomorrow.

The build appears to fix things for me on Linux as well, although I did have to hunt down the debug build because for some reason the optimized one segfaults when attempting to launch firefox-bin (and was also missing firefox?). I haven't noticed any sign of it skipping forward or getting stuck, but I do notice a very few dropped frames that can hopefully be attributed to it being a debug build.

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

okay I have found the root cause of this problem, and this build [1] fixed the issue for me on Windows 11. If anyone has free time, please free feel to help me verify whether this build works for you as well. I will post another comment to explain the problem tomorrow.

Working perfectly for me! https://i.imgur.com/jtey9Lp.png No dropped frames like another user mentioned, and no issues running the build either.

Playback generally seems much snappier, and I don't experience issues playing higher bitrate videos that push my bandwidth. Youtube has felt generally janky for so long, seemingly because of this issue and now it seems completely fixed. You are a hero <3

Just realised that this screenshot says av01 somehow... Apparently when I click fullscreen it changes from vp09 to av01? Unsure if that is intentional or not, I haven't seen that before - however I disabled av1 and tried multiple videos again and can confirm it is working correctly using only vp9.

I also don't see any problems on my Mac mini (M1 chip) yet, even when playing this video: https://www.youtube.com/watch?v=rIYBi97ZKF8

But I can say more accurately only after these changes/fixes make it into the final release, because in the final and dev versions, hardware acceleration works fine for me, unlike this build.

Thanks all for commenting here and verifying Alastor's fix, it's as always much appreciated!

We'll now be patching our various channels, and the fix should reach everybody in a few days, I'm cleaning up his patch and test runs are under way as I write this, and a dot release is planned. It's likely it's going to be 127.0.2, as 127.0.1 is already going out to fix something else unrelated to this bug. It's going to be clear when we know for sure, we'll let everybody know.

Answering a few questions I saw:

• Hardware acceleration isn't impacted by this fix (absolutely not in the same part of the code, completely unrelated), and any failure there is likely due to the nature of the build we handed out -- it will all work as expected when released.
• It's plausible that YouTube decides to switch from vp9 to av1 when going full screen, this is not under our control, they do what they want, but thanks for double-checking everything!
• Debug builds are horribly slow (on purpose, so it's easier to debug!), so dropped frame there can 100% be attributed to that, especially if not using hw acceleration on Linux, but even if using it, I'd say. Decoding the frames is far from being the only thing that need to happen for smooth media playback, and hw accelerated decoding only help with, well, the decoding.

All, this hasn't landed in Nightly yet, there is no need to test anything any more, please refrain from posting speculations here, it's a matter of hours until this merged and will be available in Nightly.

Assigning to Alastor since he has the latest fix for this under development. (comment 86)

#86

It is better then main FF version but still not perfect for me. Some logs bellow.
*) Some of my earlier logs were related to a different problem than audio timings

https://share.firefox.dev/3xnrAAX YT runs low on buffer, buffer is filled in last moment, video is frozen, audio plays for 20s, fast forward to resume video.

https://share.firefox.dev/3z8cmQS Live stream freeze after few seconds, buffering, fast forward after few seconds fixes issue.

https://share.firefox.dev/3xp7ias Video freeze for 2 seconds (~10s before log ends) audio plays. https://i.imgur.com/Ox9hMgN.png

https://share.firefox.dev/3VLCytn Video freeze for ~1 second, audio plays ( ~10 seconds before log ends ) https://i.imgur.com/kemHNk8.png

https://share.firefox.dev/3Vsyhtt Live stream plays for ~5 seconds, freeze https://i.imgur.com/DIYiirc.png , fast forward, 5 seconds playback, freeeze https://i.imgur.com/Ss325xZ.png , fast forward, 5 seconds playback, freeze https://i.imgur.com/jAkfn7b.png

https://share.firefox.dev/3xep0NQ Video freeze for 5 seconds with audio in background with healthy buffer https://i.imgur.com/ZxDoLNp.png

I'm going to write down an analysis of this problem for future readers.

This problem is triggered by bad muxed VP9 bytestream served by Youtube, so it's not a regression on our side, this issue can also be reproduced on old versions Firefox. Usually when muxing a video bytestream, the video samples' timestamp should be monotonizally increasing and no overlap between samples. But there are some bad video samples in YT's bytesteam, they overlapped with the previous sample. Eg. [124416000, 125126000] and [125125000, 131382000]. The next one should start from 12516000 instead of starting from 125125000 causing an overlapping.

That overlapped sample triggers this and our WebM demuxer fails to calculate the next timestamp in that situation. The end time of video sample was set to the same as the sample's start time, and that causes a gap being detected for the next sample, resulting in resetting append state. When doing so, mNeedRandomAccessPoint would be set to true and that triggers the sample skipping mechanism per the spec.

Therefore, there would be many sample being incorrectly skipped and won't be added into the buffered range. When entering the buffering state, Firefox would be waiting those sample which has been skipped but Youtube thought that those samples were already appended. That makes the endless buffering happened.

https://hg.mozilla.org/mozilla-central/rev/f9eb1d015824

The patch landed in nightly and beta is affected.
:alwu, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox128 to wontfix.

For more information, please visit BugBot documentation.

Comment on attachment 9408182 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

Beta/Release Uplift Approval Request

• User impact if declined: Youtube would have a high chance stucking at buffering forever when video is vp9 and its resolution is 1440p or 4K
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 83.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It addresses an edge case of handling MSE bad muxed samples which is not common, and it would only affect the end timestamp, where the worst side effect this would bring is dropping some video frames.
• String changes made/needed: No
• Is Android affected?: Yes

Comment on attachment 9408182 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

I still found the issue reproducible on Nightly, need to investigate it again...

After discussed with Paul offline, we made a mistake when doing rebasing. We will have another patch ASAP. Sorry about that.

I downloaded the build Alastor provided and am still encounting the long buffer bugs with embedded and on-side Youtube videos FYI

Would you mind follow this instruction to capture a profiled result to me, but change the log modules to timestamp,HTMLMediaElement:4,HTMLMediaElementEvents:4,cubeb:5,PlatformDecoderModule:5,AudioSink:5,AudioSinkWrapper:5,MediaDecoderStateMachine:4,MediaDecoder:4,MediaFormatReader:5,GMP:5,EME:5,MediaSource:5,MediaSourceSamples:5? Thanks!

The test build fixes the issue for me. But I found something else by testing around a bit.

I messed a bit around with some youtube videos and found there is still some similar issue that might be related to this issue.

I watched a video almost to the end so the whole video was buffered (1440p). Then I rewind back to the first second of the video. (video buffer gets flushed)
Sometimes the timer and the progressbar of the video timeline will be stuck at 0:01 seconds while the video ist still playing. The buffer of the video will not refill so the video plays until the end of the buffer. (~5 seconds)

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

After the video is stuck, I click 0:03 on the video timeline and suddenly it unstucks itself:
https://share.firefox.dev/4cnUK1C

I remember seeing this issue for a while (at least a year?). So it's not introduced by your patch.
I also found videos where I can do the same thing (rewind back to second one) and the video buffer doesn't get flushed at all.

(In reply to bauwom from comment #123)
Video used while creating these logs:
https://www.youtube.com/watch?v=fCO7f0SmrDc

Hopefully this fix will also make its way into Firefox 115 ESR soon.

https://hg.mozilla.org/mozilla-central/rev/b52c32cd0aec

Comment on attachment 9408182 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

Beta/Release Uplift Approval Request

• User impact if declined: Video playback on Youtube would have a high chance being stuck at buffering forever when video is vp9 and its resolution is 1440p or 4K
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: The fix should be deployed to Nightly tomorrow, see comment 83 for STR.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It addresses an edge case of handling MSE bad muxed samples which is not common. This patch doesn't introduce any other new behavior or structural change.
• String changes made/needed: No
• Is Android affected?: Unknown

Comment on attachment 9408175 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

Beta/Release Uplift Approval Request

• User impact if declined: Video playback on Youtube would have a high chance being stuck at buffering forever when video is vp9 and its resolution is 1440p or 4K
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: The fix should be deployed to Nightly tomorrow, see comment 83 for STR.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It addresses an edge case of handling MSE bad muxed samples which is not common. This patch doesn't introduce any other new behavior or structural change.
• String changes made/needed: No
• Is Android affected?: Unknown

I can confirm that the fix has been deployed on the latest Nightly, where no endless buffering issue for me on Windows 11. If anyone still encounters this issue, please capture a profiled result based on the instruction in the comment 122, and either post it here or send it to me ([email protected]) directly. Thanks!

I believe this will need an esr115 patch and approval request also? If so, please do so following the directions below and doing the approval request in Phabricator so that the correct metadata and reviewers are set on it.
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift

Comment on attachment 9408175 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: It affects Youtube viewing experience, video would stuck at buffering
• User impact if declined: Video playback on Youtube would have a high chance being stuck at buffering forever when video is vp9 and its resolution is 1440p or 4K
• Fix Landed on Version: 129
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It addresses an edge case of handling MSE bad muxed samples which is not common. This patch doesn't introduce any other new behavior or structural change.

Hello everyone, some users told me that the infinite buffering issue has gone for them on normal videos, but they still encounter same issue on live VP9 stream on Youtube. If anyone also encounter that problem, let's discuss the issue in bug 1900191. Thanks.

Still getting this issue on latest nightlies for the past couple of days:

In the log below I played this video: https://youtu.be/c015_tDA40A, and skipped maybe 2 or 3 times before it started hanging. It got stuck at that point for about ~10-15 seconds before resuming on its own.

This is happening to me on lots of different videos, below or above 1440p. Also happens to me on music.youtube.com playback.

Let me know if this log is correct:

https://share.firefox.dev/4ezCWmh

Sorry you need to use media preset to capture a profiled result so that we can see media related markers and logs, you can follow this instruction, thanks!

I was confused because the instructions linked in comment 122 said I should use the Media playback preset, but then there were log modules you said I should use? I thought the log modules were to be used instead of the media playback preset.

Here's one with just the media playback preset selected, and no extra log modules added in
https://share.firefox.dev/4ccKauJ

I've reproduced the issue using the YT video from comment 83, on an affected Nightly build (2024-02-03) with Win 11.

The issue is verified as fixed on the latest builds, Nightly 129.0a1, Beta 128.0b7 and Dot Release 127.0.2. Tested with Win 11, macOS 14 and Ubuntu 20.04 x64.

:alwu this does not graft cleanly to esr115.
Please rebase the patch and submit the approval request in Phabricator.
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift

Rebased for ESR115 attached, there were conflicts, but it was an easy one. Do you need anything for the other one?

(In reply to Paul Adenot (:padenot) from comment #141)

Rebased for ESR115 attached, there were conflicts, but it was an easy one. Do you need anything for the other one?

Thanks :padenot!
What do you mean by "the other one"?

https://bugzilla.mozilla.org/show_bug.cgi?id=1900191 ?

(In reply to Paul Adenot (:padenot) from comment #144)

https://bugzilla.mozilla.org/show_bug.cgi?id=1900191 ?

Bug 1900191 does not have an ESR uplift request. I'll add a NI for you to add one.
It will need a rebased patch

Comment on attachment 9408175 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time. r?padenot

Approved for 115.13esr.

https://hg.mozilla.org/releases/mozilla-esr115/rev/d80101c053542194d169cfb69802e650748c7f75
Backed out of ESR115 for causing build failures (also backed out Bug 1900191 and Bug 1904168)
Push: https://treeherder.mozilla.org/jobs?repo=mozilla-esr115&revision=50b824509129bc83debf5203ca0817163aa1074f
Example: https://treeherder.mozilla.org/logviewer?job_id=464303443&repo=mozilla-esr115&lineNumber=12291

Comment on attachment 9409964 [details]
Bug 1878510 - When recreating WebM demuxer when encountering a new segment, propagate media time (esr115 rebase)

Fix the build error in another patch, discard this one.

I've updated a new patch (D215156) for the ESR115, and no change needed for other patches.

This is also verified as fixed on 115.13esr with macOS 14, Win 11 and Ubuntu 20.04 x64.