WebRTCBin: regression from 1.16.2 to 1.18.4?

Wed Oct 6 06:29:09 UTC 2021

Hello Matt,

On 06/10/2021 06:59, Matthew Waters wrote:
> 
> 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):
>>
[...]
>>
>> 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.

Thanks for spotting that! But this raises a new question: both sides actually 
use identical code for setting up the pipeline, with this description:

bindesc="webrtcbin name=webrtcbin stun-server=stun://stun.l.google.com:19302 "+\
   "videoconvert name=front   ! "+VENCODER+"payload=96 ! webrtcbin. "+\
   "audioconvert name=audio   ! "+AENCODER+"payload=97 ! webrtcbin. "+\
   "videoconvert name=surface ! "+VENCODER+"payload=98 ! webrtcbin. "

self.bin = Gst.parse_bin_from_description(bindesc,False)

So why is 1.18 suddenly setting the local audio stream to payload ID 96?

Best, Florian

>> _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
>>>
>>>
>>
>>
> 

-- 
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/20211006/610d1818/attachment-0001.sig>