WebRTCBin: regression from 1.16.2 to 1.18.4?

Florian Echtler floe at butterbrot.org
Tue Oct 5 19:10:13 UTC 2021


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
_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/20211005/2726e84a/attachment.sig>


More information about the gstreamer-devel mailing list