Movies and auto-brightness
On Wed, 31 Jan 1996, Roger A. Unwin wrote:
> In an E-mail message, Paul Chinn wrote:
> > Ok guys, let's solve this one. Windows can record decently to disk and
> > they are even going thru VideoForWindows layer, so *we* should be able
> > rock. Here's 3 methods I've explored and the main problems with each.
> > * asynchronous file i/o- when data is flushed several frames get lost.
> > Framerate at any give moment is very good, but lost frames cause a bad
> > reduction in overall framerate- plus jarring gaps in motion.
> > * file i/o with syncs- leads to constant framerate- but at a seriously
> > degraded level.
> > * all in memory- some of my initial testing was encouraging but others,
> > especially with large frame sizes lead to a swap-o-rama. People's RAM &
> > swap space are certainly much smaller than available regular disk space.
> > Another method I'm considering: opening a pipe and forking. The
> > recording process writes to the pipe and the child manages bufferring
> > and writing. My theory is that while the parent is sleep()ing the child
> > will get yielded time and write its data...
> now, what if you anticipate the size needed to store the images.
> pre malloc it. then write to it, hopefuly forcing the swaping prior to
> the image capture.
Well, it would make sense to malloc() as much space as possible (Perhaps
a command line option to vary RAM cache size, with default of say, 2 megs.)
As I recall, a large realloc() would take too much time to finish. Perhaps
a FIFO cache that (as loomer suggested) dumps out to a forked process.
Possible problems with this (that I can see):
1) FIFO get overflowwed and frames are lost. If disk access is too slow,
this will probably happen. So the first n frames will be fine, but it
would degrade once the FIFO was full.
2) Disk access from forked process slows system response. Not damn likely
on a fast IDE/SCSI system, but possible.
3) Swapping takes place from large malloc() call and swapping slows system
down. Avoidable with a smaller FIFO, but that might result in lost frames.
Also, on a somewhat unrelated topic, would there be a way to have auto-
brightness implemented into the qcam drivers? I've just given the info
a cursory glance, and I know very little of graphics formats, but is it
possible to do a quick "brightness check" of an image? (ie: add up values of
pixels in certain areas, like a hot-spot in the middle plus a few other
points around, divide it by the # of pixels checked, and adjust brightness
until the average value is within a certain range.) I don't think it'd be
too tough to implement, as it's just greyscale. You smart guys out there
tell me, though. 8-)
Brandon High http://www.ccnet.com/~bjhigh Down with Big Brother!
email@example.com firstname.lastname@example.org email@example.com
It is people like you that cause running sores to fester.