Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras

[Janne Grunau <j@jannau.net>]

On Wed, Oct 27, 2010 at 11:08:35AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/27/2010 01:51 AM, Mitar wrote:
> > Hi!
> >
> > On Sun, Oct 24, 2010 at 6:04 PM, Mitar<mmitar@gmail.com>  wrote:
> >> Has anybody tried to improve MJPEG support in libv4l? With newer
> >> cameras this becomes important.
> >
> > I have made a patch which makes libv4l uses ffmpeg's avcodec library
> > for MJPEG decoding. Performance improvements are unbelievable.
> >
> 
> Thanks for the patch!
> 
> > I have been testing with Logitech HD Pro Webcam C910 and
> > 2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz.
> > Camera supports 2592x1944 at 10 FPS MJPEG stream.
> >
> > With using original MJPEG code it takes my computer on average 129.614
> > ms to decode the frame what is 0.0257 us per pixel.
> >
> > With using ffmpeg MJPEG decoding it takes my computer on average
> > 43.616 ms to decode the frame what is 0.0087 us per pixel.
> 
> That is a great improvement, but using ffmpeg in libv4l is not an option
> for multiple reasons:
> 
> 1) It is GPL licensed not LGPL

FFmpeg is mostly LGPL licensed, only a few optimizations and interfaces
to GPL libraries. Running FFmpeg's configure without options and
especially without --enable-gpl will only use lgpl or compatible
licensed code.

> 2) It has various other legal issues which means it is not available
>     in most distro's main repository.

FUD, Ubuntu doesn't seem to have a problem with it.

> So I'm afraid that using ffmpeg really is out of the question. What
> would be interesting is to see how libjpeg performs and then esp. the
> turbo-libjpeg version:
> http://libjpeg-turbo.virtualgl.org/
> 
> I would love to see a patch to use that instead of tiny jpeg, leaving
> tinyjpeg usage only for the pixart jpeg variant stuff.
> 
> Note that some cameras generate what I call planar jpeg, this means
> that they send 3 SOS markers with one component per scan. I don't know
> if libjpeg will grok this (I had to patch libv4l's tinyjpeg copy for
> this). But first lets see how libjpeg performs, and then we can always
> use tinyjpeg to parse the header and depending on the header decide to
> use tinyjpeg or libjpeg.
> 
> Sorry about nacking your ffmpeg patch,

While the patch is not the cleanest, there shouldn't be a problem of
making ffmpeg mjpeg decoding optional.

Janne