RTP/H264 instability under packet loss can lead to `rtpjitterbuffer` segfault

Application Development
1

Hi all,

We are running a production DeepStream/GStreamer pipeline on GStreamer 1.24.2 and seeing a crash pattern during unstable network conditions on RTSP/H264 feeds.

Environment

- GStreamer: 1.24.2 (Ubuntu packages)

- Stream type: RTSP H264 from MediaMTX to our pipeline

- Relevant chain section: `rtpjitterbuffer → rtph264depay → h264parse → decoder`

What we observe

1. During network instability, we see real RTP sequence loss/gaps (pcap-confirmed).

2. We often see warnings like `Could not decode stream` from both depay and parse.

3. Depay warnings alone are usually non-fatal and stream continues.

4. In crash cases, we see:

- `h264parse` warning: `Could not decode stream` / `Broken bit stream`

- immediately after, `rtpjitterbuffer` receives `SIGSEGV`

So the key symptom is: parser-level broken bitstream warning appears, then jitterbuffer crashes instead of graceful recovery.

Why this seems abnormal

- The same run can contain many decode warnings that do not crash.

- We confirmed packet loss is real, but a segfault still looks like an unsafe path/bug rather than expected behavior.

- We already added upstream RTP sanity filtering to drop obviously bad payload/FU patterns, which reduces risk but does not prove root cause inside GStreamer.

Evidence pattern from recent runs

Across multiple runs, we repeatedly observe:

- orphan FU continuation/end packets

- malformed H264 RTP payloads

- occasional FU timestamp mismatch

- non-monotonic RTP timestamps

These appear during unstable network periods and are the same conditions around the crash windows.

Questions

1. Is this a known issue in/around 1.24.2 where malformed/lossy RTP can lead to `rtpjitterbuffer` segfault?

2. Is there a recommended fix or patch in newer GStreamer versions?

3. Are there specific `rtpjitterbuffer`/`rtph264depay`/`h264parse` properties you recommend to harden recovery under this pattern?

If useful, we can provide:

- pcap around crash windows

- gdb backtrace logs

- exact warning/crash sequence timestamps

2

It’s not a “known issue”, no, and of course shouldn’t happen.

Having said that, 1.24.2 is more than 2 years old, and not even the latest release in the 1.24 series.

I would recommend you see if you can still reproduce this with a more recent GStreamer version (1.28.2 or latest main branch), and if so file a bug in gitlab with all the information you have (pcap etc).

If you want to peruse the commit history of the relevant elements to see if something stands out, you can do so in gitlab, e.g. https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commits/main/subprojects/gst-plugins-good/gst/rtp/gstrtph264depay.c?ref_type=heads (but it’s hard for us to know where the problem is exactly)

3

Not sure how much this can be related to @rambunctiousR’s case, though by curiosity i’ve tried to reproduce it, and some crash also soon happenned with gst 1.28.2 (my setup and build may be unusual, just for case you’d want to investigate that way).
Using debug plugin element breakmydata such as:

Sender:
gst-launch-1.0 videotestsrc ! nvvidconv ! nvv4l2h264enc insert-sps-pps=1 insert-vui=1 idrinterval=15 ! h264parse ! rtph264pay ! queue ! breakmydata probability=0.05 ! udpsink host=127.0.0.1 port=5004

Receiver:

gst-launch-1.0 udpsrc address=127.0.0.1 port=5004 ! queue ! application/x-rtp,encoding-name=H264 ! rtpjitterbuffer ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! queue ! autovideosink -v

<After many correctly handled RTP errors...>

../subprojects/gst-plugins-good/gst/rtpmanager/gstrtpjitterbuffer.c(3747): gst_rtp_jitter_buffer_chain (): /GstPipeline:pipeline0/GstRtpJitterBuffer:rtpjitterbuffer0:
Received invalid RTP payload, dropping
**
GStreamer-RTP:ERROR:../subprojects/gst-plugins-base/gst-libs/gst/rtp/gstrtpbasedepayload.c:942:gst_rtp_base_depayload_handle_buffer: ‘gst_buffer_list_length (priv->hdrext_buffers) == 0’ should be TRUE
Bail out! GStreamer-RTP:ERROR:../subprojects/gst-plugins-base/gst-libs/gst/rtp/gstrtpbasedepayload.c:942:gst_rtp_base_depayload_handle_buffer: ‘gst_buffer_list_length (priv->hdrext_buffers) == 0’ should be TRUE
Aborted (core dumped)
4

Please file an issue work item in gitlab with the reproducer :slightly_smiling_face: