Skip to content

Stop serving a stale video frame as if the stream were live - #107

Merged
leandropineda merged 3 commits into
mainfrom
fix/video-frame-staleness
Jul 29, 2026
Merged

Stop serving a stale video frame as if the stream were live#107
leandropineda merged 3 commits into
mainfrom
fix/video-frame-staleness

Conversation

@leandropineda

Copy link
Copy Markdown
Member

Stacked on #106.

get_frame_jpg() re-encoded the last decoded frame for as long as the stream stayed down, so the platform kept showing a frozen image that looked live — the worst failure mode for a safety camera, and it hides the outage from whoever is watching.

Frames older than the new stale_frame_seconds (default 3s, ~3× the age a frame reaches at the default publish rate) are no longer served, so the platform shows no video instead. stale_frame_seconds=None restores the old behaviour.

Behaviour change worth calling out in release notes.

Tests: 1 new case. Suite green, flake8/black clean.

@miguelgarcia miguelgarcia left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment thread inorbit_edge/video.py Outdated
@leandropineda
leandropineda changed the base branch from perf/video-decode-throttle to perf/decode-at-publish-rate July 29, 2026 22:39
@leandropineda
leandropineda force-pushed the fix/video-frame-staleness branch from 150407f to a489c23 Compare July 29, 2026 22:41
@leandropineda
leandropineda changed the base branch from perf/decode-at-publish-rate to main July 29, 2026 22:48
get_frame_jpg() re-encoded the last decoded frame for as long as the
stream stayed down, so the platform kept showing a frozen image that looked
live -- the worst failure mode for a safety camera, and one that hides the
outage from whoever is watching.

Frames older than the new stale_frame_seconds (default 3s, ~3x the age a
frame reaches at the default publish rate) are not served, so the platform
shows no video instead. Pass stale_frame_seconds=None for the previous
behaviour.

Tests: 1 new case in test_video.py.
A fixed 3s window is wrong for a slow rate: at one frame every 10s a
3s-old frame is perfectly normal, so every frame would be withheld and
video would stop entirely.

The window now defaults to three publish periods -- 1s at 10 fps, 3s at 1
fps (unchanged from before), 30s at 0.1 fps -- with a 1s floor so a fast
rate does not withhold frames on ordinary jitter. An explicit
stale_frame_seconds still wins, and float("inf") disables the check.

Tests: 1 new case, 1 updated in test_video.py.
@leandropineda
leandropineda force-pushed the fix/video-frame-staleness branch from a489c23 to ec99000 Compare July 29, 2026 22:51
A stale frame is dropped silently, so an operator sees the video stop with
nothing saying why. Debug level because this is reached on every publish
for as long as the stream stays down; the per-minute capture health line
carries the count for normal operation.
@leandropineda
leandropineda merged commit de8b173 into main Jul 29, 2026
24 checks passed
@leandropineda
leandropineda deleted the fix/video-frame-staleness branch July 29, 2026 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants