JPGs From Security Cams - Strategy
From
c186282@21:1/5 to
All on Sun Jun 8 00:55:22 2025
A few days ago I posted about "incomplete" JPGs
recovered from security cams - mostly using
OpenCV routines.
The cams make complete JPGs about once a second,
but there's nothing to ensure that they are
intact/valid WHEN you read them. This can, kinda
often, results in corrupted/partial images.
There is no "perfect" fix ... we're downloading
from external devices with their own schedules.
Utilities like "Motion" seem able to deliver
perfect JPGs. I've tried to look through the
source, but it's a LOT of source. As best I
can discern, it just looks for a perfect JPG,
the correct start/end bytes, and stores that.
"Bad" images are just IGNORED. Maybe not the
"ideal" fix-it-up solution, but DO-able.
SO ... my proposal is to have two flags -
a 'start detected' and 'end detected'.
We read the JPG from the cam. If both
flags don't come up true then we RE-read
immediately - for a FEW tries (counter
involved). If neither condition is ever
satisfied, well, we use the partial
buffered image. MIGHT be "good enough".
Real-world is a BITCH.
Alt ... always look for the "start" bytes
and then re-read quickly until the "end"
bytes are found. Then paste it all together.
This requires a LOT more buffering/computing.
For MOST purposes it is a waste of CPU,
just a theoretical exercise.
RTSP ... part of the cam firmware ... it
CAN do all this, send the 'perfect' image.
Alas the LATENCY tends to be VERY bad.
The evil perps could be breaking in your
front door before you even see them.
Note, all my cams are wi-fi. Info does
not xfer instantly.
The software loop proposed is not very
difficult. I'll use Python and the OpenCV
libs. The OpenCV stuff is writ in 'C' so
it's very fast. The Python is just the
'management framework' and its relative
slowness is far less relevant.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)