WebRTCBin: regression from 1.16.2 to 1.18.4?
Florian Echtler
floe at butterbrot.org
Tue Dec 14 21:59:17 UTC 2021
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>
More information about the gstreamer-devel
mailing list