mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 03:01:21 +02:00
maziggy
9fc2c6df2d
An external camera could pass the connection test, play in VLC, and show a black live view that gave up after a few seconds. The two RTSP paths were not asking ffmpeg for the same thing. The one-shot _capture_rtsp_frame passed no probe settings and got ffmpeg's defaults; _stream_rtsp hard-coded -probesize 32 -analyzeduration 0. Thirty-two bytes is enough for a camera that puts its H.264 parameters in the SDP, and not enough for one that sends them in-band a moment later -- a WebRTC source republished through go2rtc, in the reporter's case. ffmpeg then starts no decoder and yields nothing at all, which is why the test button kept passing while the live view stayed black. Those settings were never chosen for external cameras: they arrived with the P2S TLS proxy (#661) as fast-start tuning for the printer camera path, where the source is a known Bambu model, and were copied here in the same commit. This path has no model to tune against and belongs on the defaults, which are a ceiling rather than a wait -- a camera that announces itself in the first packet still starts as fast as it did. Drop the probe cap from _stream_rtsp. Keep -fflags nobuffer and -flags low_delay, which bear on how long ffmpeg sits on frames it already has rather than how long it may look before it has any. Leave _capture_rtsp_frame and the per-model printer profiles alone. Tests pin the absence of both flags, the presence of the low-latency ones, and the property underneath: both RTSP paths must probe alike, or passing the test button again means nothing about the live view. The ffmpeg subprocess fakes move to backend/tests/_fixtures/external_camera.py so the SSRF suite and this one share one definition.