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 Restart markers are used by Logitech HD Pro Webcam C910 to allow decoding of MJPEG in parallel for example on GPU for even faster decoding. So implementing libjpeg-turbo does not seem that it would give me a working solution and improvement over libavcodec. (And for ffmpeg there is at least patch for that.) Maybe we should make libv4l plugable in this respect? So that different underlying libraries could be easily swapped and tested and used? Or just use different compilation switches and let distribution maintainers decide which one they want to use? Mitar -- 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
