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

[Trey Hutcheson]

Ok so the actual problem is downstream from webrtcbin; there's some sdp
munging that happens later and that was causing failures.


On Tue, Feb 16, 2021 at 10:41 AM Trey Hutcheson <trey.hutcheson at gmail.com>
wrote:

> 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
>
> On Tue, Feb 16, 2021 at 9:00 AM Trey Hutcheson <trey.hutcheson at gmail.com>
> wrote:
>
>> 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/20210217/08044ec5/attachment.htm>