Skip to content

Added option to disable manual injection of SPS/PPS for RTSP servers that put them in the SDP (see #3168)#3655

Open
lminiero wants to merge 1 commit into
masterfrom
rtsp-spspps-tweak
Open

Added option to disable manual injection of SPS/PPS for RTSP servers that put them in the SDP (see #3168)#3655
lminiero wants to merge 1 commit into
masterfrom
rtsp-spspps-tweak

Conversation

@lminiero

@lminiero lminiero commented Jul 7, 2026

Copy link
Copy Markdown
Member

In #3168 we added a way for the Janus Streaming plugin to manually inject SPS/PPS NALs in the RTP stream, in case RTSP servers advertised them in the SDP via fmtp attributes. This helped address scenarios where the RTSP server would only put SPS/PPS in a sprop-parameter-sets: WebRTC endoints never look at that, and expect them to be part of the RTP stream, so this manual injection ensured video could be decoded.

This seems to not always work as expected with RTSP cameras that do advertise SPS/PPS via the SDP, but then also send SPS/PPS in the RTP stream. The end result is that, on the WebRTC side, SPS/PPS are duplicated, since there is the one sent by the camera itself, and then the one we add ourselves, which apparently confuses browsers and causes broken video.

This PR is a first attempt to fix this. It adds a new configuration property you can add when creating an RTSP mountpoint (statically or dynamically) called rtsp_fmtp_sps: if the value of that property is "always" (default), then it behaves as it does now, and so if it finds SPS/PPS data in the SDP, it will inject it manually in RTP; if the value is "never", instead, we ignore fmtp data sent in the RTSP SDP.

The property is a string and not a boolean as I want to keep doors open for more flexibility. In the future, for instance, it might be helpful to have something like an "auto" setting, where the plugin stores the SPS/PPS found in the fmtp, but only uses it if it never sees an SPS on the wire. This would allow the code to handle more dynamically scenarios where you don't know in advance what a camera will do. That said, this automatic mode would require more code than I wanted to add now: the existing setting should already help address the main issue in scenarios where the behaviour of the cameras is known.

I haven't tested this yet, so feedback is welcome. In case it works fine and with no regressions, I plan to merge soon and backport to 0.x.

@lminiero lminiero added the multistream Related to Janus 1.x label Jul 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

multistream Related to Janus 1.x

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant