Date: Sun, 28 Jan 1996 11:21:01 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: jkh@time.cdrom.com, terry@lambert.org, james@miller.cs.uwm.edu, dufault@hda.com, hackers@freebsd.org, multimedia@rah.star-gate.com Subject: Re: Amancio's tv program with capture! Message-ID: <199601281021.LAA03591@labinfo.iet.unipi.it> In-Reply-To: <199601280750.XAA00879@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 27, 96 11:50:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The direction which I am thinking of taking is to wired the > graphic card's frame buffer to the matrox meteor driver . > This way the meteor can dump video data with no software > intervention whatsover and if the graphic card is capable we > should be able to see 640x480*4 at 30fps. My rationale for doing > this is just speed, speed, and speed and the pathetic > memory bandwith that we have in the Pentium. Since the cpu is not involved in this kind of transfers, it's more like a problem of PCI / video ram bandwidth. A few numbers: NTSC, 640*480*30fps, 32bpp 36.864 MB/s PAL, 768*576*25fps, 32bpp 44.237 MB/s NTSC, 640*480*30fps, 16bpp 18.432 MB/s PAL, 768*576*25fps, 16bpp 22.118 MB/s Now, depending on the video refresh rate, you might not have enought bandwidth on the VRAM to do it, except perhaps in the 15-bit modes. > Now with something like the video extensions is conceivable with > little pain to dump the video stream to the off display region > and then use proper X semantics to display the frame. Usually > internal blts in graphic engine have tons of bandwith. Additionally, If I get it right, dumping video off screen and moving it back with blt ops in the video engine might allow a correct handling of overlapping windows, but at the cost of a lot of work in the video accelerator (you must ask for a redraw on every frame). Bottom line: we have three active modules in our system: CPU, video chipset, frame-grabber-controller. Inexpensive live video can be achieved by keeping busy only the latter, but only if the video window is completely visible (or invisible :) ). Dealing with oddly-shaped windows requires a lot of work by either the CPU or the video chipset. In both cases I suspect the system has not much horsepower left. Luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601281021.LAA03591>