Add secure RTSP camera support with resilient capture lifecycle

[elkampu]

Problem

IPCamLapse currently captures from HTTP/HTTPS JPEG snapshot endpoints. Many IP cameras expose RTSP as their primary or only reliable interface, which forces users to find undocumented vendor-specific snapshot URLs or prevents them from using the app at all.

Goal

Add RTSP and RTSPS as first-class camera source types while preserving IPCamLapse's local-first security model, fixed-timeline scheduling, pause/resume behavior, and useful failure diagnostics.

Difficulty: advanced. This crosses camera profiles, process management, capture scheduling, security, UI, persistence, and integration testing. A short design proposal in the issue before implementation would be welcome.

Expected product behavior

• Camera profiles let the user choose JPEG snapshot or RTSP stream.
• RTSP profiles support rtsp:// and rtsps://, authentication, and an Auto/TCP/UDP transport preference.
• Testing a profile returns a preview frame or a specific diagnostic such as authentication failure, timeout, unsupported transport, TLS failure, or missing FFmpeg.
• Starting, pausing, resuming, cancelling, or deleting a session promptly starts or releases any RTSP/FFmpeg resources owned by that session.
• Multiple sessions remain isolated; one stalled stream must not block another session.
• Captures remain aligned to the existing fixed timeline. Missing frames are recorded through the current failure counters and activity log rather than silently shifting later captures.
• Existing HTTP snapshot profiles and persisted sessions continue to work without manual migration.

Security requirements

• Apply the existing private/loopback/link-local camera-address policy to RTSP targets. Hostnames and public addresses must remain opt-in through the existing camera-access settings.
• Protect stored passwords with the existing ASP.NET Core Data Protection path.
• Never include credentials or full credential-bearing URLs in logs, exceptions, diagnostics, UI output, test snapshots, or committed fixtures.
• Avoid exposing credentials in the FFmpeg command line if practical. If the platform/FFmpeg interface makes that impossible, document the limitation, minimize process lifetime, redact all application logging, and explain the trade-off in the PR.
• Bound connection time, frame size, and subprocess shutdown time. Cancellation must not leave orphaned FFmpeg processes.

Implementation constraints

• Keep the HTTP capture path intact and introduce a source-aware capture abstraction rather than adding RTSP branches throughout CaptureBackgroundService.
• Make FFmpeg/process execution injectable so lifecycle, cancellation, exit-code handling, and redaction can be tested without relying on a developer machine's camera hardware.
• Do not buffer an unbounded stream in memory. A captured frame must still pass image validation and the configured snapshot-size limit before it enters session storage.
• Persist the source type and RTSP settings with backwards-compatible defaults for existing profile JSON.
• Surface FFmpeg as a required health check only when an RTSP source is selected; the demo and HTTP snapshot paths must remain usable without it.

Acceptance criteria

• A user can create, edit, test, and delete an authenticated RTSP camera profile.
• A user can complete RTSP capture → render → download on Windows and Linux.
• Auto, TCP, and UDP transport choices map to documented FFmpeg behavior.
• Pause/resume and cancel stop RTSP work promptly and preserve correct active-capture timing.
• Retries and consecutive-failure accounting behave the same way as HTTP snapshot capture.
• An interrupted or failed FFmpeg process produces a useful, credential-free diagnostic and cannot mark the session completed.
• Existing HTTP/demo profiles and sessions remain backwards compatible.
• Unit tests cover profile migration, URL policy, argument/diagnostic redaction, process cancellation, retry behavior, and concurrent-session isolation.
• An automated integration test uses a local synthetic RTSP source—no real camera or internet dependency—to exercise capture through a stored frame. Document how to run it locally if it is too heavyweight for the default test job.
• README, architecture, configuration, and security documentation describe setup, transports, limitations, and troubleshooting.
• dotnet test, dotnet format --verify-no-changes, and the existing Windows/Ubuntu CI jobs pass.

Out of scope

• Live-view streaming in the browser
• Audio capture
• Motion detection or object recognition
• ONVIF discovery
• Recording the original continuous stream

Suggested delivery slices

1. Backwards-compatible source models, RTSP URL policy, and secure profile UI.
2. Injectable FFmpeg capture backend with lifecycle and redaction tests.
3. Capture-pipeline integration, diagnostics, synthetic RTSP test fixture, and documentation.

These may be separate PRs linked to this issue if that makes review safer.