Ring camera ingestion negotiates PLI-only (no RTX), causing visible corruption on Rebroadcast/RTSP path — browser Play session gets RTX and looks clean

[stueastwell]

Hi,

I've been debugging persistent H.264 corruption on a Ring Doorbell's RTSP rebroadcast (consumed by Frigate) for several days, and traced it to what looks like a specific SDP negotiation gap. Posting here since I couldn't find a matching existing issue/discussion.

Setup: Scrypted on TrueNAS, Ring Doorbell (mains-powered), Rebroadcast plugin feeding go2rtc/Frigate over RTSP. RTSP Parser set to "FFmpeg (TCP)".

Symptom: Frigate's live view (via the Rebroadcast RTSP stream) shows persistent H.264 corruption — vertical stripe artifacts, concealing N DC/AC/MV errors in I frame, corruption present from the start of the session and persisting throughout, not just at connection start. Meanwhile, Scrypted's own Play (WebRTC) view of the same camera looks clean.

What I ruled out: WiFi/LAN quality (wired/mains, tested guest+main network, both channels), Scrypted's Prebuffer setting, and the specific Ring media server (corruption persisted across at least two different assigned RMS servers, same region eu-south-2). Confirmed via tcpdump/tshark that Play's WebRTC session is a genuine peer-to-peer connection direct from my browser to Ring's cloud (never touches the Scrypted host) — so it's not that Play is "cheating" by reading from the same ingested stream Rebroadcast uses.

What I found: Comparing the SDP offer/answer for each session:

Scrypted's WebRTC Plugin offer to Ring (video, ingestion for Rebroadcast):

a=rtcp-fb:99 transport-cc
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb

No apt=99 / RTX payload type declared in the offer.

Ring's answer:

a=rtcp-fb:99 nack pli

Only PLI is granted — no plain NACK-based retransmission, no RTX.

By contrast, in a simultaneous browser Play session (captured via chrome://webrtc-internals), Ring granted real RTX-based retransmission — the inbound video stream showed an active rtxSsrc, and stats showed 1,035 NACK-triggered retransmissions successfully recovering lost packets over a ~266s session (final reported packet loss: 0%). The Rebroadcast/ingestion session has no equivalent recovery mechanism — PLI just requests a full keyframe, so any packet lost between keyframes shows up as visible corruption until the next one arrives.

I know Scrypted's WebRTC plugin is built on werift, which does support RTX generally, so this doesn't look like a hard library limitation.

Question: Is this a known limitation of how @scrypted/webrtc/@scrypted/ring construct the SDP offer for camera-import/ingestion (vs. the viewer-facing use case)? Is there a way to get an RTX payload type included in the ingestion offer, or is this a Ring-side policy that only grants RTX to certain client types? Happy to provide full SDP logs / webrtc-internals dumps if useful.

Scrypted version: v0.147.0

Any help with this would be much appreciated.

Thanks in advance