1617929 - Broken streaming videos on video.friday.tw

Status: RESOLVED FIXED

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

Description

[Imanol Fernandez]

When playing streaming videos on https://video.friday.tw , Firefox Reality (user-agent mode: desktop) displays the green/black/Mosaic screen after 2~5 seconds playback.

I also tried in Fenix and GeckoView and got a infinite spinner.

It works well in Firefox Desktop.

STR and video recoding here: https://github.com/MozillaReality/FirefoxReality/issues/2844

Comment 1

[Imanol Fernandez]

I confimed that it works in Oculus Browser on the Oculus Quest, so it doesn't seem related to a system codec/GPU bug.

Comment 2

[Emily Toop (:fluffyemily)]

Sorry for changing the priority. I thought this was in the GV component. Reverting and adding priority whiteboard flags instead.

This is now a P1 issue for GeckoView V76, if that is possible?

Comment 3

[Lars Bergstrom (:larsberg)]

cc :miketaylr for webcompat regression / ideas on this one, too.

This is an extremely high priority bug for our partners distributing in Taiwan. Thanks!

Comment 4

[Mike Taylor [:miketaylr]]

Dennis, can you look into this one please?

Comment 5

[kaiping_lee]

This issue can be reproduced via Firefox Reality from the below URL as well: https://bitmovin.com/demos/drm

Comment 6

[Mike Taylor [:miketaylr]]

(Dennis is PTO this week, Tom, can you look please?)

Comment 7

[kaiping_lee]

This issue does not exist in Firefox Reality 1.3.2 according to the latest test from HTC.
https://github.com/MozillaReality/FirefoxReality/releases/tag/1.3.2%2Bwavevr

Comment 8

[Mike Taylor [:miketaylr]]

Does that suggest this is a regression?

Comment 9

[Thomas Wisniewski [:twisniewski]]

Unfortunately, after trying over a VPN, I get this error in an alert-box when I click to play the video in Fenix while viewing in desktop mode: 請確認瀏覽器版本是否支援(htl10)

Which appears to be a DRM error:

	} else if (code == '0x81000010') {
		return 'VO_OSMP_DRM_ERR_SELECT_KEY_SYSTEM_FAIL#請確認瀏覽器版本是否支援(htl10)';

So this is a DRMed video, and I think Fenix doesn't support those yet. I'll try to get my Oculus up and running.

Comment 10

[kaiping_lee]

Please try to repo this issue on https://bitmovin.com/demos/drm. You can do that without VPN, and it is an open web.
repo steps.

1. Using Firefox Reality to visit https://bitmovin.com/demos/drm via Vive Focus plus.
2. Switch Firefox Reality to "Desktop mode".
3. Play the video and you can see the green screen after 3~5 seconds.

Comment 11

[Thomas Wisniewski [:twisniewski]]

Ah, thanks, I had missed that comment, kaiping_lee.

I can reproduce this on my Oculus Go with the link given above, while in desktop mode (after a few seconds the video becomes garbled). Since I do see Firefox requesting encrypted DASH segments, such as:

curl 'https://bitmovin-a.akamaihd.net/content/art-of-motion_drm/video/1080_4800000/cenc_dash/segment_7.m4s' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0' -H 'Accept: */*' -H 'Accept-Language: en-US' --compressed -H 'Origin: https://bitmovin.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://bitmovin.com/demos/drm' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

However, the site sends the same segment data regardless of the user-agent, so it does not seem to be the stream itself. Especially since when I pause the video and resume it, then the problem seems to go away.

I can't compare with the Oculus or Samsung browsers, because they both crash on the tab (with a slow script warning on the Oculus browser).

Additionally, I see suspect behavior from the page when viewing in FxR in non-desktop mode, which causes it to simply break before it can even play video:

This polyfill script throws because "species" is not a redefinable property:

  Object.defineProperty(Symbol, 'species', {
    value: Symbol('species')
  });

Then there is an endless recursion happening in their player script (which is possibly why the other browsers are crashing, since the Oculus Browser shows a slow-script warning).

I'm not sure where to go from here.

Comment 12

[Thomas Wisniewski [:twisniewski]]

I can confirm that version 1.4 on my Go exhibits the problem, while 1.3 does not (as found on https://github.com/MozillaReality/FirefoxReality/releases)

rbarker suggests to me that the only likely difference between the two versions is the Geckoview version used:

• 1.3.0 GV 70.0.20190710094220
• 1.4 used GV 71.0.20190909095540

Which implies that something in that range should have caused this.

Comment 13

[Victor]

It looks like we're having the same issue here, that DRM video will be playing garbled in GV-nightly-71.0.20191003093956, we've been blocked for weeks, unluckily, we can't change our GV version to give it another try in our case, it's linked to another library we bought.

I was wondering is there a setting or function changing between GV 70 and GV 71? Will this issue be fixed if we call some functions or make some settings?

Comment 14

[Emily Toop (:fluffyemily)]

It is looking like this is definitely a media issue that has regressed after Gecko 70. Can you take a look Bryce?

Comment 15

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

:jhlin is currently investigating this.

Comment 16

[John Lin [:jhlin][:jolin]]

Finally reproduced it successfully. It only happens when the alternative stream is received.

From the network panel in about:debugging it looks like the page downloaded a 720p init segment followed by a video segment, then another init segment, this time 1080p, with video remaining segments following. I suspect that this is a regression of bug 1560092. Since the patch there, MediaChangeMonitor no longer prepends SPS/PPS to key frames when the contents are encrypted [1]. Because SPS/PPS only exists in init segment and not in the sample of AVC1 video segment, the recycled decoder on Android won't receive the necessary configuration data to decode correctly.

[1] https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#50

Comment 17

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 18

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Stealing this as I'm working on fixing the regression. Many thanks to John for figuring out what's going on.

Comment 19

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 1617929 - Remove H264Changemonitor's special encrypted handling. r?jya,jolin

This undoes the changes from bug 1560092. These changes assumed that we couldn't
play encrypted avc3 content as we couldn't read SPS + PPS info from the stream.
However, after some testing I believe the issue is we can try and detect SPS +
PPS data in such streams, but need to better handle the encrypted case.

A following patch will address better handling SPS + PPS data in encrypted
streams.

Comment 20

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: Bug 1617929 - Make a best effort to use extra data found in h264 samples. r?jya,jolin

Prior to this patch if we tried to extract extra data from an encrypted h264
sample but then found a partial NAL unit we'd discard the already found extra
data rather than processing it. This is problematic for avc3 streams where
encryption starts during a NAL unit, as even if we'd seen extra data prior to
finding such a partial unit, we'd discard it.

With this patch we will instead process the extra data we've already found in a
best effort attempt. If we get sent avc3 content that encrypts in band extra
data we'll still be in trouble, but I am not sure such content exists at this
stage.

Depends on D70766

Comment 21

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=670c8dc8fb9acbc7394ea85fa0fca52139af7b74&selectedJob=297786400

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8d298947b2d8
Remove H264Changemonitor's special encrypted handling. r=jya,jolin
https://hg.mozilla.org/integration/autoland/rev/e1c8313256c7
Make a best effort to use extra data found in h264 samples. r=jya,jolin

Comment 23

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/8d298947b2d8
https://hg.mozilla.org/mozilla-central/rev/e1c8313256c7