On Tuesday May 26 2015 18:56:35 Konstantin Tokarev wrote: > > 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
MJPEG might indeed be one of the use cases where one could see a performance gain from a faster decoder, supposing that moving the decoded images around isn't going to be the (or another) bottleneck. One of my (informal!) tests involved a VNC client using libVNCServer, comparing libjpeg v9 and libjpeg-turbo, on a LAN. LibVNCServer prints a warning about performance when it detects you're not using libjpeg-turbo, but I doubt now that it's reasonable to expect much difference between the 2 libraries on recent hardware and anything but gigabit, fibre-optic network (or localhost connections). > > 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. > > FWIW, MJPEG is by far not the best codec choice for HD video. Indeed, though it depends on what you're aiming at, preserving quality with optimal compression, or playback performance - and what range of hardware you have to support. R. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
