c186282 <
[email protected]> wrote:
MOST of my JPGs come from SECURITY CAMS. They get refreshed, by the
cam, about once per second. Good enough.
But, problem, it's kinda pure CHANCE as to whether I get a COMPLETEL
jpg. The cams may update at any moment.
The problem here is a classic race condition. Your 'file reading'
program is not synchronized with the 'file writing' program (the cam)
and so it is opening files the camera has not yet finished writing.
Some ideas for solutions:
Can you configure the camera to write to separate jpeg files (i.e.
0000.jpeg, 0001.jpeg, etc.)? If yes, then you could ignore the
"newest" file (as it might still be getting written) and only open the
"second newest" and older files instead.
If the camera always writes to the same file (this is a poor design,
but if it is what the camera does and you can't change it you have
little recourse) then what filesystem does the camera write to? Is it
a Linux filesystem? If yes, you /might/ be able to use an inotify
event of "file closed" to synchronize your reader to the writer such
that the reader only reads the file just after the camera closed it
(assuming the camera wrote a complete file, then you'd get a 1 second
chance to read the file whole). If you go this route I'd suggest you
simply do a straight "file copy" when the inotify event triggers, then
open and process that copy. That gives you "1 second" to complete the
copy (fesable) and your "after processing" can take more than 1 second
without worry at that point.
Third idea, if your cameras provide a "web" api to retreive the current
image, maybe retreving an image via that method to use might give you a
fully valid image.
Clearly though, OpenCV isn't entirely oriented towards securing
COMPLETE jpgs. It acts on WHAT'S THERE at the moment. MIGHT be
complete, or maybe not.
Not really OpenCV's fault when the file it is reading is incomplete.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)