DVR reencode: stop silently corrupting recordings, fail fast instead#141
Draft
henkwiedig wants to merge 5 commits into
Draft
DVR reencode: stop silently corrupting recordings, fail fast instead#141henkwiedig wants to merge 5 commits into
henkwiedig wants to merge 5 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DVR reencode: stop silently corrupting recordings, fail fast instead
Investigated a video artifact reported in field footage — DVR reencode frames occasionally skipped colour-correction and showed a green bar at the bottom, while the recording looked completely normal (still "recording", no errors). Root cause: the colour-correct/OSD-blend GL+RGA pipeline had a fallback chain that could publish a corrupted or partially-written frame instead of catching the problem.
Two changes:
Removed the fallback cascade. Any GL/RGA conversion failure now stops the reencode session immediately (raw recording, if also enabled, keeps going untouched) and shows an OSD popup so the user knows recording stopped instead of unknowingly getting a broken file.
Padding guard. Even a successful RGA call could leave the last few rows of the frame buffer unwritten (the bit beyond 1080p's real height, up to the 16-pixel-aligned buffer size) — and this hardware can't reliably let the CPU verify what RGA actually wrote, so detecting it after the fact isn't possible. Instead, we now always extend the last real row into that padding via one more RGA op — guaranteed correct by construction, not by inspection.
This is not a actual fix, at least not for the second bug. We try to guard it and hope it helps.
Will amend this with logging in the sbc-groundstation so the user can generate more useful information.