From: Hans de Goede <hdegoede@redhat.com>
To: Mitar <mmitar@gmail.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
Date: Wed, 27 Oct 2010 11:08:35 +0200 [thread overview]
Message-ID: <4CC7EC13.1080008@redhat.com> (raw)
In-Reply-To: <AANLkTikGT6m9Ji3bBrwUB-yJY9dT0j8eCP_RNAvh3deG@mail.gmail.com>
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
2) It has various other legal issues which means it is not available
in most distro's main repository.
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, I hope that you are willing to
do a patch to switch to libjpeg, as I'm afraid I currently don't have
time to look into this.
Oh and a hint when using libjpeg for in memory images, please
use the jpeg_mem_src code from here:
http://gphoto.svn.sourceforge.net/viewvc/gphoto/branches/libgphoto2-2_4/libgphoto2/camlibs/ax203/jpeg_memsrcdest.c?revision=13328&view=markup
This code was specifically written to be API compatible with the
one introduced in newer libjpeg versions (8), while providing
memory src support when working with libjpeg versions which
do not ship with a memory src themselves like the version 6b
shipped by most distros (and used as a basis for libjpeg turbo).
So by using this memory src code, the libv4l libjpeg support can
work with libjpeg6-8 and libjpeg-turbo without needing any
ifdef's other then the one in that .c file.
Thanks & Regards,
Hans
next prev parent reply other threads:[~2010-10-27 9:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 23:51 [PATCH] Too slow libv4l MJPEG decoding with HD cameras Mitar
2010-10-27 9:08 ` Hans de Goede [this message]
2010-10-27 10:49 ` Janne Grunau
2010-10-27 13:23 ` Hans de Goede
2010-10-27 13:59 ` Mitar
2010-10-27 17:43 ` Hans de Goede
2010-10-28 20:35 ` Mitar
2010-10-27 14:01 ` Mitar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC7EC13.1080008@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=mmitar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox