WebRTC: "Could not intersect offer direction with transceiver direction" when using H264 with webrtcbin

Application Development
1

Hi all,

I’m using webrtcbin with GStreamer (via Python gi bindings) on Ubuntu 20.04, which comes with GStreamer 1.16.3.
For development reasons, I prefer not to build GStreamer from source but to use the provided packages.

I’m running into a puzzling issue:

When using VP8, everything works as expected — the SDP offer is created with direction sendonly, and media is properly negotiated.

However, when switching the pipeline to use H264, the SDP offer falls back to recvonly, and I see this warning:

WARN webrtcbin gstwebrtcbin.c:2664:_create_answer_task: Could not intersect offer direction with transceiver direction

:small_blue_diamond: H264 pipeline (not working):

webrtcbin name=webrtcbin bundle-policy=max-bundle
v4l2src device={device} !
video/x-raw,width={width},height={height},framerate={fps}/1 !
videoconvert !
x264enc bitrate=90000 sliced-threads=true speed-preset=superfast tune=zerolatency !
video/x-h264,profile=constrained-baseline,level=(string)3.1,packetization-mode=1 !
rtph264pay pt=96 mtu=1400 config-interval=3 ! queue !
application/x-rtp,media=video,encoding-name=H264,payload=96,clock-rate=90000 !
webrtcbin.

:small_blue_diamond: VP8 pipeline (working fine):

webrtcbin name=webrtcbin bundle-policy=max-bundle
v4l2src device={device} !
video/x-raw,width={width},height={height},framerate={fps}/1 !
videoconvert !
vp8enc deadline=1 !
rtpvp8pay !
queue name=q !
application/x-rtp,media=video,encoding-name=VP8,payload=96 !
webrtcbin.

In both cases, I’m emitting add-transceiver(SENDONLY, None) before setting the pipeline to PLAYING.

My guess is that something might be going wrong in the H264 encoding or caps negotiation, which causes webrtcbin to fall back to recvonly. However, I’m not sure how to confirm or fix this.

Since I’m on Ubuntu 20.04 with GStreamer 1.16.3, and prefer not to build from source,
I’m looking for advice on how to solve or work around this issue within these constraints.

Is there a recommended way to ensure the H264 stream is recognized and used correctly by webrtcbin?
Any advice on how to debug this or enforce sendonly with H264 would be greatly appreciated.

Thank you in advance!

2

GStreamer 1.16 is very old for WebRTC usage. I would strongly suggest upgrading as this issue is more than likely fixed.

3

Thank you for your response.
I was able to resolve the issue myself.
I found that in older versions of GStreamer, to send an SDP with sendrecv direction, it needs to be set on the offer side, not the answer side.