WebRTCBin: regression from 1.16.2 to 1.18.4?

[Florian Echtler]

Hello again,

I've gone back to try and debug this issue, and discovered that the problem is 
actually related to having one peer on 1.16, and one on 1.18. Everything works 
when both peers are on the same version.

So I've had another look at the generated SDPs, and spotted one single 
difference apart from randomly generated stuff like SSRCs.

The first video section created as offer by 1.16 contains the following line:

a=fmtp:96 
packetization-mode=1;profile-level-id=42c016;sprop-parameter-sets=Z0LAFtoCgL/lwFqDAILSgAAAAwCAAAAPR4sXUA==,aM48gA==

The first video section created as offer by 1.18 contains the following line:

a=fmtp:96 
packetization-mode=1;profile-level-id=42c016;sprop-parameter-sets=Z0LAFtoCgL/lwFqDAwNSgAAAAwCAAAAPR4sXUA==,aM48gA==

It's hard to spot, but the sprop-parameter-sets are minimally different, even 
though the input to webrtcbin should be exactly the same:

1.16 -> Z0LAFtoCgL/lwFqDAILSgAAAAwCAAAAPR4sXUA==,aM48gA==
1.18 -> Z0LAFtoCgL/lwFqDAwNSgAAAAwCAAAAPR4sXUA==,aM48gA==
                          ^^

I tried to parse this back into some human-understandable form, but haven't 
found any tool that would actually be able to do this.

Interestingly, however, I've tried the incredibly ugly hack of just 
string-replacing the sprop-parameter-sets before the SDP offer is sent out, and 
that made things work - otherwise, the answer contains "a=recvonly" for the 
first video section, because apparently the sprop-parameter-sets don't match (?)

Coming back to my original question now, can someone decode the SPS to shed some 
light on _why_ this is different between versions? For reference, the pipeline 
feeding into webrtcbin looks as follows:

x264enc bitrate=600 speed-preset=ultrafast tune=zerolatency key-int-max=15 ! 
video/x-h264,profile=constrained-baseline ! queue max-size-time=100000000 ! 
h264parse ! rtph264pay config-interval=-1 ! 
application/x-rtp,media=video,encoding-name=H264,payload=96 ! webrtcbin.

Are there any known differences between 1.16 and 1.18 for the other elements, 
i.e. x264enc/h264parse/rtph264pay?

Thank you in advance and best regards, Florian

>>>> On 26/9/21 1:18 am, Florian Echtler via gstreamer-devel wrote:
>>>>> Hello everyone,
>>>>>
>>>>> my WebRTC client is running as expected on GStreamer 1.16.2 (Ubuntu
>>>>> 20.04), but exhibits a weird bug on GStreamer 1.18.4 (Debian Bullseye).
>>>>>
>>>>> Specifically, the SDP answer generated on 1.18 contains "a=recvonly"
>>>>> for one of the three video streams (the first one, incidentally). On
>>>>> 1.16, the same code generates an SDP containing "a=sendrecv" for all
>>>>> three streams.
>>>>>
>>>>> I've already tried to explicitly set the transceivers to SENDRECV
>>>>> before requesting an answer, but that doesn't seem to make a
>>>>> difference...
>>>>>
>>>>> Any ideas much appreciated :-)
>>>>>
>>>>> Best regards, Florian

-- 
SENT FROM MY DEC VT50 TERMINAL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20211214/01f04c5b/attachment.sig>