Hi,
On 10/27/2010 12:49 PM, Janne Grunau wrote:
<snip>
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.
Ok, that is good to know.
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.
Not a really helpful response I'm afraid, there are a number of highprofile
distributions which do not include ffmpeg, so depending on ffmpeg is not
really an option.
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.
If and only if libjpeg-turbo turns out to be much slower this is something
to consider. But the first thing to do here is see if we can solve this
in a way which is acceptable to all downstream users of libv4l, and thus
can be added in a non optional way (so make libv4l require libjpeg).
I'm not a big fan of optional features / compile time options as they
do not make support any easier.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
