Video doesn't play on twitch.tv
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: ksenia, Assigned: Zaggy1024)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
This was originally reported in https://github.com/webcompat/web-bugs/issues/105377
To reproduce, visit https://www.twitch.tv/videos/637388605 in Firefox Nightly and observe the video.
The original reporter is experiencing this problem on Linux and I was able to reproduce it on MacOS.
Expected:
Video plays
Actual:
"This video is either unavailable or not supported in this browser. (Error #4000)" error is displayed
This seem to be the only video that has this error, another stream from the same user plays fine.
Reporter | ||
Comment 1•2 years ago
•
|
||
I run mozregression on MacOS and Windows and it points to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=af0c1ff4ce299c32cf252f510dc54c452a080033&tochange=6f97064ebae745b0a85cab06a1e81782ef66c2f1
On Linux it doesn't seem to be a recent regression as it is showing the error in a build from a year ago.
Reporter | ||
Comment 2•2 years ago
|
||
Hi Zaggy, wonder if you could take a look at this, please?
Comment 3•2 years ago
|
||
Set release status flags based on info from the regressing bug 1757861
I wasn't aware that Twitch has AV1 videos available, thanks for reporting this. Looks like they're using "video/mp4;codecs="av01.0.31M.08"" as their mimetype, which specifies level 31, which as indicated by spec should be equivalent to the highest level parameters available. Not sure why they're using it, but it highlights something I missed in the spec.
I believe the solution for this would be to check for level == 31 here and change that to the maximum actual valid level (23 if spec is never revised).
I'm setting up my development environment again now, so I can get to this in a while if nobody else can add in that quick fix.
Actually, after another look at the spec, it seems like it needs to be changed to accept level == 31 and store it internally, I'll have to check whether there are any other places that may break it. The quote from spec:
If seq_level_idx is equal to 31 (indicating the maximum parameters level), then there are no level-based constraints on the
bitstream.
Self-assigning this so that I can create a patch once my development environment is ready.
Updated•2 years ago
|
Updated•2 years ago
|
Fixes an issue where AV1 test videos on twitch.tv would be unable to play.
Pushed by zaggy1024@gmail.com: https://hg.mozilla.org/integration/autoland/rev/9fb58db3c3f1 Accept AV1 level 31 in codec parameter strings. r=alwu
Comment 8•2 years ago
|
||
bugherder |
Comment 9•2 years ago
|
||
The patch landed in nightly and beta is affected.
:Zaggy1024, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox102
towontfix
.
For more information, please visit auto_nag documentation.
Comment 10•2 years ago
|
||
Alastor, that looks like something we should uplift in 102, what do you think?
Comment 11•2 years ago
|
||
Comment on attachment 9280555 [details]
Bug 1773120 - Accept AV1 level 31 in codec parameter strings. r=alwu
Beta/Release Uplift Approval Request
- User impact if declined: Some AV1 video can't be played
- 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 comment0.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This patch doesn't introduce any new feature or structural change, it simply allows us to support AV1 video with profile level 31.
- String changes made/needed:
- Is Android affected?: Yes
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Comment on attachment 9280555 [details]
Bug 1773120 - Accept AV1 level 31 in codec parameter strings. r=alwu
Approved for 102 beta 8, thanks.
Comment 13•2 years ago
|
||
bugherder uplift |
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Reproduced the issue on Firefox 103.0a1 (2022-06-07) under macOS 12.4 by following the STR from Comment 0.
The issue is fixed on latest Firefox 103.0a1 (2022-06-14) and Firefox 102.0b8 (treeherder build). Tests were performed on macOS 12.4, Ubuntu 22.04 and Windows 11.
Updated•2 years ago
|
Description
•