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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 10/27/2010 03:59 PM, Mitar wrote:
> Hi!
>
> On Wed, Oct 27, 2010 at 3:23 PM, Hans de Goede<hdegoede@redhat.com>  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