[Prev][Next][Index][Thread]
Re: disk dilema
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.
$0.02
>
> --
> __ _____ _____ _____ _____ ______
> | | | | | | ___| __ | | Paul Chinn
> | |__| | | | | | | | ___| \ | loomer@1000klub.com
> |_____|_____|_____|_|_|_|_____|__|\__| | finger loomer@svpal.org for
> PGP key
>
--
__&__
/ \
| |
| (o)(o)
C ,---_)
| |,___| "I am Homer of the Borg. You will be assimilated. Resistance
| \__/ is irrelevant. Preparation is irrel...MMMmmm...doughnut!"
/_____\
/_____/ \
Follow-Ups:
References: