RTP Server and rtpjitterbuffer fails w/ Seg Fault

Chris Hallinan challinan at gmail.com
Wed Mar 16 00:32:58 UTC 2022

Hi Team,

GStreamer  newbie here!!  My application is a remote control for a
pseudo-digital HF radio.  Mac OS 10.15.7, GST top-of-tree + 1.20 binary

I have a pipeline pair (client/server) including a jitter buffer that works
fantastic using UDP/RTP only (ie not RTSP.)  Nice audio but it's not

Thanks to Nirbheek I found RTSP Server.  Using a similar pipeline, without
jitterbuffer, my compiled Rtsp Server (based on the example code) works
fine, but latency and fidelity is poor.

I tried introducing the rtpjitterbuffer but this seg faults my rtsp server
app.  After several days of debugging through the code, I'm beginning to
suspect that the GStreamer RTSP server code expects the rtp{x}pay to be the
final element in the pipeline.

On the server side, this works (but with bad latency)

"osxaudiosrc device=66! audio/x-raw, rate=48000 ! audioresample !
audio/x-raw, rate=44100 ! rtpL16payname=pay0"

However, adding the rtpjitterbuffer after the payloader fails with Seg
Fault 11:

"osxaudiosrc device=66! audio/x-raw, rate=48000 ! audioresample !
audio/x-raw, rate=44100 ! rtpL16payname=pay0 ! rtpjitterbuffer mode=synced"

Looks like the code is trying to create a ghost pad on rtpL16pay, but the
src pad is already linked (presumably) to the rtpjitterbuffer, and
therefore gst_rtsp_media_create_stream() fails on this line:

streampad = gst_ghost_pad_new (name, pad); (rtsp-media.c:2434)

because the pad is already linked (presumably) to the rtpjitterbuffer.

This results in a Seg Fault shortly thereafter b/c streampad is 0x0.

Is my analysis anywhere near on target?  Is this a supported operation?
Suggestions/comments welcome!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220315/07885d95/attachment.htm>

More information about the gstreamer-devel mailing list