From owner-freebsd-hackers  Sun Jan 28 02:24:11 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA13899
          for hackers-outgoing; Sun, 28 Jan 1996 02:24:11 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA13880
          for <hackers@freebsd.org>; Sun, 28 Jan 1996 02:24:05 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA03591; Sun, 28 Jan 1996 11:21:02 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199601281021.LAA03591@labinfo.iet.unipi.it>
Subject: Re: Amancio's tv program with capture!
To: hasty@rah.star-gate.com (Amancio Hasty Jr.)
Date: Sun, 28 Jan 1996 11:21:01 +0100 (MET)
Cc: jkh@time.cdrom.com, terry@lambert.org, james@miller.cs.uwm.edu,
        dufault@hda.com, hackers@freebsd.org, multimedia@rah.star-gate.com
In-Reply-To: <199601280750.XAA00879@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 27, 96 11:50:24 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
Precedence: bulk

> 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