Option to validate camera streams by fetching a snapshot image

[Ullaakut]

Description

Overview

Add an option to enhance stream validation by attempting to fetch a snapshot from each video stream, confirming camera accessibility not just through network or authentication checks but by retrieving an actual image frame from the stream.

Goals

• Provide a configurable option to enable snapshot validation in Cameradar scan settings. Should be off by default.
• When enabled, for each identified stream, attempt to fetch a snapshot (image frame) early in the validation process (ideally using ffmpeg or a similar tool).
• Indicate in the results/report whether a snapshot was successfully retrieved for each stream.
• Ideally, should allow specifying a destination path or output method for retrieved snapshots (e.g., local folder, stdout as base64, etc.)

Potential Solutions

• Use ffmpeg to attempt to extract and save a single frame from the discovered video stream URLs.
  • Pros:
    • ffmpeg is widely available, reliable, and supports many protocols/streams.
    • Approach is scriptable and can run as part of the container.
  • Cons:
    • May increase scan time, especially on many streams.
    • Handling error cases for all types of camera endpoints may be complex.
    • If running Cameradar in a self-contained/self-destructing Docker container, displaying the image output is non-trivial—there’s no guaranteed terminal image support (see open questions).

Additional Info

Open Questions

• How can the user best view these snapshots, considering Cameradar may be running in a disposable Docker container?
  • Is there a cross-terminal way to display images in modern terminals or should snapshots be written to disk or as downloadable files?
• Does this approach significantly slow down scans and should it be off by default?

Code of Conduct

• I agree to follow this project's Code of Conduct

[vugarli]

Since the goal is to validate stream liveness, maybe another option could be a lightweight frame difference or read noise check?

[nblair2]

Since the goal is to validate stream liveness, maybe another option could be a lightweight frame difference or read noise check?

I think this would be a good follow-on once screen-grabbing is implemented.

[Ullaakut]

Since the goal is to validate stream liveness, maybe another option could be a lightweight frame difference or read noise check?

The main goal is to confirm that the credentials/route are correct. Sometimes, especially with cheap cameras that use outdated hardware/bad RTSP implementations, they might answer incorrectly to RTSP requests and look like they've been successfully accessed with no credentials, when in fact upon trying to grab a frame or view the stream we'd realize they're just misbehaving.

Unfortunately in those cases, despite confirming that they're inaccessible with what seemed like valid credentials/routes, the only way we'd really be able to bruteforce them would be by retrying the whole attack each time with a validation after each 200 OK which might be a very slow process, depending on how long an ffmpeg call to grab a frame takes.

Then, once we have that, we could easily add more features onto the validation check to make it even more reliable yes :)

[vugarli]

Since the goal is to validate stream liveness, maybe another option could be a lightweight frame difference or read noise check?

The main goal is to confirm that the credentials/route are correct. Sometimes, especially with cheap cameras that use outdated hardware/bad RTSP implementations, they might answer incorrectly to RTSP requests and look like they've been successfully accessed with no credentials, when in fact upon trying to grab a frame or view the stream we'd realize they're just misbehaving.

My bad. I initially assumed that misbehavior would only manifest as ffmpeg grabbing blank frames or static content