Re: Performance issue with HD Video cam

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 09, 2011 at 12:29:33AM +0200, Laurent Pinchart wrote:
> Hi Sarah,
> 
> 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.

Sarah Sharp
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux