Hi Sarah, On Tuesday 09 August 2011 02:30:33 Sarah Sharp wrote: > On Tue, Aug 09, 2011 at 12:29:33AM +0200, Laurent Pinchart wrote: > > On Tuesday 09 August 2011 00:18:02 Sarah Sharp wrote: > > > On Tue, Aug 02, 2011 at 01:44:54AM +0200, Laurent Pinchart wrote: > > > > On Monday 01 August 2011 18:57:14 Sebastian Andrzej Siewior wrote: > > > > > * Laurent Pinchart | 2011-08-01 16:04:55 [+0200]: > > > > > >> IIUC, there's no way to avoid copying the data since it has to > > > > > >> processed before getting sent to userspace. > > > > > > > > > > > > Every UVC packet starts with a header that needs to be removed, > > > > > > so we unfortunately can't get rid of all memcpy() calls. > > > > > > > > > > So we have something like that: > > > > > +---------------+------------+-----------+ > > > > > > > > > > | hdr-to-remove | jpeg header| jpeg-data | > > > > > > > > > > +---------------+------------+-----------+ > > > > > > > > First of all, UVC devices don't stream MJPEG only. Uncompressed video > > > > formats are very common. > > > > > > Would it help to have UVC use a scatter gather list for every > > > isochronous frame? Then you would just need to allocate the header to > > > remove as the first sg entry, and place the jpeg header and data into > > > the second sg entry, which would avoid the memory copy. There's > > > already scatter gather list support for bulk transfers, so I think it > > > shouldn't be too hard to extend to isochronous transfers. > > > > Thanks for your proposal. > > > > Let's make it even more fun: the header size is not constant, and is > > specified by the first byte of the header. Good luck coming up with a > > generic solution for this :-) > > So is the header something the UVC video driver allocates, or something > userspace allocates? Is the header, jpeg header, and data all confined > to one frame (one usb_iso_packet_descriptor in the URB)? > > Scatter gather list entries can be variable length, so I don't really > see where the problem is, as long as the uvcvideo driver knows how long > the header for that particular frame is supposed to be. You'd just have > one scatterlist per frame, with either two or three entries (I don't > know if userspace passes the jpeg header and data as one buffer) that > you would re-setup every time an URB completes. > > Of course, I don't know if the trade off in size of having a scatterlist > per frame vs. the performance gain of avoiding the memcopy would be a > good choice. But I do think it's feasible. In a nutshell, uvcvideo devices that use isochronous transfers slice the data in packets and prepend each packet with a header. The resulting packet is then sent over the bus. The header starts with an 8-bit field that indicates its length. The length is variable (typically 2 or 12 bytes, but can take other values as well) and the host has no way to know in advance how long the header will be for a particular packet. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
