1904937 - Youtube enters infinite buffering after seeking back to the start position

Status: RESOLVED FIXED

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

Description

[Alastor Wu [:alwu]]

This issue is reproducible on my Firefox Release 127 and Nightly 129 on Windows 11.

STR. (reproduce steps video)

1. go to https://www.youtube.com/watch?v=fCO7f0SmrDc
2. start video in 4K resolution
3. seek to the place near the end of buffered range many times, until video buffered range reaches to the end
4. seek back to the start position

Expected.
5. video keeps playing and shows the correct current time

Actual.
5. video's current time stuck at 0.00 (or 1.00 depends on where you seek to) and the buffered range won't keep growing. So video enters infinite buffering when reaching the end of buffering.

---

Here is the media profile I captured on the latest Nightly on Windows 11.

Comment 1

[Alastor Wu [:alwu]]

In addition, I found the reproduce steps video in comment0 sometimes can't start playback successfully on my Firefox Release and Nightly on Windows 11, but that video can start without problem on Chrome. I've filed bug 1904938.

Comment 2

[Alastor Wu [:alwu]]

This seems to be an issue in Youtube player, when the buffer size is full, they would reload the entire resource (like bug 1760529) and then their player seems to have a problem to recognize the correct media current time so that the media time on the player won't be updated, so does the buffered range.

Comment 3

[Alastor Wu [:alwu]]

I'm still investigating this issue, maybe the problem is in our eviction logic. Will update more details after I figure out what happened.

Comment 4

[Alastor Wu [:alwu]]

From my observation, there are two problems, (1) on certain situation, our eviction algorithm fails after seeking back to the start position, which causes the buffered data won't be clear properly so that appending would raise an NS_ERROR_DOM_MEDIA_SOURCE_FULL_BUFFER_QUOTA_EXCEEDED_ERR (2) when Youtube noticed that error, they would try to assign a new source buffer to the media element, which also happens in bug 1760529 as well. Youtube player seems not being able to handle this case properly, so it doesn't update the current time of the player and does not keep appending the data.

Comment 5

[Alastor Wu [:alwu]]

I've informed Youtube about this bug, and I will improve our eviction algorithm in this bug, and increase our video buffer size to 150 MB in bug 1760529.

Comment 6

[Alastor Wu [:alwu]]

I already have a patch for this problem, now I'm working on the test. Will post them once they're ready.

Comment 7

[Alastor Wu [:alwu]]

Attachment: Bug 1904937 - part1 : evict data when the buffer is near full and the next target sample isn't in the buffered range.

Comment 8

[Alastor Wu [:alwu]]

Attachment: Bug 1904937 - part2 : add debug logs.

Depends on D215264

Comment 9

[Alastor Wu [:alwu]]

Attachment: Bug 1904937 - part3 : add a test.

Depends on D215265

Comment 10

[Alastor Wu [:alwu]]

I'm going to write down the analysis of this bug for the future readers. First, this issue is caused by Youtube's player, they should handle the case of buffer full better via trimming the buffer themselves, instead of recreating a new media source. Even if they do so, they should update their player's logic better in order to keep the media time correct in order to append more data. We've reported this issue to Youtube, but no response so far.

My patches here are used to mitigate the buffer full issue by improving our eviction mechanism.

---

By following the STR mentioned in the comment 0. Before seeking back to the start position, the buffer has been almost full. The data eviction wasn't performed after seeking, so Youtube wasn't able to append more data. This is the problem I'm going to improve in this bug.

We update mEvictable to know how many data is able to be evicted, and this only applies for the data before the given index, which means that it won't consider future data.

UpdateEvictionIndex() would be called in multiple places. When we tried to seek to the start position, as the target is not in the buffered range yet, we won't call TrackBuffersManager::Seek() with a given target time. The manager's seek would only be triggered by resetting the demuxer and that would make us set mNextGetSampleIndex to the index of keyframe in the old buffered range, which is 0. As evicting the past data, we always stop at key frame.

As I mentioned above, our eviction would only consider the data before the current index, this call would result in canEvict will always be zero and nothing would be able to be evicted anymore because lastKeyFrameIndex was actually the first key frame index, not the last index. But that would be a different story if the seek target is in the buffered range, then the eviction would work as expected.

Therefore, even if the seek target is not in the buffered range, we still need to be able to evict data successfully.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/930ac66302d7
part1 : evict data when the buffer is near full and the next target sample isn't in the buffered range. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/aa15765aa458
part2 : add debug logs. r=media-playback-reviewers,padenot
https://hg.mozilla.org/integration/autoland/rev/b9567c30bbbb
part3 : add a test. r=media-playback-reviewers,padenot

Comment 12

[tszentpeteri]

https://hg.mozilla.org/mozilla-central/rev/930ac66302d7
https://hg.mozilla.org/mozilla-central/rev/aa15765aa458
https://hg.mozilla.org/mozilla-central/rev/b9567c30bbbb

Comment 13

[Karl Tomlinson (:karlt)]

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

As I mentioned above, our eviction would only consider the data before the current index, this call would result in canEvict will always be zero and nothing would be able to be evicted anymore because lastKeyFrameIndex was actually the first key frame index, not the last index. But that would be a different story if the seek target is in the buffered range, then the eviction would work as expected.

I'm not understanding how eviction would work differently if the seek target were in the buffered range. lastKeyFrameIndex and canEvict would still both be zero, right?

Comment 14

[Alastor Wu [:alwu]]

(In reply to Karl Tomlinson (:karlt) from comment #13)

I'm not understanding how eviction would work differently if the seek target were in the buffered range. lastKeyFrameIndex and canEvict would still both be zero, right?

If seek target is already in the buffered range, then website doesn't need to append more data so no eviction is needed. If seek can be completed, the data would be gradually evicted as the playback moves forward.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Does this need a Release uplift request?

Comment 16

[Alastor Wu [:alwu]]

No, it's not that serious. We can let it ride the train of Fx129.

Comment 17

[Monica Chiorean]

I was able to reproduce it only one time on Win11x64 using FF build 129.0a1(20240626153712).
Could not reproduce it on Win11x64 using FF builds 129.0b8 and 130.0a1.