I don't think you can do what you propose in real-time, at that frame rate. Also, if you do it the way you describe you will get intolerable flicker, as you redraw the graphics over the video. If you draw the graphics into the memory buffer before copying it to the screen you will get no flicker. But if what you are trying to do is to display captions over live video, you can definitely do that. What you need to do is set a video clipping bitmap equal to the shape of the captions, then draw the captions. Don't use capture mode; let the capture card do DMA to the frame buffer. It will clip the video, not drawing video wherever there are ones (1) in the clipping bitmap. Using Xlib (I don't know about OpenGL) you can create a bitmap (depth 1 pixmap), clear it to 0, draw the text into it with foreground color = 1, do a XGetImage to get the bits back from the X server, and then set those bits into Video4Linux, first stopping the video then restarting after setting the clip bitmap. Then draw the same text to the screen using Xlib and the same font (do this also on Expose events). All this works great with bttv (e.g. WinTV card) and Video4Linux "one". How to set a clip bitmap is undocumented; I discovered it by reading the source. I earlier posted mail to this group, but I've switched mailers and don't have it anymore. It's probably in the FAQ archives (if you can figure out how to use them - I can't ); you could search for "Kaczowka" - that's pretty unique. I don't know if non-bttv cards support clipping bitmaps, or if Video4Linux 2 supports it. If not, you can also use the X Shape extension to convert a bitmap to a list of rectangles (Region) then get that region back from the X server. There is then no supported way to get the rects from a region, but if you look at Xlib source code you can find out what a region really is: a pointer to a structure. Read the rects from that structure, convert them to Video4Linux format, then set that list of rectangles to the video driver. This approach is slower but is ok if you don't change captions often. The irony is that the bttv driver converts the list of rectangles to a bitmap, then calls code to program the DMA engine from that bitmap. So you will be having X convert the bitmap to a list of rects, only to then convert the list of rects to a bitmap. The other approach is to use XFree86 4.0 and XVideo with some sort of chroma key support: video appears wherever you paint a transparent color. At least I'm assuming that that environment supports chroma keying; I haven't used it yet. In any case, the approach I've described above works, and takes essentially no CPU unless you change the captions, since all the video is being DMA'd; does take PCI bus bandwidth though. As I noted in earlier mail, bttv has a bug: if the clipping bitmap is too large or complicated it will hang the CPU (or bus) big-time, and you will have to reboot, and in some cases pull the power plug to force a hard reset on the capture card. Captions won't generally do that, but setting a clipping shape such as every-other-bit-on will. Now a shameless plug for my ex-company and product (others can skip to next mail message if they like): if your company has a need for high-quality/resolution display cards, or for high-performance imaging software, take a look at DOME imaging systems (www.dome.com). As far as hardware goes DOME mainly sells high-res grayscale displays (e.g. 5-8 Mpixels) for PACS. They also have do sell color displays which I assume you would want for cardiac - oh yeah and they now sell very high-quality-res color flat panels, which I assume would be useful to your business. Their imaging software is called "DIMPL": DOME Image Processing Library. See the web site for benchmarks; by far the fastest code around, e.g. look at JPEG decompression timings (uses MMX, etc.) Lots of major medical companies use it. DOME generally does not name them, but one of them is the world's largest medical company; well, actually, the world's largest company also, I think. Lots of Japanese companies also (am I still under NDA?) This is all biased I'll admit. I own stock in DOME, and I also wrote DIMPL. But this being the USA, every bit of free information (TV, Web, or this mail) comes with an advertisement, like this one :-) My current company is not selling product yet or I would plug that also. Hope this helps. Peter "only in it for the money" Kaczowka www.ucentric.com Brian Hoffman wrote: > Hi, > > I've seen lots of development work related to capturing NTSC/PAL video > and simply displaying it (video4linux, video4linux2 for TV tuner cards, > etc.) > > However, I haven't seen much (any ...?) information or projects related > to overlaying graphics on top of captured video. > > With a generic x86-PC, I'm envisioning: > > a) Capturing color video (720x486, PCI bus->Memory) > > b) Transferring each frame in real time to a 3D graphics > accelerator card (Memory->AGP4x->GFX Card) > > c) Drawing the video data as a textured rectangle or > using glDrawPixels() > > d) Rendering/Blending additional graphics on top of it > with OpenGL. > > So here are the questions: :) > > 1) Is it even possible to do this under Linux/XFree86? > > 2) Has anyone done such a thing already? > > 3) Assuming yes, can it be done at full-speed (30Hz)? > (i.e. no dropped frames, constant framerate? > bandwidth limitations?) > > 4) Any suggestions for graphics cards + capture cards? > (that would play well together and with the available > software?) > > Being able to drive an NTSC output would be nice also, as there are > a number of attractive display options that don't have VGA inputs. > > Hoping I'm posting to the right list(s) :) If I'm > not, hoping you can point me to the right ones ... > > Thanks! > Brian > > ----- > Brian Hoffman > Intuitive Surgical, Inc. > brian_hoffman@xxxxxxxxxxxx > > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
