> > With Capture: > > Allocate video memory for frames > > Set the capture to use this video memory > > Use the DRM to map these into client memory > > After a frame is captured the client reads the data and stores it > > to disk. The client then does an XvMCPutSurface to display the > > frame on the overlay, since it is already in Video memory > > no copy is needed. > > Again, some sync between the frame reading and the capture would > > have to be done. > > Oh, no. The card captures _directly_ into an offscreen buffer. To make the > frame display all you need is to setup the overlay. Or is it what > XvMCPutSurface is supposed to do ? > > > > > For cc then you could just write to the cc area of the frame. > _read_ > Yep this would work. Though, I hear that for VBI plain reads are again too > slow, at least on the older cards. >
At least on faster machines, it is more efficient to read VBI frames and decode them in software; the software I2C is much slower than reading the VBI lines using PCI reads and decoding it in software. (Assuming interrupts are used for timing). I'm not sure about the few cards with hardware I2C _and_ hardware VBI decoding. But in any case, the CC must be read by the host processor for formating, and then rendered atop the color-keyed region. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
