From owner-freebsd-hackers Fri Apr 18 04:20:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA25670 for hackers-outgoing; Fri, 18 Apr 1997 04:20:46 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25644 for ; Fri, 18 Apr 1997 04:20:40 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id EAA04704; Fri, 18 Apr 1997 04:19:52 -0700 (PDT) Message-Id: <199704181119.EAA04704@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Peter Dufault cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: video capture driver interface to file system? In-reply-to: Your message of "Fri, 18 Apr 1997 06:01:17 EDT." <199704181001.GAA16977@hda.hda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Apr 1997 04:19:52 -0700 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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