Hi,
On 10/27/2010 03:59 PM, Mitar wrote:
Hi!
On Wed, Oct 27, 2010 at 3:23 PM, Hans de Goede<hdegoede@xxxxxxxxxx> wrote:
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 opted for avcodec as I have been told it is the fastest
implementation around. But I have not really tested that claim. So for
sure this should be tested. I tested just original tinyjpeg vs.
avcodec implementation.
I am sorry but I do not have time to do more work on this. Especially
because libjpeg-turbo also seems to have problems with restart
markers:
http://libjpeg-turbo.virtualgl.org/About/Performance (at the end)
which is the problem I am currently try to deal with also with ffmpeg:
https://roundup.ffmpeg.org/issue2325
Well the problem is not entirely the same. libjpeg-turbo will degrade
a bit in performance when encountering these markers, where as if I
understand your ffmpeg bugreport properly ffmpeg does not properly
decode these images. This seems actually like an argument in favor of
giving libjpeg a try.
Are you sure you cannot make some time for this?
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
