> * If the driver has to touch the video data (which is true for many usb > cams because they have to uncompress the data) it doesn't work nicely. > Basically the driver will have to do a extra memcpy then: > copy_to_user(v4l2_buffer->ptr,kernelbuf,size).
The driver cannot touch the video data if it is in a userspace buffer? > For these reasons it simply is no option to drop the mmap() buffers > altogether. And I don't like the idea to support both mmaped and > application-allocated buffers that much because it makes drivers and > applications more complex. In my application's case, using my own memory instead of the mmaped memory would simplify things a bit. Not a lot, but a bit. I would not see much of a speed increase because my processor is pretty fast as it is, but I am grabbing at anything I can get at this point, and this sort of algorythmic increase is greatly desirable over fine-tuned assembly. The absolute ideal situation would be one of two. 1. I ask X for shared xvideo mem buffers, and get the capture device to capture directly to them. 2. I ask the device for mem buffers, and get X to use those for xvideo display. One of these two options has GOT to be possible, I don't want to believe that neither is. Actually, the second one should be possible for sure, perhaps simpler all round than the first. Any ideas? _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
