Follow-ups split out of #592 (which fixed _mainv detection to read the SDP go2rtc serves rather than the producer SDP). Neither blocks #592; both are pre-existing.
1. _mainv is blind to a record-from-sub camera's main
_mainv detection now keys on the served SDP, which requires the main to have a steady-state RTSP consumer. Under the default RecordStream::Main policy the recorder provides exactly that. But a camera whose policy records from the sub (RecordStream::Sub) has no persistent consumer of its main — go2rtc dials producers on demand, so the main can be entirely idle. The served verdict is then permanently None, and an fmtp-less HD main on such a camera never gets _mainv, silently.
#592 adds a reconcile debug log ("main-repair enabled but the main has no served-SDP verdict…") so the case is at least observable. A real fix would either (a) briefly dial the main during a pass when the repair is enabled and no verdict exists, or (b) fall back to a positive-only producer verdict (served.or(producer.filter(|&b| b))) so a genuinely fmtp-less producer still flags — while never letting a producer Some(false) unflag (that "producer looks healthy" lie is the exact #592 bug).
2. Sub-side incomplete-fmtp class
_subv detection stays producer-based (it works for the known #483 H.264 class and switching it risks the un-consumed-sub case). But the same class #592 found on the main — an a=fmtp line that is present but incomplete (H.265 missing sprop-vps; the H.264 analog: a=fmtp with no sprop-parameter-sets) — would make go2rtc serve consumers a broken sub SDP while the producer verdict reads "has fmtp." A sub in that state would never get _subv. Pixel-motion consumes most subs continuously, so a served-side (or served-first, producer-fallback) verdict is feasible for subs too.
Suggested approach
Unify on a served-first, producer-fallback-positive-only verdict for both _mainv and _subv, with the on-demand-dial or the observability signal covering cameras with no consumer at all. Keep sdp_video_lacks_fmtp as-is (it already returns the right verdict for any SDP it's handed); this is about which SDP feeds it.
Area: services/api go2rtc reconcile (stream_served_video_lacks_fmtp, resolve_needs_subv).
Follow-ups split out of #592 (which fixed
_mainvdetection to read the SDP go2rtc serves rather than the producer SDP). Neither blocks #592; both are pre-existing.1.
_mainvis blind to a record-from-sub camera's main_mainvdetection now keys on the served SDP, which requires the main to have a steady-state RTSP consumer. Under the defaultRecordStream::Mainpolicy the recorder provides exactly that. But a camera whose policy records from the sub (RecordStream::Sub) has no persistent consumer of its main — go2rtc dials producers on demand, so the main can be entirely idle. The served verdict is then permanentlyNone, and an fmtp-less HD main on such a camera never gets_mainv, silently.#592 adds a reconcile debug log ("main-repair enabled but the main has no served-SDP verdict…") so the case is at least observable. A real fix would either (a) briefly dial the main during a pass when the repair is enabled and no verdict exists, or (b) fall back to a positive-only producer verdict (
served.or(producer.filter(|&b| b))) so a genuinely fmtp-less producer still flags — while never letting a producerSome(false)unflag (that "producer looks healthy" lie is the exact #592 bug).2. Sub-side incomplete-fmtp class
_subvdetection stays producer-based (it works for the known #483 H.264 class and switching it risks the un-consumed-sub case). But the same class #592 found on the main — ana=fmtpline that is present but incomplete (H.265 missingsprop-vps; the H.264 analog:a=fmtpwith nosprop-parameter-sets) — would make go2rtc serve consumers a broken sub SDP while the producer verdict reads "has fmtp." A sub in that state would never get_subv. Pixel-motion consumes most subs continuously, so a served-side (or served-first, producer-fallback) verdict is feasible for subs too.Suggested approach
Unify on a served-first, producer-fallback-positive-only verdict for both
_mainvand_subv, with the on-demand-dial or the observability signal covering cameras with no consumer at all. Keepsdp_video_lacks_fmtpas-is (it already returns the right verdict for any SDP it's handed); this is about which SDP feeds it.Area: services/api go2rtc reconcile (
stream_served_video_lacks_fmtp,resolve_needs_subv).