WebRTCBin: regression from 1.16.2 to 1.18.4?

Wed Oct 6 04:59:59 UTC 2021

On 6/10/21 06:10, Florian Echtler wrote:
> Hello Matthew,
>
> thanks for the suggestion, but I was hoping I could fix this on my end
> so it's going to work with stock distribution packages.
>
> I've been poring over GStreamer trace logs for both clients, collected
> with GST_DEBUG="*webrtc*:7" and found the following noteworthy
> difference.
>
> In 1.16 (shortened to allow comparison with Meld):
>
> _find_codec_preferences:<webrtcbin> retreiving codec preferences from
> <webrtctransceiver0>
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and application/x-rtp,
> media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)H264, packetization-mode=(string)1,
> profile-level-id=(string)42c016,
> sprop-parameter-sets=(string)"Z0LAFtoCgL/lwFqDAILSgAAAAwCAAAAPR4sXUA\=\=\,aM48gA\=\=",
> payload=(int)96, ssrc=(uint)848784337,
> timestamp-offset=(uint)3689963213, seqnum-offset=(uint)32151,
> a-framerate=(string)15
> _find_codec_preferences:<webrtcbin> retreiving codec preferences from
> <webrtctransceiver1>
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and application/x-rtp,
> media=(string)audio, clock-rate=(int)48000,
> encoding-name=(string)OPUS, sprop-maxcapturerate=(string)48000,
> sprop-stereo=(string)0, payload=(int)97, encoding-params=(string)2,
> ssrc=(uint)1315295987, timestamp-offset=(uint)605079114,
> seqnum-offset=(uint)25626
> _create_answer_task:<webrtcbin> found compatible transceiver (NULL)
> for offer media 1
>
> In 1.18:
>
> _find_codec_preferences:<webrtcbin> retrieving codec preferences from
> <webrtctransceiver0>
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and application/x-rtp,
> media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)H264, packetization-mode=(string)1,
> profile-level-id=(string)42c016,
> sprop-parameter-sets=(string)"Z0LAFtoCgL/lwFqDAwNSgAAAAwCAAAAPR4sXUA\=\=\,aM48gA\=\=",
> payload=(int)96, ssrc=(uint)2830923854,
> timestamp-offset=(uint)548213747, seqnum-offset=(uint)23667,
> a-framerate=(string)15
> _find_codec_preferences:<webrtcbin> retrieving codec preferences from
> <webrtctransceiver1>
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and application/x-rtp,
> media=(string)audio, clock-rate=(int)48000,
> encoding-name=(string)OPUS, sprop-maxcapturerate=(string)48000,
> sprop-stereo=(string)0, payload=(int)96, encoding-params=(string)2,
> ssrc=(uint)2019109917, timestamp-offset=(uint)3902779266,
> seqnum-offset=(uint)22275

I assume this is the one that's meant to match (the only audio caps). 
The difference here is payload=97 (from SDP) vs payload=96 (from
upstream caps).  When answering, you need to ensure that your caps match
what is provided by the offer.

Cheers
-Matt

> _find_codec_preferences:<webrtcbin> retrieving codec preferences from
> <webrtctransceiver2>
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and application/x-rtp,
> media=(string)video, clock-rate=(int)90000,
> encoding-name=(string)H264, packetization-mode=(string)1,
> profile-level-id=(string)42c01f,
> sprop-parameter-sets=(string)"Z0LAH9oBQBbsBagICAoAAAMAAgAAAwA9HjBlQA\=\=\,aM48gA\=\=",
> payload=(int)96, ssrc=(uint)1422565321,
> timestamp-offset=(uint)447117537, seqnum-offset=(uint)8654,
> a-framerate=(string)15
> _find_codec_preferences:<webrtcbin> retrieving codec preferences from
> <webrtctransceiver3>
> _find_codec_preferences:<webrtctransceiver3> Could not find caps for
> mline 3
> _create_answer_task:<webrtcbin> trying to compare application/x-rtp,
> media=(string)audio, payload=(int)97, clock-rate=(int)48000,
> encoding-name=(string)OPUS, encoding-params=(string)2,
> sprop-maxcapturerate=(string)48000, sprop-stereo=(string)0,
> rtcp-fb-nack-pli=(boolean)true and (NULL)
> _create_answer_task:<webrtcbin> Created new transceiver
> <webrtctransceiver4> for mline 1
>
> I hope this is somewhat readable without linewrap - but it in my
> interpretation, it boils down to 1.18 not being able to match the caps
> with an existing transceiver and therefore creating a new one, that's
> then going to be recvonly?
>
> What could be the root cause for this? Caps negotiation happening too
> late?
>
> Best, Florian
>
> On 28/09/2021 05:00, Matthew Waters wrote:
>> Hi,
>>
>> This kinda depends on what exactly you are doing.  Some behaviours
>> that were not explicitly tested for may have worked in 1.16, are not
>> always possible.  The same is also true of git master compared to the
>> 1.18 releases at the time of writing.
>>
>> I would suggest trying to run against GStreamer git master as a first
>> step as some issues have been resolved there.  If that also doesn't
>> work, then we are going to need a full reproducible test case to be
>> able to debug this further.
>>
>> Cheers
>> -Matt
>>
>> 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/20211006/1178f34e/attachment.sig>