On Mon, 24 Dec 2007 19:10:08 -0800 (PST), runcyclexcski@gmail.com
wrote:
My app (MFC .NET) performs image processing of an 640 by 480 8-bit
video at 30 frames per second and saves the data (x,y,z) of an object.
Movies may last up to 1 hr.
So far I've been throwing away the raw movie data. Now I am thinking
to save the raw video movies as well, in case I later on decide to re-
analyze them with another algorithm. A 1 hr full-frame movie would
take 640x480x30x3600 =~30 Gb. With my limited understanding of
programming, here is roughly what I am doing:
pFILE * movie;
char * buffer;
for (int i=0;i<frames;i++) {
grabframe();
writeframe(pFile,buffer,size);
}
The above routine works fine when I use a small region of interesest
(say, 200 by 200 pixels), but it can't keep up with the 30 fps frame
rate when I aquire the whole CCD - 480x640 - it misses every other
frame. I tested it only for 30 second movies so far.
If I put writeframe to a worker thread and signal to it to write by
posting messages , does it mean that with time all my RAM will be full
of frames waiting in the queue and the system will crash? How should I
handle this problem? Most likely, I won't be saving the whole 640x480
frame, but I figured I should test the worst case scenario.
well IMHO I believe it would be better to have a number of buffers and
instead of writing whenever you get a frame, to queue each frame in
one buffer, then at a given time period/frame limit you switch to a
fresh receiving buffer and start writing the frames from the "full"
buffer using a separate thread.
improve I/O performance. That way the I/O system can optimitze writing the