WebRTCBin: regression from 1.16.2 to 1.18.4?

[Matthew Waters]

sprop-parameter-sets should not actually be necessary to put in the SDP
at all as the SPS/PPS should be sent in-band in the stream.

From memory, the H.264 input (byte-stream/avc, alignment configuration)
into rtph264pay determines what caps rtph264pay would output with
respect to sprop-paramter-sets or other fields.

Cheers
-Matt

On 15/12/21 08:59, Florian Echtler wrote:
> 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
>

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