webrtcbin, h264 profiles and iOS?

Trey Hutcheson trey.hutcheson at gmail.com
Sat Mar 27 15:37:30 UTC 2021


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210327/ebae65e3/attachment.htm>


More information about the gstreamer-devel mailing list