Date: Thu, 06 Jan 2000 06:52:17 +0000 From: Alex <ak@freenet.co.uk> To: Tim Pozar <pozar@lns.com> Cc: freebsd-multimedia@FreeBSD.ORG, Amancio Hasty <hasty@rah.star-gate.com> Subject: Re: an FXTV suggestion Message-ID: <38743BA1.C439154D@freenet.co.uk> References: <38718545.451AE46F@mos.net> <20000105171550.A14765@ipass.net> <3873CED1.22BD498F@mos.net> <20000105164531.A88681@lns.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Pozar wrote: > > On Thu, Jan 06, 2000 at 02:08:02AM +0300, Alexei Khalimov wrote: > > Randall Hopper wrote: > > > > > What you want is a batch capture tool. What Fxtv is is an interactive GUI > > > application. These should be a separate apps. > > > > > > [[ I've seen this discussion before, with other tools. First is the > > > request for batch capabilities, then the complaint from someone else that > > > doesn't even run X that they have to have X installed (allocate disk space > > > for it, download the packages, etc.), not just to compile their batch app, > > > but to run it. The complaint is certainly justified. ]] > > > > Well, I would be happy with something like > > fxtv -batchsave /tmp/webcam.ppm -period 60 > > which will save single frame to that file every 60sec > > or save one and exit when called without -period > > (all this without starting GUI) > > > > it should not be hard to code it... > > I did this way back when (~'93) with Sun's VideoPix video frame > grabber device (/dev/vfc0). Cron would launch the program every > minute and the code would then opened the device, set the format > (size, video format, color, etc), grab a frame and spit out a YUV > image. At that point I would run PBM to clean it up and spit out > a (then) GIF image. > > Is there something like a frame grabber device for the 848 cards > that could be managed in much the same manner? Yes, that's exactly what /dev/bktr0 is for. You open the device, set the format (using the various ioctl's in <machine/ioctl_bt848.h>), then mmap the device, and you can start grabbing frames from the mmapped memory location. If you want a real *live* webcam (continuous capture), forget about saving images to the disk, use SysV IPC instead. You need a webcam server program that first allocates a shared memory location, and then continuously jpegs captured frames into that location (the jpeg library can do that very well). Then you have a client application that reads images from shared memory and sends them to the client. The only way to do that continuously (that I know of) is to use Netscape's "server-push". MSIE didn't support server-push two years ago, maybe they do now. You have to use semaphores to lock access to your shared memory while the server is updating it, and while a client is reading from it. This method worked very well for me in the past, with multiple clients. CPU consumption generally depends on how often you update the image, its size and JPEG quality. On a Pentium 200, with continuous updates, size 320x240 and a quality of 50, the server consumed about 50-90% of CPU time, while the clients used only about 0.01% each. The server was coded to do nothing if there were no clients requesting data. Obviously due to memory locks, the more clients you have, the less often the server updates the image (and therefore consumes less CPU, which I find rather amusing :). The maximal number of clients I had tested it with was about a 100, but I'm sure it can handle a lot more. The reason the clients are so lightweight is because compression, a CPU-intensive task, is done by the server; all a client has to do is 1) lock memory, 2) copy the data into its own buffer, 3) unlock memory, 4) send the data. The copying of the data into a buffer is important to avoid locking the shared memory for long periods of time (while the data are being sent across the network). That's all there is to it. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38743BA1.C439154D>