1136138 - With https://hg.mozilla.org/releases/mozilla-aurora/rev/419b32569a76, Youtube videos are re-buffering every few minutes.

Status: RESOLVED DUPLICATE of bug 1132825

(Core :: Audio/Video, defect)

Description

[Johan C]

This started with this build: https://hg.mozilla.org/releases/mozilla-aurora/rev/419b32569a76.

Videos are re-buffering every few minutes, i.e. the video stops and the grey video buffer bar is reset. For me the video will resume almost immediately, but this is most likely due to the fact that my connection is fast enough to "recover"/re-download. I could see this being more noticeable on slower connections.

Example video (3 hours long): https://www.youtube.com/watch?v=Jp59FElhOTw
Note that this will happen with shorter videos as well.

Comment 1

[Johan C]

Attachment: Log: (MEDIA_LOG_SAMPLES=1 NSPR_LOG_MODULES=MediaDecoder:5,MediaSource:5,MediaPromise:5,MP4Demuxer:5)

Log created with:
MEDIA_LOG_SAMPLES=1
NSPR_LOG_MODULES=MediaDecoder:5,MediaSource:5,MediaPromise:5,MP4Demuxer:5

Comment 2

[Johan C]

I should also note that I cannot reproduce this on Nightly (https://hg.mozilla.org/mozilla-central/rev/9b077c6f3d02), but maybe someone else can.

I can however reproduce it with a fresh profile on Aurora (https://hg.mozilla.org/releases/mozilla-aurora/rev/419b32569a76). The log above was capture with said profile on Aurora.

Comment 3

[Marcia Knous [:marcia]]

Syd: Can you try to reproduce this issue?

Comment 4

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Ralph - is Aurora missing a patch or does John have an old build?

Comment 5

[Jean-Yves Avenard [:jya]]

Did someone change their source buffer threshold value??

With a 75MB default threshold, you should never enter the state where the track buffer couldn't evict enough data.

Comment 6

[Syd Polk :sydpolk]

Been watching that video with Aurora for about 15 minutes now on Windows 7, and I see no discontinuities.

Comment 7

[Syd Polk :sydpolk]

Works fine with my other Windows machine as well.

Comment 8

[Ralph Giles (:rillian)]

I can't reproduce with aurora on mac with that url either.

The indicated revision is the uplift of bug 1133625. I think JohnC might mean 37 beta, not Aurora?

Comment 9

[Johan C]

Attachment: Screenshot of about:buildconfig and "About Firefox"-dialog.

> The indicated revision is the uplift of bug 1133625. I think JohnC might
> mean 37 beta, not Aurora?

Nope. It's Aurora alright. I can't speak for what John is using however. ;)

Additional notes:
* Videos are played in 720p.
* Videos can be played in normal mode or in fullscreen mode.
* 0 installed extensions.
* The only plugin enabled is "OpenH264 Video Codec provided by Cisco Systems, Inc. 1.3".

Comment 10

[Ralph Giles (:rillian)]

(In reply to Johan C from comment #9)
> Created attachment 8568813 [details]
> Screenshot of about:buildconfig and "About Firefox"-dialog.
> 
> > The indicated revision is the uplift of bug 1133625. I think JohnC might
> > mean 37 beta, not Aurora?
> 
> Nope. It's Aurora alright.

So you can reproduce with the 37.0a2 (2015-02-23) official build? I guess we haven't published an aurora build of 38 yet?

> I can't speak for what John is using however. ;)

Sorry!

Can you also please verify clearing the VISITOR_INFO1_LIVE youtube cookie doesn't resolve the issue. You said clean profile, so probably not, but that was a weird one I hit on Sunday right after those changes landed.

Comment 11

[Johan C]

(In reply to Ralph Giles (:rillian) from comment #10)
> (In reply to Johan C from comment #9)
> > Created attachment 8568813 [details]
> > Screenshot of about:buildconfig and "About Firefox"-dialog.
> > 
> > > The indicated revision is the uplift of bug 1133625. I think JohnC might
> > > mean 37 beta, not Aurora?
> > 
> > Nope. It's Aurora alright.
> 
> So you can reproduce with the 37.0a2 (2015-02-23) official build? I guess we
> haven't published an aurora build of 38 yet?
Yep, it's an official build. 

If I'm not entirely mistaken Aurora isn't updated until Friday.

> > I can't speak for what John is using however. ;)
> 
> Sorry!
:D

> Can you also please verify clearing the VISITOR_INFO1_LIVE youtube cookie
> doesn't resolve the issue. You said clean profile, so probably not, but that
> was a weird one I hit on Sunday right after those changes landed.
Hmm, I forgot I used (and probably created) the profile to debug bug 1132034. Sorry!
I cleared all cookies including VISITOR_INFO1_LIVE and the bug unfortunately persists.

If anything, clearing all cookies increased the "buffering pause". Previously the video would stop for a split second before continuing, now it stops for about 2 seconds (ish). This however might be entirely coincidental.

Comment 12

[Johan C]

(In reply to Johan C from comment #11)
> If anything, clearing all cookies increased the "buffering pause".
> Previously the video would stop for a split second before continuing, now it
> stops for about 2 seconds (ish). This however might be entirely coincidental.

This does not appear to be coincidental. I went back to my main profile (where I initially saw the bug) and cleared the "VISITOR_INFO1_LIVE"-cookie, to no effect. However, after clearing all "youtube" related cookies the "buffering pause" increased to 2-3 seconds (ish) on this profile as well.

This might be relevant for anyone trying to reproduce the bug.

STR (of sorts):
1. Clear all "youtube" related cookies.
2. Load and play any youtube video (I could reproduce it with the 3 hour long video in comment 0).
3. Let the video play, do not pause or skip ahead. The video can play in a background tab.

Actual result:
The video can start to re-buffer at any time, the earliest so far was about two minutes in. But usually I have to wait for between 8–14 minutes. The video will then continue to re-buffer every 8–14 (ish) minutes.

Comment 13

[Jean-Yves Avenard [:jya]]

Johan C, have you set a value in about:config : media.mediasource.eviction_threshold, and if so what value did you set?

The only time YouTube will clear the entire buffer and attempt to rebuffer everything is when it attempts to add data, and the size of that data exceed the size of our buffer. With the default eviction threshold value, this will never happen.
With a value set to < 30MB, it can happen as from time to time YouTube attempts to add a very large buffer, exceeding 25MB.

Comment 14

[Jean-Yves Avenard [:jya]]

Never mind.. analysing the log gave me all the information I wanted to see.

We hit bug 1135532, but in a different fashion. It causes no data to be evicted, so we throw a QuotaExceededError exception.

This problem would have been prevented by bug 1132825, but Aurora is missing this commit  https://hg.mozilla.org/mozilla-central/rev/7def63a22bed
(I made a mistake which had overwritten that change in an earlier commit, it would have been easy to overlook)

On top of this, for bug 1133625 to not introduce regression, we need to also uplift bug 1134064, or revert it completely.
Bug 1135532 needs to be uplifted ASAP as well.

Comment 15

[Ralph Giles (:rillian)]

Thanks for the the analysis, Jean-Yves. I've pushed the followup revert from bug 1132796 to 37 now. That was my oversight. I was the patch and requested approval for it but didn't actually push the change.

Comment 16

[Jean-Yves Avenard [:jya]]

As per IRC discussion

Comment 17

[Jean-Yves Avenard [:jya]]

Quick update. The video stops at 141s because it's cut short. While the moof indicates we have 145s of video, there's only 141s in the mdat

Comment 18

[Jean-Yves Avenard [:jya]]

wrong bug

Comment 19

[advcomp2019]

Well, with my bug(https://bugzilla.mozilla.org/show_bug.cgi?id=1131884), I think I am starting to get this bug without MSE and an hour or more long videos now because the buffer goes once I get the video going again but then a few minute it gets buffered to a point. Then a few minutes later, the buffer is going back down to back to where the progress bar is at.