Date: Fri, 18 Apr 1997 04:19:52 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Peter Dufault <dufault@hda.com> Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: video capture driver interface to file system? Message-ID: <199704181119.EAA04704@rah.star-gate.com> In-Reply-To: Your message of "Fri, 18 Apr 1997 06:01:17 EDT." <199704181001.GAA16977@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Lets see, We can capture video in different formats: yuv9, yuv12, rgb16, rgb24, rgb32, 8bit grayscale. The size of the frames can be specified by the user to be anywhere between 160x140 to 640x480 or PAL resolution. What I am thinking that will be useful is to capture yuv12 which can be used for mpeg or h.263 encoding. yuv12 is : x*y + 2(x/2 * y/2). We can daisy chain buffers in physical memory pending upon the resolution and the amount of memory available for the system. A good resolution for mpeg is 320x240 30 frames/sec for yuv12 that translates to 3456000 bytes/sec so lets called it 3.5MB/sec substain thruput. How many frames should I store in memory in order to realize such thruput? (scsi disk recommendations for video recording are welcome 8) ) I get a frame every 1/30 of second. Someone once dubbed the multmedia hackers as "lizards" I think we are more like Jelly Beans http://multiverse.com/~rhh/fxtv/index.html#ThePic 8) Tnks, Amancio >From The Desk Of Peter Dufault : > > We need a very fast mechanism to store images to disk. Suggestions? > > You need to provide more info because the problem is different > based on how much you're trying to store to disk, and whether it > should be a normal UFS file system, etc. > > To do this completely you're going to have to look at your requirements > (trigger condition, latency to start, latency between blocks, block > size, throughput, and maximum length of run), and based on this > possibly do as much as: > > Pre-allocate the file; pre-allocate the blocks of a file; pre-set > up some control info for a transfer, mmap a set of blocks for the > video card driver to dump data into; have the driver chain to the > next block and interrupt you on each transfer, dump the video frames > to the pre-allocated store. > > If you have the P1003.1b-1993 spec you'll find a proposed (not > standard) real time file interface (look for the "rf_" stuff) in > the back with a proposed API. > > However, if the rates are low enough and the pentium and bus fast > enough you can do as little as to provide multiple mmapd buffers > that the video driver will chain through and a SIGUSR to the logging > process that dumps frames of collected data to disk through the > file system - nothing fancy. This isn't synchronous because the > driver is chaining to the next block at "frame done" interrupt time > giving you the elasticity you need. > > Peter > > -- > Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation > HD Associates, Inc. Voice: 508 433 6936
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181119.EAA04704>