Summary
The stdpixel-based detection threshold assumes per-pixel temporal noise survives into the FF stack. Video paths that smooth it — software H.264 re-encoding, and some IP-camera encoders — break that assumption: stdpixel drops well below the residual maxpixel noise floor, the k1·stdpixel + j1 threshold falls under that floor, the white-ratio guard in checkWhiteRatio() rejects every time window, and detection silently yields zero meteors all night.
Evidence (Pi 5 / IMX296, re-encoded RTSP stream, clear night)
- median
stdpixel ≈ 3, but median maxpixel − avepixel ≈ 26 ADU
- at default
k1=3.5, j1=12: ~68 % of the frame passes threshold → the 5 % white-ratio guard aborts every time window → 0 KHT lines → 0 meteors
- a saturated, unambiguous meteor (≈7.2°, 0.80 s, ≈9 °/s, perfectly linear) logged
detected meteors: 0 live; the same FF reprocessed with j1=30 (whole-frame white → ~2.2 %) detects it correctly
- control: on cloudy/twilight frames the background statistics rise, the threshold rises with them, and detection "works" — which is exactly why the failure looks intermittent and goes unnoticed
The failure is also completely silent at INFO level (see companion PR to surface it).
Why it matters
Pi + CSI-camera stations that bridge to RTSP (no hardware H.264 encoder on the Pi 5) are a growing population, and any such re-encoded path is susceptible. An affected station uploads nightly but detects nothing on clear nights, with no error to indicate why.
Proposed directions (for discussion)
- Adaptive threshold — when the white ratio exceeds the limit, raise
j1 (or scale the threshold) and retry rather than aborting, so detection recovers without per-station tuning.
- Warn + document — surface the abort (companion PR) and document recommended
k1/j1 for encoder-fed stations.
- Robust noise estimate — derive the threshold from a noise measure less sensitive to the encoder's temporal smoothing.
Happy to contribute the adaptive-threshold change (1) if there's appetite for it.
Summary
The
stdpixel-based detection threshold assumes per-pixel temporal noise survives into the FF stack. Video paths that smooth it — software H.264 re-encoding, and some IP-camera encoders — break that assumption:stdpixeldrops well below the residualmaxpixelnoise floor, thek1·stdpixel + j1threshold falls under that floor, the white-ratio guard incheckWhiteRatio()rejects every time window, and detection silently yields zero meteors all night.Evidence (Pi 5 / IMX296, re-encoded RTSP stream, clear night)
stdpixel≈ 3, but medianmaxpixel − avepixel≈ 26 ADUk1=3.5, j1=12: ~68 % of the frame passes threshold → the 5 % white-ratio guard aborts every time window → 0 KHT lines → 0 meteorsdetected meteors: 0live; the same FF reprocessed withj1=30(whole-frame white → ~2.2 %) detects it correctlyThe failure is also completely silent at INFO level (see companion PR to surface it).
Why it matters
Pi + CSI-camera stations that bridge to RTSP (no hardware H.264 encoder on the Pi 5) are a growing population, and any such re-encoded path is susceptible. An affected station uploads nightly but detects nothing on clear nights, with no error to indicate why.
Proposed directions (for discussion)
j1(or scale the threshold) and retry rather than aborting, so detection recovers without per-station tuning.k1/j1for encoder-fed stations.Happy to contribute the adaptive-threshold change (1) if there's appetite for it.