Webrtcbin + h264, depayload > parse > payload yields different profile-level-ids

[Trey Hutcheson]

Here's the situation:
Peer 1 > media server (gstreamer) > Peer 2
* Peer 1 creates an offer that contains h264.
* 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
* the offer is presented to the second remote peer, and ultimately
rejected, because it doesn't understand the profile-level-id

This is in chrome, but I've seen the same behavior with safari (though the
profiles are different).

Original video offer sdp fragment:
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102
level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

Caps observed on the pad-added signal:
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")

2nd offer created by webrtcbin, after "repayloading" the stream:
a=rtpmap:102 H264/90000
a=rtcp-fb:102 nack pli
a=fmtp:102
profile-level-id=42c015;packetization-mode=1sprop-parameter-sets=Z0LAFYyNQKD5APCIRqA=,aM48gA==

And outbound caps:
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")

Notice the original profile-level-id was 42001f, but the new
profile-level-id was 42c015

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