Closed Bug 1617929 Opened 2 years ago Closed 2 years ago

Broken streaming videos on


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




Tracking Status
firefox-esr68 --- unaffected
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- fixed


(Reporter: mortimergoro, Assigned: bryce)




(Keywords: regression, Whiteboard: [fxr:p1][geckoview:p1])

Crash Data


(2 files)

When playing streaming videos on , 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:

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

Priority: -- → P3
Rank: 5
Priority: P3 → P2
Whiteboard: [fxr:p1][geckoview:m76]

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?

Whiteboard: [fxr:p1][geckoview:m76] → [fxr:p1][geckoview:p1]
Rank: 5
Priority: P2 → P3

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

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

Flags: needinfo?(miket)

Dennis, can you look into this one please?

Flags: needinfo?(miket) → needinfo?(dschubert)

This issue can be reproduced via Firefox Reality from the below URL as well:

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

Flags: needinfo?(dschubert) → needinfo?(twisniewski)

This issue does not exist in Firefox Reality 1.3.2 according to the latest test from HTC.

Does that suggest this is a regression?

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.

Flags: needinfo?(twisniewski)

Please try to repo this issue on You can do that without VPN, and it is an open web.
repo steps.

  1. Using Firefox Reality to visit 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.

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 '' -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:' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer:' -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.

I can confirm that version 1.4 on my Go exhibits the problem, while 1.3 does not (as found on

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.

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?

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

Flags: needinfo?(bvandyk)

:jhlin is currently investigating this.

Flags: needinfo?(bvandyk)

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.


Assignee: nobody → jolin
Priority: P3 → P2

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

Keywords: regression

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

Assignee: jolin → bvandyk
Regressed by: 1560092

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

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

Depends on D70766

Attachment #9140271 - Attachment description: Bug 1617929 - Make a best effort to use extra data found in encrypted h264 samples. r?jya,jolin → Bug 1617929 - Make a best effort to use extra data found in h264 samples. r?jya,jolin
Pushed by
Remove H264Changemonitor's special encrypted handling. r=jya,jolin
Make a best effort to use extra data found in h264 samples. r=jya,jolin
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Duplicate of this bug: 1588198
Crash Signature: [@ mozilla::H264ChangeMonitor::PrepareSample]
You need to log in before you can comment on or make changes to this bug.