<div dir="ltr">Ok so it appears Safari is in fact rejecting the profile 42001f. <div><br></div><div>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.</div><div><br></div><div>Is it h264parse that's modifying the caps? Is there any way to preserve the profile-level-id here? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 27, 2021 at 10:37 AM Trey Hutcheson <<a href="mailto:trey.hutcheson@gmail.com">trey.hutcheson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Here's my situation: <div>* remote peer (ios) produces an sdp offer with h264. I negotiate with webrtcbin, and the remote peer sends in video.</div><div>* 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</div><div>* webrtcbin instance 2 creates an offer. </div><div>* the 2nd remote peer rejects the offer with the message: "Failed to set remote offer sdp: Failed to set remote video description send parameters'.'</div><div><br></div><div>From what I've read, I *believe* the 2nd peer is rejecting the offer because of the h264 profile offered by webrtcbin.</div><div><br></div><div>The original offer from the video producing peer looks like this (relevant parameters):</div><div>a=rtpmap:98 H264/90000<br>a=rtcp-fb:98 goog-remb<br>a=rtcp-fb:98 transport-cc<br>a=rtcp-fb:98 ccm fir<br>a=rtcp-fb:98 nack<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1<br></div><div><br></div><div>And then when webrtcbin produces the offer for the second peer, it looks like this:</div><div>a=rtpmap:98 H264/90000<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==<br></div><div><br></div><div>So the video sending peer offered profile level 42e01f. But for the same h264 stream, webrtcbin offered profile level 42001f.</div><div><br></div><div>What's going on here? What is the correct behavior?</div><div><br></div><div>Chrome accepts the offer and plays the video just fine. Safari does not. </div><div><br></div><div><br></div></div>
</blockquote></div>