Steps to reproduce:

1. Open and play Live video (Not all but several live. It seems low latency live stream)
   e.g. https://www.youtube.com/watch?v=jQaDDtiu05E w/ 1080p. Or other low latency video streams.

Actual Results:
Video stops after for a while. But audio is playing.
Profiler log: https://share.firefox.dev/4aEXK8R

When the buffer length reaches 0s, the image seems to stop without recovery.

Thank you for capturing the profile.
From 15.518s, there is a gap in video frame timestamps, with one video frame in the gap with a zero-length zero-start-time interval.

InsertFrames - Processing 2 video/vp9 frames(start:13654934000 end:13655000000)
4 * RequestDecode:V:720<h<=1080:hw,vp9,
InsertFrames - Processing 1 video/vp9 frames(start:0 end:0)
~16 *  RequestDecode:V:720<h<=1080:hw,vp9,
RequestDecode:V:720<h<=1080:kf,hw,vp9,
<- 0.7s no vp9 activity ->
InsertFrames - Processing 5 video/vp9 frames(start:13656000000 end:13656168000)

The same gap is not present in the audio frame timestamps.

A [0, 0] frame was also seen in bug 1878510 comment 13, but the RemoveFrames seen there is not happening here. The spinner seen there is also not here.

I'm not able to play the linked youtube stream from my location.

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

The video stream of comment #0 is not available now.

https://www.youtube.com/watch?v=gcimTLMOLQk, the video and audio will stop and spinning loading spinner forever.
Pofiler: https://share.firefox.dev/4b2lzHy

We've landed a fix in bug 1878510, could you help me try the latest Nightly to see if the issue still persists? If so, could you capture a profiled result for us again? Some people told me that bug 1878510 fixed the buffering problem for normal video, but the problem still happens on live stream video. Thanks!

I can reproduce the infinite buffering issue on this video by switching resolution around.

This issue is still caused by incorrect webm sample's endtime, which triggered the discontinuity check so that Firefox skipped the samples which should have been appended to the buffered range. We need a better way to determine the webm sample's end time, that can be done in bug 1903466.

From the profiled result, here we can see the samples Youtube appended, but the first and the second samples have the wrong end time. As there is an unexpected gap appearing between them, a lot of samples were skipped unexpectedly.

And the reason of why we didn't set the correct timestamp for the first sample is because the appended buffer only contained one frame [46824993000, 46825009000] (duration: 16000), and our webm demuxer doesn't know how to handle that case because we didn't know the duration and there was no previous timestamp.

Comment on attachment 9409034 [details]
Bug 1900191 - use default duration if exists.

Beta/Release Uplift Approval Request

• User impact if declined: YouTube live, especially when low latency is broken: video eventually stop playing, sometimes audio continues
• 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: Attempt to play: https://www.youtube.com/watch?v=jQaDDtiu05E
  https://www.youtube.com/watch?v=uXNU0XgGZhs
  (depending on the location of the QA person). Other low-latency live stream can repro as well.

Please ping padenot (europe) alwu (west coast) if more streams are needed.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This brings Firefox closer to how Chrome handles WebM. The cause of the problem is well understood.
• String changes made/needed: none
• Is Android affected?: Yes

https://hg.mozilla.org/mozilla-central/rev/51c72e671bce

Comment on attachment 9409034 [details]
Bug 1900191 - use default duration if exists.

Approved for 128.0b8 and our 127.0.2 dot release

Note to testers: This patch is in the nightly BuildID 20240624144542

https://hg.mozilla.org/mozilla-central/rev/1ebafa5c7395

Reproduced the issue with Firefox 128.0b7 on Ubuntu 22.04, macOS 13 arm, Windows 10x64 using this Youtube video by changing the resolution of the video multiple times or by clicking on the seek bar. The video will stop and an endless spinning circle will be displayed with a video picture.

The issue is verified fixed with Firefox 129.0a1 (2024-06-24), 128.0b8 from comment 14, and 127.0.2 on macOS 13 ARM, Windows 10x64, Ubuntu 22.04. I tried multiple times to change the resolution of the video and click on the seek bar of the above video and no endless loading occurred.

Please note that sometimes it seems that when changing the resolution to 4k it shows a loading circle for like ~3-4s. This does not happen every time. From what I saw on Chrome the transition to change the video is much faster. This is present on macOS 13 ARM and Ubuntu 22 and not so visible on Windows 10x64. Please let me know if I should file something on this. Thank you!

You mentioned this in https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c144
It does not graft cleanly to ESR115. If this is also needed for ESR115, could you please attach a rebased patch and ESR115 uplift request?

Comment on attachment 9409034 [details]
Bug 1900191 - use default duration if exists.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a follow-up to 1878510 and is an important follow-up to really fix the issue. Both patches landed and release and are known to work well.
• User impact if declined: Regular YouTube and Youtube Live can appear to buffer endlessly under some circumstances.
• Fix Landed on Version: 127.0.2
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is well understood and has received appropriate scrutiny by various groups (devs, QA, users reporting it works, etc.)

Done, let one of us know if something looks funny.

Comment on attachment 9409034 [details]
Bug 1900191 - use default duration if exists.

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 1878510 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

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

The issue is verified fixed with Firefox 115.13.0esr on macOS 14 ARM, Windows 10x64, and Ubuntu 23 using this Youtube Video. I tried multiple times to change the resolution of the video and clicked on the seek bar multiple times and no endless loading occurred.