Date: Fri, 18 Apr 1997 22:41:27 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: dufault@hda.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: video capture driver interface to file system? Message-ID: <199704181311.WAA25579@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704181119.EAA04704@rah.star-gate.com> from Amancio Hasty at "Apr 18, 97 04:19:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty stands accused of saying: > > 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. Proposal #1: Ok, so let's be really aggressive and say that you've configured the system for heavy-duty video recording. You need to sustain 3.5M/sec; a good SCSI subsystem can perhaps double that on a clear day, so allow yourself a 10M ringbuffer for acquisition; if you get more than a couple seconds behind I would expect you've got more problems than you want to know about. > 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. As suggested, I'd start with a couple of seconds of slack, to cover things like paging storms, soft write errors, etc., and basically write just as fast as you can. Your performance is going to vary lots depending on your system/disk/load profile, so it's difficult to be terribly explicit about numbers without lots of experimentation. You might want to think about frame-skipping heuristics in an attempt to deal with systems that weren't keeping up; that would probably be better than anything else I can think of right now. 8) Proposal #2: Stuff this whole files-and-filesystems thing. Pass a major/minor pair in to your device driver and teach it to use the low-level disk interface functions to write directly to regions on the disk. The latter approach, naturally, means more work, but you get to escape all the filesystem gumpf and get as close to the maximum throughput as you can; you end up with something more like a dedicated harddisk recorder. How serious about it do you expect your users to be? Are they likely to bite at repartitioning their disks? If I follow your inferences correctly, you want to add VCR-like functionality to something like fxtv, correct? In that case, you probably want to use regular files, and because recording is likely to be a spontaneous activity, you wouldn't be able to do much in the way of planning ahead, so you're going to be fairly-much dependant on getting the data to the filesystem as quickly as possible. > Amancio -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704181311.WAA25579>