1834275 - "the quota has been exceeded" makes it impossible to watch some videos on Unity site

Status: VERIFIED FIXED

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

Description

[Alfred]

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

Steps to reproduce:

Trying to watch video tutorials on Unity website at this address:
https://learn.unity.com/tutorial/introduction-to-artificial-intelligence?uv=2021.3&courseId=5dd851beedbc2a1bf7b72bed&projectId=63442b67edbc2a1417afe845#

Actual results:

When I click the "play" symbol on the video, after a few seconds the "the quota has been exceeded" message appears on top of the video frame. The play symbol is replaced by an X surrounded by the "loading" animation. Nothing else happens from that moment on.

Expected results:

The video should have started, as it happens without problems in Google Chrome.

I followed some suggestions found online to change some of the dom.storage settings and then restarted Firefox, but nothing changes. In any case, this is something that should work "out of the box" without the need of tampering around...

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jens Stutte [:jstutte]]

(In reply to Alfred from comment #0)

Actual results:

When I click the "play" symbol on the video, after a few seconds the "the quota has been exceeded" message appears on top of the video frame. The play symbol is replaced by an X surrounded by the "loading" animation. Nothing else happens from that moment on.

I tried and for me it shows "the quota has been exceeded" right away once clicked on the video. Did the video start for you?

I disabled "Enhanced Tracking Protection" (as there were some hints about blocked cookies in the console), but no luck.

I am able to see other Videos on that site, as well as the demo on https://videojs.com/ which seems to be the used player here. I have no idea what makes this video special.

From the code it looks as if we'd use NS_ERROR_DOM_QUOTA_EXCEEDED_ERR in quite some media related places in order to signal large/invalid buffer values or such. Is that actually wanted? It looks confusing (I do not know, if some of those is what we see here).

Edit: From https://www.w3.org/TR/media-source-2/ it seems we must expect QuotaExceededError not only from storage APIs. And from the error definitions I understand we can have different error messages. Filing a bug.

Comment 3

[Jens Stutte [:jstutte]]

Marking this depends on bug 1834326 in the meaning of "if we had this we knew where it comes from". There might be other ways to find out, of course.

Comment 4

[Alfred]

(In reply to Jens Stutte [:jstutte] from comment #2)

(In reply to Alfred from comment #0)

Actual results:

When I click the "play" symbol on the video, after a few seconds the "the quota has been exceeded" message appears on top of the video frame. The play symbol is replaced by an X surrounded by the "loading" animation. Nothing else happens from that moment on.

I tried and for me it shows "the quota has been exceeded" right away once clicked on the video. Did the video start for you?

No, It didn't. It just takes 3-4 seconds of time before showing the message...

Comment 5

[Jens Stutte [:jstutte]]

With the patch from bug 1834326 I see:

VIDEOJS: ERROR: (CODE:-3 undefined) MediaSource buffer exceeded. 
Object { code: -3, type: "APPEND_BUFFER_ERR", message: "MediaSource buffer exceeded.", originalError: DOMException }

Comment 6

[Paul Adenot (:padenot)]

When fixing this, we need to add more logging in error paths. The cause should be absolutely evident when logging and it is not.

Comment 7

[Jim Mathies [:jimm]]

Hey Paul, is the Unity site doing something we don't like ('MediaSource buffer exceeded') or are we being overly restrictive here? Can we address this by increasing buffer sizes or is this something Unity needs to fix?

Comment 8

[Paul Adenot (:padenot)]

I'm halfway debugging this. Finger's crossed it's going to boil down to changing a couple constant on our end.

Comment 9

[Paul Adenot (:padenot)]

Attachment: Bug 1834275 - Allow passing in a track type to TrackBuffersManager::EvictionThreshold. r?alwu

Comment 10

[Paul Adenot (:padenot)]

Unity does something that's valid but uncommon: adding about 20MB of audio to an MSE. We can simply add a pref to fix this.

It's likely that we'll clean all this later this year, because https://github.com/w3c/media-source/issues/232 is being worked on.

Comment 11

[Paul Adenot (:padenot)]

Jim, we can fix this on release quickly by pushing a new value for media.mediasource.eviction_threshold.audio, upping it to 100 * 1024 * 1024 (100MB), if we feel it's important.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/20056e07ec0b
Allow passing in a track type to TrackBuffersManager::EvictionThreshold. r=alwu

Comment 13

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/20056e07ec0b

Comment 14

[Dana Lucaci, Desktop QA]

Reproduced the issue with Firefox 114.0a1 (2023-04-26) on MacOS 12.
The issue is verified fixed with Firefox 117.0a1 (20230726093921) and Firefox 116.0 (20230724170120) on MacOS 12, Win 10 and Ubuntu 22.