Since firefox 96, video received over p2p isn't being decoded and played in some instances
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | wontfix |
firefox98 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | wontfix |
People
(Reporter: gama.l, Unassigned, NeedInfo)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
I watched a live video of a camera through a website, which can be displayed normally before firefox 95, but it cannot be displayed normally after firefox 96.
I compared the nightly version through mozregression, and the final result is as follows:
INFO: Last good revision: 4f57142ccd08255c6e87390db6772db94a1033c4 (2021-10-31)
INFO: First bad revision: 08eb1047d841ce4f1fcee1595dc4ec7ed8cba8f5 (2021-11-01)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4f57142ccd08255c6e87390db6772db94a1033c4&tochange=08eb1047d841ce4f1fcee1595dc4ec7ed8cba8f5
I checked the pushlog records and found that there are many changes between the two versions. I am not sure which change caused the problem, and how should I solve this problem.
The website used is https://live.amaryllo.eu. Need to go to about:config and set media.navigator.mediadatadecoder_h264_enabled to false.
Can refer to my attached file
Actual results:
I used wireshark to query the connection packets. The cameras all send instant video to firefox, but the 95 version can be displayed normally, but the 96 version can't be displayed.
Expected results:
Should be able to watch live video normally
![]() |
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Thanks gama.l for the detailed report and regression range, which points to bug 1654112, which was a major libwebrtc update.
... Need to go to about:config and set media.navigator.mediadatadecoder_h264_enabled to false.
Do I understand correctly that if you don't do this then everything works? This pref should normally be on by default I believe.
I used wireshark to query the connection packets. The cameras all send instant video to firefox, but the 95 version can be displayed normally, but the 96 version can't be displayed.
This doesn't sound related to local camera but to video reception over p2p, specifically video decoding and specifically from the server https://live.amaryllo.eu. Can you confirm your local camera(s) otherwise work here or here?
Could you do me a favor and run the STRs in the latest nightly build and look at the "RTP stats" (it should have a line for "Decoder" that shows which video codec is used) in about:webrtc? If you could dump that line here that would be useful. Maybe compare to 95.
I don't have access to test with https://live.amaryllo.eu but I'm able to test reception of VP8, H264 and VP9 using https://mozilla.github.io/webrtc-landing/pc_test.html and the about:webrtc output, and they all appear to work (even H264 which was unexpected since I have media.navigator.mediadatadecoder_h264_enabled
set to false!)
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #1)
This doesn't sound related to local camera but to video reception over p2p, specifically video decoding and specifically from the server https://live.amaryllo.eu. Can you confirm your local camera(s) otherwise work here or here?
The camera is not a local camera, it's a webcam, so I can't use it on this machine.
Could you do me a favor and run the STRs in the latest nightly build and look at the "RTP stats" (it should have a line for "Decoder" that shows which video codec is used) in about:webrtc? If you could dump that line here that would be useful. Maybe compare to 95.
I use nightly version (2021-10-31), RTP stats have Decoder line. But use nightly version (2021-11-01), RTP stats have not Decoder line.
So it should be because there is no Decoder, the video cannot be displayed.
I don't have access to test with https://live.amaryllo.eu but I'm able to test reception of VP8, H264 and VP9 using https://mozilla.github.io/webrtc-landing/pc_test.html and the about:webrtc output, and they all appear to work (even H264 which was unexpected since I have
media.navigator.mediadatadecoder_h264_enabled
set to false!)
Updated•3 years ago
|
Comment 3•3 years ago
|
||
(In reply to gama.l from comment #2)
Could you do me a favor and run the STRs in the latest nightly build and look at the "RTP stats" (it should have a line for "Decoder" that shows which video codec is used) in about:webrtc? If you could dump that line here that would be useful. Maybe compare to 95.
I use nightly version (2021-10-31), RTP stats have Decoder line. But use nightly version (2021-11-01), RTP stats have not Decoder line.
So it should be because there is no Decoder, the video cannot be displayed.
Sorry that may be an unrelated old bug in about:webrtc. I should have clarified, could you please test in a 99.0a1 (2022-02-16) or newer nightly? We added codec stats to the "Decoder:" and "Encoder:" line in about:webrtc only last week in bug 1754611, and I'm curious what they show.
It might also help resolve this quicker if you could hit the "Save Page" button in about:webrtc and email it to me.
Comment 4•3 years ago
|
||
Set release status flags based on info from the regressing bug 1654112
Updated•3 years ago
|
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)
(In reply to gama.l from comment #2)
Could you do me a favor and run the STRs in the latest nightly build and look at the "RTP stats" (it should have a line for "Decoder" that shows which video codec is used) in about:webrtc? If you could dump that line here that would be useful. Maybe compare to 95.
I use nightly version (2021-10-31), RTP stats have Decoder line. But use nightly version (2021-11-01), RTP stats have not Decoder line.
So it should be because there is no Decoder, the video cannot be displayed.Sorry that may be an unrelated old bug in about:webrtc. I should have clarified, could you please test in a 99.0a1 (2022-02-16) or newer nightly? We added codec stats to the "Decoder:" and "Encoder:" line in about:webrtc only last week in bug 1754611, and I'm curious what they show.
It might also help resolve this quicker if you could hit the "Save Page" button in about:webrtc and email it to me.
I have tested the nightly 99.0a1 (2022-02-16) version and saved the about:webrtc page, may I ask how can I send you an email?
Updated•3 years ago
|
Updated•3 years ago
|
This page is config:webrtc page in firefox nightly v99.0a1(2022-02-16) version.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
(In reply to gama.l from comment #5)
I have tested the nightly 99.0a1 (2022-02-16) version and saved the about:webrtc page, may I ask how can I send you an email?
Sorry, it's my 3 initials @ mozilla.com
Excuse me, is there any new progress on this issue? Thanks.
Comment 9•3 years ago
|
||
The severity field is not set for this bug.
:mjf, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 10•3 years ago
|
||
Ah sorry I missed that you uploaded logs in comment 6! — It looks like you've munged the local SDP to only offer reception of H264:
m=video 60456 UDP/TLS/RTP/SAVPF 97
a=recvonly
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtpmap:97 H264/90000
...and then at the same time disabled H264 decoding:
User Set WebRTC Preferences
media.navigator.mediadatadecoder_h264_enabled: false
My questions: Why are you doing this, and what are you expecting Firefox to do in this situation? And why did this work in 95?
Comment 11•3 years ago
|
||
And why did this work in 95?
I suppose this question is for us. Byron, do you agree with my analysis, or can you help explain why this worked in 95? Am I misunderstanding what the media.navigator.mediadatadecoder_h264_enabled
pref does?
Comment 12•3 years ago
|
||
Am I misunderstanding what the
media.navigator.mediadatadecoder_h264_enabled
pref does?
It looks like I am. From bug 1505284 comment 0 it looks like the pref just switches what backend we use to decode.
If so, we appear to have regressed decoding some forms of H264 without this pref set (though H264 in webrtc-landing WFM in comment 1). John is that correct?
Comment 13•3 years ago
|
||
I don't think that media.navigator.mediadatadecoder_h264_enabled is what enables H264 in general. In fact, I don't see us actually using this pref anywhere:
I wonder if we inadvertently lost the code that used this. I'm going to do some archaeology.
Comment 14•3 years ago
|
||
Ok, this is bizarre. modules/libpref/init/StaticPrefList.h does not exist in the repo anymore, but hg log -v --remove modules/libpref/init/StaticPrefList.h does not yield any changesets that removed or moved it...
Comment 15•3 years ago
|
||
Comment 16•3 years ago
|
||
So, the profile-level-id=4d8028 in the remote SDP is a bit unusual. I wonder if libwebrtc barfs on that now?
Reporter | ||
Comment 17•3 years ago
|
||
Because in the previous version, there was a problem that the video could not be decoded and displayed, and then setting media.navigator.mediadatadecoder_h264_enabled to false can be successful, so subsequent versions will use this setting.
In addition, the images transmitted by our video camera only accept the transmission of H264, so the information of SDP will be reassembled, and the information that is not H264 will be deleted.
Reporter | ||
Comment 18•3 years ago
|
||
Are there any new developments or discoveries, thank you
Reporter | ||
Comment 19•3 years ago
|
||
Excuse me, is there any new information?
In addition, it is necessary to update the adapter.js used by sdp, because the version downloaded in 2016 is currently used.
Thank you.
Updated•2 years ago
|
Reporter | ||
Comment 20•2 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #16)
So, the profile-level-id=4d8028 in the remote SDP is a bit unusual. I wonder if libwebrtc barfs on that now?
The camera changed the profile-level-id of sdp from 4d8028 to 4d0028, but the previous version of Nightly 2021-10-31 changed from success to failure. Later versions were also unsuccessful.
I tested the Nightly 2022-03-01 version once successfully, but after several tests, it failed.
You can test the live.amaryllo.eu website, click on the camera icon, enter iCRa0aw6m for the ID, and 6A7PJT6Q for the passcode.
Thank you.
Comment 21•2 years ago
|
||
Could you try 42e01f, which is the standard thing?
![]() |
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 22•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•2 years ago
|
Comment 23•2 years ago
|
||
This still happens with Firefox 104.0.2 in Linux (Ubuntu 22.04.1) here. There is some more information at https://github.com/nextcloud/spreed/issues/6802:
- my report: https://github.com/nextcloud/spreed/issues/6802#issuecomment-1041409022
- some debugging of someone who knows more about this: https://github.com/nextcloud/spreed/issues/6802#issuecomment-1201937076 (+ info that it also happens with jitsi)
Comment 24•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:mjf, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 25•2 years ago
|
||
Byron - any thoughts from comment 23?
Comment 26•2 years ago
|
||
(In reply to RH from comment #23)
This still happens with Firefox 104.0.2 in Linux (Ubuntu 22.04.1) here. There is some more information at https://github.com/nextcloud/spreed/issues/6802:
- my report: https://github.com/nextcloud/spreed/issues/6802#issuecomment-1041409022
- some debugging of someone who knows more about this: https://github.com/nextcloud/spreed/issues/6802#issuecomment-1201937076 (+ info that it also happens with jitsi)
Is there a Talk instance where we can attempt to reproduce this issue?
Comment 27•1 year ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Description
•