webrtcbin, h264 profiles and iOS?

[Trey Hutcheson]

Here's my situation: 

* remote peer (ios) produces an sdp offer with h264. I negotiate with webrtcbin, and the remote peer sends in video.

* a second peer (ios) joins, and my media server creates a new webrtcbin instance, and depayloads/repayloads the h264 from the first webrtcbin to the 2nd

* webrtcbin instance 2 creates an offer. 

* the 2nd remote peer rejects the offer with the message: "Failed to set remote offer sdp: Failed to set remote video description send parameters'.'

From what I've read, I *believe* the 2nd peer is rejecting the offer because of the h264 profile offered by webrtcbin.

The original offer from the video producing peer looks like this (relevant parameters):

a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

And then when webrtcbin produces the offer for the second peer, it looks like this:

a=rtpmap:98 H264/90000
a=rtcp-fb:98 nack pli
a=fmtp:98 packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==

So the video sending peer offered profile level 42e01f. But for the same h264 stream, webrtcbin offered profile level 42001f.

What's going on here? What is the correct behavior?

Chrome accepts the offer and plays the video just fine. Safari does not. 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Trey Hutcheson]

Ok so it appears Safari is in fact rejecting the profile 42001f. 

When the first webrtcbin instance fires the pad-added signal for the src pad, the caps show a profile-level-id of 42e01f. We then repayload the stream (queue ! rtph264depay ! h264parse config-interval=-1 ! rtph264pay) on its way to the 2nd webrtcbin instance, and the caps on the sink pad end up having a profile-level-id of 42001f.

Is it h264parse that's modifying the caps? Is there any way to preserve the profile-level-id here? 

On Sat, Mar 27, 2021 at 10:37 AM Trey Hutcheson <[hidden email]> wrote:

Here's my situation: 

* remote peer (ios) produces an sdp offer with h264. I negotiate with webrtcbin, and the remote peer sends in video.

* a second peer (ios) joins, and my media server creates a new webrtcbin instance, and depayloads/repayloads the h264 from the first webrtcbin to the 2nd

* webrtcbin instance 2 creates an offer. 

* the 2nd remote peer rejects the offer with the message: "Failed to set remote offer sdp: Failed to set remote video description send parameters'.'

From what I've read, I *believe* the 2nd peer is rejecting the offer because of the h264 profile offered by webrtcbin.

The original offer from the video producing peer looks like this (relevant parameters):

a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

And then when webrtcbin produces the offer for the second peer, it looks like this:

a=rtpmap:98 H264/90000
a=rtcp-fb:98 nack pli
a=fmtp:98 packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==

So the video sending peer offered profile level 42e01f. But for the same h264 stream, webrtcbin offered profile level 42001f.

What's going on here? What is the correct behavior?

Chrome accepts the offer and plays the video just fine. Safari does not. 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel