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

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!)

(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.

Set release status flags based on info from the regressing bug 1654112

(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？

This page is config:webrtc page in firefox nightly v99.0a1(2022-02-16) version.

(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.

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit auto_nag documentation.

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?

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?

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?

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:

https://searchfox.org/mozilla-central/search?q=media.navigator.mediadatadecoder_h264_enabled&case=true&path=

I wonder if we inadvertently lost the code that used this. I'm going to do some archaeology.

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...

Ok, found it: https://searchfox.org/mozilla-central/rev/d6850ecec549f9a1b10dd8ec8823db3791cf81fd/dom/media/webrtc/libwebrtcglue/MediaDataCodec.cpp#40

So, the profile-level-id=4d8028 in the remote SDP is a bit unusual. I wonder if libwebrtc barfs on that now?

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.

Are there any new developments or discoveries, thank you

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.

(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.

Could you try 42e01f, which is the standard thing?

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

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)

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.

Byron - any thoughts from comment 23?

(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?

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.