RTP Server and rtpjitterbuffer fails w/ Seg Fault

[Chris Hallinan]

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
install.

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
routable.

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!

Thanks,

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