Hello, friends. :) I put together a "DroidCam" program for myself to turn my smartphone into a webcam with a microphone ( https://github.com/dev47apps/droidcam ). It turned out to be very useful for me because of the convenient way to connect a smartphone via ADB and via Wi-Fi. The only thing that prevents me from using it normally is the unstable transfer of the video stream from the camera of my smartphone to Skype via WiFi. Video transmission is interrupted or does not start at all due to the fact that Mageia-8 uses "libjpeg-turbo-v2.0.5". There is a bug in this version, which is described here: https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.0.6 Quote (Significant changes relative to 2.0.5): --- 2. Fixed or worked around multiple issues with jpeg_skip_scanlines(): Fixed segfaults or "Corrupt JPEG data: premature end of data segment" errors in jpeg_skip_scanlines() that occurred when decompressing 4:2:2 or 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that is, when setting cinfo.do_fancy_upsampling to FALSE.) 2.0.0[6] was a similar fix, but it did not cover all cases. --- Now I am forced to build my "DroidCam" using the package contents from here: https://sourceforge.net/projects/libjpeg-turbo/files/2.1.0 , since the existing lib64jpeg-devel-2.0.5-1.mga8.x86_64.rpm contains the above bug. Could you update the above package at least to version 2.0.6 or, even better, to the latest version 2.1.0 (it is already in Mageia-9)? Thank you in advance... Sincerely, Alex
Thank you for this detailed report. I could not find any relevant reference to "libjpeg-turbo"; the best I could find, following the 'devel' reference above, is: $ urpmq -l lib64jpeg-devel | grep turbo /usr/include/turbojpeg.h /usr/lib64/libturbojpeg.so /usr/lib64/pkgconfig/libturbojpeg.pc but the library is provided by: $ urpmq -l lib64turbojpeg0 | grep turbo /usr/lib64/libturbojpeg.so.0 /usr/lib64/libturbojpeg.so.0.2.0 $ urpmq --requires lib64jpeg-devel | grep turbo lib64turbojpeg0[== 1:2.0.5] $ rpm -q lib64turbojpeg0 lib64turbojpeg0-2.0.5-1.mga8 Assigning to DavidG who mostly does the libjpeg SRPM. @Alex : if & when this gets done as you ask, can you please test the result when it gets into updates_testing.
Summary: Corrupt JPEG data: premature end of data segment => Please update lib64jpeg-devel to version 2.0.6 (or the latest version 2.1.0 already in Cauldron) to fix a bug in 2.0.5Assignee: bugsquad => geiger.david68210
Hi, Lewis Smith. I will be happy to test new packages from updates_testing and report the results after testing. Thanks. :) Sincerely, Alex
I think it's safer for now to only go to 2.0.6 to get this fixed as there are a lot of changes between 2.0.6 and 2.1.0 that can cause some "interesting" fallout / bugs... so the packages to test are: SRPM: libjpeg-2.0.6-1.mga8.src.rpm i586: jpeg-progs-2.0.6-1.mga8.i586.rpm libjpeg62-2.0.6-1.mga8.i586.rpm libjpeg8-2.0.6-1.mga8.i586.rpm libjpeg-devel-2.0.6-1.mga8.i586.rpm libjpeg-static-devel-2.0.6-1.mga8.i586.rpm libturbojpeg0-2.0.6-1.mga8.i586.rpm x86_64: jpeg-progs-2.0.6-1.mga8.x86_64.rpm lib64jpeg62-2.0.6-1.mga8.x86_64.rpm lib64jpeg8-2.0.6-1.mga8.x86_64.rpm lib64jpeg-devel-2.0.6-1.mga8.x86_64.rpm lib64jpeg-static-devel-2.0.6-1.mga8.x86_64.rpm lib64turbojpeg0-2.0.6-1.mga8.x86_64.rpm
Assignee: geiger.david68210 => qa-bugs
Created attachment 12887 [details] DroidCam-v1.8.0-1+Wi-Fi
Hello, Thomas Backlund and Lewis Smith. Thank you very much for your cooperation! After updates there are no more errors and the broadcast from the smartphone camera works steadily (see the screenshot "DroidCam-v1.8.0-1+Wi-Fi" in the attachment). As a result, I successfully got rid of buying a new webcam for the ubiquitous mother-in-law. Hurray! :) I will leave a link to my packages here, maybe someone will need it: https://github.com/AKotov-dev/droidcam-rpm DroidCam Client: --- dkms-v4l2loopback_dc-0.0.2-0.mrx8.noarch.rpm droidcam-cli-1.8.0-1.mrx8.x86_64.rpm droidcam-1.8.0-1.mrx8.x86_64.rpm Lewis Smith, should I close this topic or should I leave it open while the packages are in update_testing? With respect, Alex
MGA8-64 Plasma on Lenovo B50 No installation issues. Did not test droidcam, might take me too long to figure everything out. Tested as before bug 25926 Comment 6, with slght difference in the results. $ wrjpgcom -comment "Experimental comment for QA" 0004.jpg > withcomment.jpg $ ls -als (superfluous omitted) totaal 8432 1696 -rw-r--r-- 1 tester8 tester8 1735012 nov 11 2013 0004.jpg 1696 -rw-r--r-- 1 tester8 tester8 1735044 aug 6 14:08 withcomment.jpg Size increased. $ rdjpgcom withcomment.jpg Experimental comment for QA $ jpegtran -flip horizontal 0006.jpg > flipped.jpg $ ls 0004.jpg 0006.jpg 0010.jpg flipped.jpg foto1.thumbnail foto2.thumbnail foto3.thumbnail 0004.thumbnail 0006.thumbnail 0010.thumbnail foto1.jpg foto2.jpg foto3.jpg withcomment.jpg $ jpegtran -flip vertical 0010.jpg > upsidedown.jpg $ jpegtran -transpose 0004.jpg > work1.jpg $ jpegtran -transverse 0004.jpg > work2.jpg $ jpegtran -grayscale 0006.jpg > greyscale.jpg $ jpegtran -perfect -rotate 90 work1.jpg > work3.jpg jpegtran: transformation is not perfect I have no idea why this result occurs, but anyway.... [tester8@mach5 20130124reuniespacedefense]$ jpegtran -rotate 90 work1.jpg > work3.jpg [tester8@mach5 20130124reuniespacedefense]$ jpegtran -crop 800x640+300+200 0010.jpg > work4.jpg All generated images look OK. Not sure whether this can be OK'ed without testing the droidcamt hingie.
CC: (none) => herman.viaene
Summary: Please update lib64jpeg-devel to version 2.0.6 (or the latest version 2.1.0 already in Cauldron) to fix a bug in 2.0.5 => Update libjpeg to version 2.0.6 to fix multiple issues with jpeg_skip_scanlines()
Advisory, added to svn: type: bugfix subject: Updated libjpeg packages fixes multiple issues with jpeg_skip_scanlines() src: 8: core: - libjpeg-2.0.6-1.mga8 description: | Updated libjpeg packa es fixes packages fixes multiple issues with jpeg_skip_scanlines(): Fixes segfaults or "Corrupt JPEG data: premature end of data segment" errors in jpeg_skip_scanlines() that occurred when decompressing 4:2:2 or 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that is, when setting cinfo.do_fancy_upsampling to FALSE.) jpeg_skip_scanlines() now throws an error if two-pass color quantization is enabled. Two-pass color quantization never worked properly with jpeg_skip_scanlines(). Fixed an issue whereby jpeg_skip_scanlines() always returned 0 when skipping past the end of an image. Fixed unexpected visual artifacts that occurred when using jpeg_crop_scanline() and interblock smoothing while decompressing only the DC scan of a progressive JPEG image. references: - https://bugs.mageia.org/show_bug.cgi?id=29321 - https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/2.0.6
Keywords: (none) => advisory
Keywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2021-0165.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
This update fixed CVE-2020-35538: https://ubuntu.com/security/notices/USN-5631-1