GStreamer-devel

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

classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Trey Hutcheson
Reply | Threaded
Open this post in threaded view
♦
♦
|

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
 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Trey Hutcheson
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Trey Hutcheson
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 <[hidden email]> 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
 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Trey Hutcheson
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page