[Interest] libjpeg vs. libjpeg-turbo/mozjpeg

Matthew Woehlke mw_triad at users.sourceforge.net
Tue May 26 17:47:28 CEST 2015


On 2015-05-23 13:50, René J.V. Bertin wrote:
> On Saturday May 23 2015 19:06:47 Allan Sandfeld Jensen wrote:
>> The bug for replacing lbjpeg with libjpeg-turbo is 
>> https://bugreports.qt.io/browse/QTBUG-40091 - Feel free to take it over :)
> 
> Funny how that focuses on a performance difference which is
> apparently not due to using libjpeg-turbo vs. the regular version.

Hmm...

Performance is *exactly* why we switched to building our own
libjpeg-turbo and then building Qt against that, rather than using the
bundled libjpeg.

We have an application that deals with what is effectively MJPEG video,
but we are handling the "M" part of it ourselves, and using Qt to read
and write frames. We ran into problems with HD video; it worked fine on
Linux, but had serious issues on Windows. After tracking it down to the
time spent reading/writing the frames, we realized that on Windows, Qt
was using a bundled libjpeg, while Linux of course was using
libjpeg-turbo. Building Qt on Windows against an externally built
libjpeg-turbo fixed the problem.

> Apparently the few tests I did where not decoding-constrained even
> on a 4yo 2.7Ghz i7

I guess not (or else for some reason you are not getting the same
performance gain as on other platforms). For us, we saw about a 10x
difference in (IIRC both encode and) decode performance between Qt's
embedded libjpeg and libjpeg-turbo. Mind, that's comparing numbers (real
numbers from targeted performance metrics measured in code with
QElapsedTimer) from a Linux machine and a Windows machine, although the
Linux machine in theory was a slower CPU, so an apples-to-apples number
might be even larger. At any rate, for our use case (for which JPEG
encode/decode was definitely the bottleneck) there was a significant
improvement on Windows when we switched.

An objective test, if you wanted to run one, would be to read a
modest-sized JPEG into a QByteArray, then use QImage::load to decode it,
wrapped with a QElapsedTimer to time how long QImage::load takes. Do
this with both Qt's embedded libjpeg and libjpeg-turbo. This should
eliminate any I/O overhead. An image around 2 MP should be enough to be
well above measurement noise (IME, tens of milliseconds with
libjpeg-turbo, and hundreds of milliseconds with libjpeg).

-- 
Matthew




More information about the Interest mailing list