[Prev][Next][Index][Thread]

Re: mpeg encoder

Russell Nelson wrote:
> 
> 
> Hmmm...  I'm hoping that the MPEG encoder can deal with frames that
> don't arrive at a constant rate!  If it needs a constant rate, then we
> need the QCam driver to throttle back the frame rate until it can
> predict that it will really be able to generate the frame rate that
> it's asked to, even in view of changing system load.
> 

I have added the ability to record video to xfqcam but it's not ready
for primetime.  I'm hoping to get some input from the group.  My
strategy is to dump raw frames to one big file while recording then
process them out into individual pictures when done.  I have the camera
recording at a constant rate using the following algorithm:

for the desired frame rate compute the usecs per frame(uspf).  ie 30 fps
= 33333 usecs per frame.  that's the total time we can (and must) spend
processing a frame to achieve constant rate.

then, loop:
	start=gettimeofday
	captureframe
	savetodisk
	stop=gettimeofday
	elapsed=stop-start
	if elapsed < desired
		wait for rest of duration
	else
		figure out how many frames we lost

the wait is implemented with a combination of usleep and loop that
takes into account usleep's poor resolution (20-30 millisecs on my
system)

This works very well.  Of course a big shift in load will nuke a frame
or two in tight situtions (ie 160x120 at 15fps) but over all ensures a
steady framerate.

The problem is with the disk access- it's killing me- it appears the
system is not multitasking the disk io, instead it buffers up over
several frames, then it writes to disk and a couple frames are lost.
This occurs even if I have plenty of cpu time to burn.  For example,
without the disk access, I can achieve 15fps at 160x120.  So I go to
record at a paltry 5 fps but I lose frames left and right.  I have tried
both the fopen routines and open with O_NDELAY.

What I want to happen is this:
	capture frame
	write frame
	plenty of time to sleep
	...
	capture frame
	write frame
	sleep  [linux timeslices, data is written while I sleep]
	...
	etc.
but what appears to be happening is:
	capture frame
	write frame
	sleep
	...
	capture frame
	write frame- lots of data written, long time spent
	no times to sleep- infact we lose frames!!!


Any ideas from the crowd?  Either in modifying the algorithm or
something about disk i/o to handle this.

--
 __    _____ _____ _____ _____ ______
|  |  |     |     |     |  ___|  __  |   | Paul Chinn
|  |__|  |  |  |  | | | |  ___|      \   | loomer@1000klub.com
|_____|_____|_____|_|_|_|_____|__|\__|   | finger loomer@svpal.org for
PGP key
Follow-Ups: References: