Rtspsrc: EOS when server changes RTP SSRC mid‑RTSP session (Parrot Anafi drone) – can it follow the new SSRC?

General Discussion
1

Hi,

I have an RTSP client built with GStreamer talking to a Parrot Anafi USA drone, and I am trying to keep the live video stream running while triggering still photos via a separate control channel (Parrot Olympe API).

Setup

  • Client: Jetson AGX Orin, JetPack 6 (Ubuntu 22.04, GStreamer 1.20.x from NVIDIA packages

  • RTSP server: Parrot Anafi USA via SkyController 4 Black

  • RTSP URL: rtsp://192.168.53.1/live

  • Pipeline (works fine until I take a photo):

gst-launch-1.0 -v \
  rtspsrc location="rtsp://192.168.53.1/live" ! \
  rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! \
  autovideosink sync=false

On another process I control the drone with Python/Olympe.
As soon as the still photo is taken, the GStreamer pipeline prints:

Got EOS from element pipeline0
Execution ended after 0:00:09.xxxxxx
Setting pipeline to NULL
Freeing pipeline

So from the client’s perspective, rtspsrc emits EOS and the pipeline stops.

According to Parrot’s explanation and a Wireshark trace they provided for the Anafi family, the RTSP session itself is not torn down when a photo is taken or when switching video/photo modes:

  • RTSP session ID stays the same for the whole time (same Session: header)

  • RTP ports stay the same

  • The RTP SSRC changes whenever the camera pipeline is reconfigured (switch video→photo, change framerate/resolution, trigger photo, etc.) Parrot Developers Forum

  • On the H.264 side a new SPS/PPS sequence is started when the camera configuration changes

So from an RTSP point of view it is a single, long‑lived session; only the SSRC (and H.264 parameter sets) change mid‑stream. In the forum there is an explicitly mention that “the GStreamer stream most likely breaks because of the change in SSRC that probably triggers stopping the GStreamer RTP element”.

Does rtspsrc support mid‑stream SSRC changes?

Is there any property or mode where rtspsrc (and its internal rtpbin/jitterbuffer) can automatically accept a new SSRC on an existing session instead of ending the stream with EOS when the SSRC changes?

If not, what is the recommended pattern?

Should I:

Catch EOS on the bus, cycle the whole pipeline through READY/NULL and back to PLAYING to force rtspsrc to reconnect (as is often suggested for RTSP reconnection),
GStreamer Discourse

Or is there a way to only tear down and recreate the RTSP/RTP part while keeping the downstream decode/processing chain intact?

Do I need to drop rtspsrc and use lower‑level RTP elements?

For example: udpsrc + rtpbin + rtpssrcdemux to explicitly handle new SSRCs, using signals like new-ssrc-pad to switch or relink the downstream decoder when the SSRC changes.

If this is the right approach, is there any example or best‑practice for handling an RTP source that keeps the same ports but changes SSRC mid‑session?