4 ms·
Yes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of c
by Pxtl 3y ago
Yes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of calculus when it comes to risk-vs-reward of embracing new standards for compression formats. When was the last time there was a serious vulnerability in major JPEG libs? Or even h.264, which is much newer? Yes, a .webp is like 2/3 the size of a similar JPEG, but for most people are JPEG image sizes a huge cause for concern? Once you're doing lossy compression you're already sacrificing fidelity for filesize so you don't see a lot of machine-crushing-huge JPEGs.
- peter_d_sherman 3y ago>When was the last time there was a serious vulnerability in major JPEG libs? 1) Kindly define "serious"... 2) Kindly define "major"... Also... why can't you ask the question you pose: "When was the last time there was a serious vulnerability in major JPEG libs?" ...with the words "serious" and "major" removed, i.e.: "When was the last time there was a vulnerability in JPEG libs?" ? As that might be a far better question if the generation of insight is desired... ?
- dureuill 3y agoThe most recent high severity vulnerability I could find in libjpeg is CVE-2016-6702[0]. If you're willing to count libjpeg-turbo, there's also CVE-2020-17541[1]. For h.264, if you're willing to count Firefox or gstreamer, we're talking CVE-2022-3266 or CVE-2021-3185 (the latter is even critical) [0]: https://nvd.nist.gov/vuln/detail/CVE-2016-6702 https://nvd.nist.gov/vuln/detail/CVE-2016-6702 [1]: https://nvd.nist.gov/vuln/detail/CVE-2020-17541 https://nvd.nist.gov/vuln/detail/CVE-2020-17541