fix(video): reconnect in software instead of swapping decoders mid-st…

[keyldev]

…ream (#94)

• On HW decode failure, mark the stream and end the session so the reconnect opens a fresh RTSP session decoded in software
• The in-place swap started the software decoder mid-stream; on NVRs whose frames keep referencing the session's first keyframe it drew grey forever

Summary

Related

Type

• Bug fix
• Feature
• Refactor / cleanup
• Docs / CI
• Other:

Checklist

• Builds with 0 warnings (TreatWarningsAsErrors=true).
• Tests pass (dotnet test); new Core logic has unit tests.
• No layering violation — App references Core only (Infrastructure / Video / Devices wired via DI in a head).
• Scope stays within one phase (didn't pull work from a later phase's "Не входит").
• README / docs updated if public commands, options, or setup changed.

Platforms tested

• Windows
• Linux
• macOS
• Android
• iOS
• CI build only

Screenshots / notes

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Reconnect with software decoding after hardware decode failure

🐞 Bug fix 📝 Documentation 🕐 10-20 Minutes

AI Description

• Reconnect failed hardware-decoded streams in software instead of swapping decoders mid-stream.
• Open a fresh RTSP session so software decoding can receive the session’s initial keyframe.
• Update troubleshooting guidance for persistent black or grey video.

Diagram

graph TD
  Camera["RTSP camera"] --> HW["HW decode session"] --> Cache[("Failed stream cache")] --> Wrapper["Reconnect wrapper"] --> SW["Software session"]
  Cache -->|skip HW| SW
  SW -->|fresh RTSP connection| Camera

Loading

High-Level Assessment

Reusing the existing reconnect wrapper is appropriate: it opens a fresh RTSP session while the run-scoped failure record directs the replacement session to software decoding. An in-place decoder swap cannot recover a keyframe sent at session start.

Files changed (2) +27 / -19

Bug fix (1) +23 / -15

FfmpegVideoSession.csEnd failed hardware sessions to reconnect in software +23/-15

End failed hardware sessions to reconnect in software

• Replaces the mid-stream decoder swap with a terminal failure after sustained hardware decode errors. Records the affected stream, releases the current packet, and reports a failure reason so the existing wrapper can create a fresh software-decoded session.

src/OpenIPC.Viewer.Video/Pipeline/FfmpegVideoSession.cs

Documentation (1) +4 / -4

troubleshooting.mdExplain software-decode reconnection for black video +4/-4

Explain software-decode reconnection for black video

• Clarifies that persistent VideoToolbox decode errors trigger a reconnect in software after roughly 2.5 seconds. Adds grey video to the symptoms users should report if the fallback does not help.

docs/troubleshooting.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Camera checks fail on recoverable streams ✓ Resolved

Description

FfmpegVideoSession.Run now ends the session after a hardware decode failure, but one-shot sessions
have no wrapper to reopen the stream in software. When this failure occurs during a camera
connection check, the check reports no video; a fresh-stream snapshot attempt likewise runs out of
time without trying software decoding.

Code

src/OpenIPC.Viewer.Video/Pipeline/FfmpegVideoSession.cs[R358-360]

+                    ffmpeg.av_packet_unref(packet);
+                    exitError = "Hardware decoding failed; reconnecting with software decoding";
+                    break;

Evidence

Both affected callers explicitly disable auto-reconnect. The engine returns a bare session in that
mode, while only the reconnect wrapper creates another session after failure. The changed break
therefore removes the previous in-place software fallback for these callers.

src/OpenIPC.Viewer.Video/Pipeline/FfmpegVideoSession.cs[353-360]
src/OpenIPC.Viewer.Video/Pipeline/FfmpegVideoSession.cs[444-447]
src/OpenIPC.Viewer.Video/FfmpegVideoEngine.cs[28-35]
src/OpenIPC.Viewer.App/Services/CameraConnectService.cs[239-263]
src/OpenIPC.Viewer.App/Services/CameraConnectService.cs[141-153]
src/OpenIPC.Viewer.Core/Snapshots/SnapshotService.cs[158-190]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The hardware-failure path terminates one-shot sessions, so camera connection checks and fresh-stream snapshots cannot use the software fallback.
## Fix Focus Areas
- src/OpenIPC.Viewer.Video/Pipeline/FfmpegVideoSession.cs[353-360]
- src/OpenIPC.Viewer.App/Services/CameraConnectService.cs[237-263]
- src/OpenIPC.Viewer.Core/Snapshots/SnapshotService.cs[158-190]
## Recommended Fix
On hardware-decoding failure, give one-shot callers a bounded retry that opens a fresh RTSP session with software decoding. Keep the existing time limits and ensure the failed session is disposed before the retry.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can import rules and skills only from the repositories your team follows

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗