Problem
Stream quality (640x360, 10 fps, 700k) is effectively hardcoded. When the uplink can't sustain the bitrate, SRT drops late packets and the viewer gets artifacts or freezes. There is no graceful degradation and no way to configure a lighter profile for sites on weak 4G links.
Two related findings:
- Latent config bug:
start_stream reads width, height, fps, conf from STREAMS[camera_ip] (routes_stream.py:77-80), but STREAMS is built in config.py with only input_url and output_url. These keys can never be set, so the defaults always apply. Per-camera quality config silently doesn't exist.
- SRT latency unit: ffmpeg's
latency option is in microseconds, so SRT_LATENCY = 50 means 50 µs (rounded to 0, libsrt falls back to its 120 ms default). The intended value was presumably 50 ms, which would be too low anyway for 4G links (rule of thumb: 3-4x RTT).
Proposal
- Propagate quality keys (
width, height, fps, bitrate) from credentials.json into STREAMS so per-camera profiles work.
- Accept optional quality overrides on
POST /stream/start_stream (e.g. bitrate, fps, or a profile=low|high shortcut) so the platform can pick per session.
- Fix
SRT_LATENCY to an explicit microsecond value (~300000).
- Optional follow-up: switch restream mode to
-c:v copy (camera already outputs H.264, re-encoding wastes Pi CPU) and control bitrate at the source via the camera API.
Out of scope: automatic ABR (HLS ladder or congestion-based encoder restart). Can be discussed later if static profiles prove insufficient.
Problem
Stream quality (640x360, 10 fps, 700k) is effectively hardcoded. When the uplink can't sustain the bitrate, SRT drops late packets and the viewer gets artifacts or freezes. There is no graceful degradation and no way to configure a lighter profile for sites on weak 4G links.
Two related findings:
start_streamreadswidth,height,fps,conffromSTREAMS[camera_ip](routes_stream.py:77-80), butSTREAMSis built inconfig.pywith onlyinput_urlandoutput_url. These keys can never be set, so the defaults always apply. Per-camera quality config silently doesn't exist.latencyoption is in microseconds, soSRT_LATENCY = 50means 50 µs (rounded to 0, libsrt falls back to its 120 ms default). The intended value was presumably 50 ms, which would be too low anyway for 4G links (rule of thumb: 3-4x RTT).Proposal
width,height,fps,bitrate) fromcredentials.jsonintoSTREAMSso per-camera profiles work.POST /stream/start_stream(e.g.bitrate,fps, or aprofile=low|highshortcut) so the platform can pick per session.SRT_LATENCYto an explicit microsecond value (~300000).-c:v copy(camera already outputs H.264, re-encoding wastes Pi CPU) and control bitrate at the source via the camera API.Out of scope: automatic ABR (HLS ladder or congestion-based encoder restart). Can be discussed later if static profiles prove insufficient.