webrtcbin, h264 profiles and iOS?

Trey Hutcheson trey.hutcheson at gmail.com
Sun Mar 28 14:01:15 UTC 2021


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 <trey.hutcheson at gmail.com>
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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210328/5c3e78a7/attachment.htm>


More information about the gstreamer-devel mailing list