<div dir="ltr">And this may be an issue elsewhere. It looks like it's not the profile-level-id. It may be some sdp munging downstream. I'll update as soon as I confirm</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 16, 2021 at 9:00 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 the situation:<div>Peer 1 > media server (gstreamer) > Peer 2</div><div>* Peer 1 creates an offer that contains h264.</div><div>* When the media arrives and webrtcbin fires the pad-added signal, the media server "repayloads" the stream (queue ! rtph264depay ! h264parse config-interval=-1 ! rtph264pay pt={}), and connects to another webrtcbin instance, and creates a new offer</div><div>* the offer is presented to the second remote peer, and ultimately rejected, because it doesn't understand the profile-level-id</div><div><br></div><div>This is in chrome, but I've seen the same behavior with safari (though the profiles are different).</div><div><br></div><div>Original video offer sdp fragment:</div><div>a=rtpmap:102 H264/90000<br>a=rtcp-fb:102 goog-remb<br>a=rtcp-fb:102 transport-cc<br>a=rtcp-fb:102 ccm fir<br>a=rtcp-fb:102 nack<br>a=rtcp-fb:102 nack pli<br>a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f<br></div><div><br></div><div>Caps observed on the pad-added signal:</div><div>Caps("application/x-rtp, media=(string)video, payload=(int)102, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)42001f, level-asymmetry-allowed=(string)1, packetization-mode=(string)1, rtcp-fb-nack-pli=(boolean)true, rtcp-fb-ccm-fir=(boolean)true, ssrc=(uint)4118433928")</div><div><br></div><div>2nd offer created by webrtcbin, after "repayloading" the stream:</div>a=rtpmap:102 H264/90000<br>a=rtcp-fb:102 nack pli<br><div>a=fmtp:102 profile-level-id=42c015;packetization-mode=1sprop-parameter-sets=Z0LAFYyNQKD5APCIRqA=,aM48gA==</div><div><br></div><div>And outbound caps:</div><div>Caps("application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c015, sprop-parameter-sets=(string)\"Z0LAFYyNQKD5APCIRqA\\=\\,aM48gA\\=\\=\", payload=(int)102, ssrc=(uint)1172136079, timestamp-offset=(uint)1112621284, seqnum-offset=(uint)402")</div><div><br></div><div>Notice the original profile-level-id was 42001f, but the new profile-level-id was 42c015</div><div><br></div><div>In the case of safari (M1 mac mini) on both ends, the original profile level id was 640c1f, but the repayloaded profile-level-id was 64001f</div><div> <br></div></div>
</blockquote></div>