WebRTCBin: regression from 1.16.2 to 1.18.4?

[Florian Echtler]

Well, that actually did the trick!

I tried to set the rtph264pay element attribute "sprop-parameter-sets" to "", 
but that did not seem to have an effect.

I'm now just removing the entire SPS attribute from the SDP before sending, and 
now both 1.16 and 1.18 can talk to each other and to browser clients without any 
issues.

Thanks for your help!

Best, Florian

On 15/12/2021 12:11, Matthew Waters wrote:
> 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
>>
> 


-- 
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/20211215/db70090f/attachment.sig>