On Mon, Oct 08, 2001 at 06:14:13PM -0700, Sottek, Matthew J wrote: > my apologies for the misunderstanding. np, the point is we all learned something new :-)
> My point should still hold. The DRM should allow you to map
> an video area into a client accessible memory location.
You don't need DRM for plain memcpy. Pure X functions can do that.
> Your client could then read directly from the video memory and output
> the result to disk.
Yes, but this:
1. is slow as hell (so I've been told by volodya and RC, I don't have personal
experience with that)
2. eats CPU time as hell (this follows directly from 1.)
> This would require some sort of synchronization to make sure you are not
> reading a buffer that is being updated.
Actually not necessary, read futher...
> Without capture:
> Allocate video memory for frames
> Set the capture to use this video memory
> (either a separate card or an on-chip capture)
> Set the overlay display hardware to display these buffers.
This is exactly how R128{Get,Put}Video (or something like that) currently works.
> With Capture:
> Allocate video memory for frames
> Set the capture to use this video memory
Just Cut&Paste from R128GetVideo.
> Use the DRM to map these into client memory
drmDMA;drmUberCoolCapture;memcpy;drmFree;
> 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.
Not necessary, just call R128DisplayVideo422.
(for radeon or mach64 just replace the R128).
Hmm perhaps we could have a yet new function, XvShmGetImageAndVideo that
combines capturing and displaying, because from outside of X there is no way
to call the internal functions?
> Again, some sync between the frame reading and the capture would
> have to be done.
I think this already works (i.e. simply getting the data from the tuner and
displaying it doesn't produce flicker).
> For cc then you could just write to the cc area of the frame.
> This all comes down to how bad the mmap'd read is compared to
> a DMA write from the Video card to system memory
Memcpy is so slow that apparently you can't even transfer the frames in
realtime. Not to mention that you'd probably want to compress them after the
transfer.
I hope I can find time to make some real experience soon :-)
> plus the extra read from the system memory in order to write it to disk.
IMHO negligible.
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
msg01848/pgp00000.pgp
Description: PGP signature
