nest: request keyframes + advertise sprop-parameter-sets (fix slow/failed consumer opens)

[ajplotkin]

Two small, self-contained improvements to the Nest (nest:) WebRTC source, both gated on FormatName == "nest/webrtc" so nothing else is affected. Together they make Nest cameras usable as a warm RTSP/HLS/consumer source — right now a consumer that joins a Nest stream can wait a long time to start, or fail to determine the video size at all.

1. Request periodic keyframes for the Nest source

OnTrack in pkg/webrtc/conn.go already sends an RTCP PictureLossIndication every 2s to keep the source emitting keyframes — but only for ModePassiveProducer (WHIP/browser push). Nest is an active-pull source (ModeActiveProducer), so it was excluded, and an idle Nest camera lets its keyframe interval drift long. Any consumer that joins mid-GOP (RTSP live view, an on-demand frame.jpeg, MSE) then waits up to a full keyframe interval to start.

This enables the existing keyframe-request loop for the Nest source, gated on FormatName (not the mode) so other ModeActiveProducer WebRTC sources — e.g. battery cameras where a forced 2s IDR would be power/bandwidth hostile — are untouched. PLI is media-plane RTCP, so there's no impact on the Nest/SDM API command quota.

Measured on a Nest doorbell: keyframe interval ~3.3s → ~1.8s; on-demand frame.jpeg grabs drop from several seconds to ~1s.

Also added defer t.Stop() on the ticker (the existing pattern relies on GC of an unreferenced ticker — fine on Go ≥1.23, but explicit is safer).

2. Advertise sprop-parameter-sets in the RTSP SDP

The Nest source's H264 codec FmtpLine comes from Google's WebRTC SDP answer, which carries profile-level-id but no sprop-parameter-sets (WebRTC sends SPS/PPS in-band). The RTSP server copies FmtpLine verbatim into DESCRIBE, so an RTSP consumer gets no SPS/PPS in the SDP and can't determine the video dimensions until an in-band keyframe arrives — which forces a large -probesize for ffmpeg, or fails outright at a small one.

This captures SPS (NAL 7) / PPS (NAL 8) from the incoming H264 RTP in the OnTrack receive loop — handling STAP-A, which is how libwebrtc typically bundles SPS+PPS+IDR — and appends sprop-parameter-sets to the codec FmtpLine once. Every consumer that clones the codec (RTSP) or reads GetParameterSet (MSE/MP4) then benefits. This mirrors what pkg/dvrip already does for H265.

Verified in a live DESCRIBE after the change:

a=fmtp:97 ...;profile-level-id=64001f;sprop-parameter-sets=Z00AIJ...,aO48gA==

Notes / honesty

• Both are gated on FormatName == "nest/webrtc"; no behavior change for any other source.
• Codec.Match ignores FmtpLine, so appending sprop can't affect media matching/renegotiation.
• The FmtpLine append happens on the receive goroutine and is written once; with the keyframe request above, SPS/PPS are captured before any consumer's DESCRIBE. A -race build could flag a consumer connecting during the sub-2s warm-up window; the existing H265 append in pkg/dvrip is unguarded in the same way. Happy to wrap it in a small mutex or capture-into-locals-then-assign if preferred.
• These don't make stream-copy opens instant: ffmpeg still aligns copy output to the next keyframe, so the ~2s keyframe interval (now bounded by patch 1) remains the floor. The win is that the interval is bounded and the SDP is complete, so consumers start predictably instead of hanging.

Context: I'm using this to serve Nest cameras to Apple HomeKit via Homebridge over local RTSP, so a single warm go2rtc stream is shared instead of each viewer opening its own concurrent Google WebRTC stream (Nest enforces a concurrent-stream limit). Both patches were needed to make that path reliable.