diff options
Diffstat (limited to 'media/libjpeg')
| -rw-r--r-- | media/libjpeg/1050342.diff | 121 | ||||
| -rw-r--r-- | media/libjpeg/LICENSE.md | 54 | ||||
| -rw-r--r-- | media/libjpeg/MOZCHANGES | 28 | ||||
| -rw-r--r-- | media/libjpeg/README.ijg | 99 | ||||
| -rw-r--r--[-rwxr-xr-x] | media/libjpeg/README.md | 100 | ||||
| -rw-r--r-- | media/libjpeg/moz.build | 227 | ||||
| -rw-r--r-- | media/libjpeg/mozilla.diff | 67 |
7 files changed, 346 insertions, 350 deletions
diff --git a/media/libjpeg/1050342.diff b/media/libjpeg/1050342.diff deleted file mode 100644 index a409ca2c47..0000000000 --- a/media/libjpeg/1050342.diff +++ /dev/null @@ -1,121 +0,0 @@ -Bug 1050342. Fix a case where the fast huffman decoder in libjpeg-turbo can produce different results depending on how data is fed to it. - -This change comes from the blink repo https://codereview.appspot.com/229430043/ and is unlikely to be accepted upstream into libjpeg-turbo. - -diff --git jdhuff.c jdhuff.c ---- jdhuff.c -+++ jdhuff.c -@@ -664,17 +664,17 @@ decode_mcu_fast (j_decompress_ptr cinfo, - ASSIGN_STATE(state, entropy->saved); - - for (blkn = 0; blkn < cinfo->blocks_in_MCU; blkn++) { - JBLOCKROW block = MCU_data ? MCU_data[blkn] : NULL; - d_derived_tbl *dctbl = entropy->dc_cur_tbls[blkn]; - d_derived_tbl *actbl = entropy->ac_cur_tbls[blkn]; - register int s, k, r, l; - -- HUFF_DECODE_FAST(s, l, dctbl); -+ HUFF_DECODE_FAST(s, l, dctbl, slow_decode_mcu); - if (s) { - FILL_BIT_BUFFER_FAST - r = GET_BITS(s); - s = HUFF_EXTEND(r, s); - } - - if (entropy->dc_needed[blkn]) { - int ci = cinfo->MCU_membership[blkn]; -@@ -682,17 +682,17 @@ decode_mcu_fast (j_decompress_ptr cinfo, - state.last_dc_val[ci] = s; - if (block) - (*block)[0] = (JCOEF) s; - } - - if (entropy->ac_needed[blkn] && block) { - - for (k = 1; k < DCTSIZE2; k++) { -- HUFF_DECODE_FAST(s, l, actbl); -+ HUFF_DECODE_FAST(s, l, actbl, slow_decode_mcu); - r = s >> 4; - s &= 15; - - if (s) { - k += r; - FILL_BIT_BUFFER_FAST - r = GET_BITS(s); - s = HUFF_EXTEND(r, s); -@@ -701,33 +701,34 @@ decode_mcu_fast (j_decompress_ptr cinfo, - if (r != 15) break; - k += 15; - } - } - - } else { - - for (k = 1; k < DCTSIZE2; k++) { -- HUFF_DECODE_FAST(s, l, actbl); -+ HUFF_DECODE_FAST(s, l, actbl, slow_decode_mcu); - r = s >> 4; - s &= 15; - - if (s) { - k += r; - FILL_BIT_BUFFER_FAST - DROP_BITS(s); - } else { - if (r != 15) break; - k += 15; - } - } - } - } - - if (cinfo->unread_marker != 0) { -+slow_decode_mcu: - cinfo->unread_marker = 0; - return FALSE; - } - - br_state.bytes_in_buffer -= (buffer - br_state.next_input_byte); - br_state.next_input_byte = buffer; - BITREAD_SAVE_STATE(cinfo,entropy->bitstate); - ASSIGN_STATE(entropy->saved, state); -diff --git jdhuff.h jdhuff.h ---- jdhuff.h -+++ jdhuff.h -@@ -203,32 +203,34 @@ EXTERN(boolean) jpeg_fill_bit_buffer - } else { \ - slowlabel: \ - if ((result=jpeg_huff_decode(&state,get_buffer,bits_left,htbl,nb)) < 0) \ - { failaction; } \ - get_buffer = state.get_buffer; bits_left = state.bits_left; \ - } \ - } - --#define HUFF_DECODE_FAST(s,nb,htbl) \ -+#define HUFF_DECODE_FAST(s,nb,htbl,slowlabel) \ - FILL_BIT_BUFFER_FAST; \ - s = PEEK_BITS(HUFF_LOOKAHEAD); \ - s = htbl->lookup[s]; \ - nb = s >> HUFF_LOOKAHEAD; \ - /* Pre-execute the common case of nb <= HUFF_LOOKAHEAD */ \ - DROP_BITS(nb); \ - s = s & ((1 << HUFF_LOOKAHEAD) - 1); \ - if (nb > HUFF_LOOKAHEAD) { \ - /* Equivalent of jpeg_huff_decode() */ \ - /* Don't use GET_BITS() here because we don't want to modify bits_left */ \ - s = (get_buffer >> bits_left) & ((1 << (nb)) - 1); \ - while (s > htbl->maxcode[nb]) { \ - s <<= 1; \ - s |= GET_BITS(1); \ - nb++; \ - } \ -- s = htbl->pub->huffval[ (int) (s + htbl->valoffset[nb]) & 0xFF ]; \ -+ if (nb > 16) \ -+ goto slowlabel; \ -+ s = htbl->pub->huffval[ (int) (s + htbl->valoffset[nb]) ]; \ - } - - /* Out-of-line case for Huffman code fetching */ - EXTERN(int) jpeg_huff_decode - (bitread_working_state *state, register bit_buf_type get_buffer, - register int bits_left, d_derived_tbl *htbl, int min_bits); diff --git a/media/libjpeg/LICENSE.md b/media/libjpeg/LICENSE.md index 4623e29425..d753e1d76a 100644 --- a/media/libjpeg/LICENSE.md +++ b/media/libjpeg/LICENSE.md @@ -9,12 +9,12 @@ libjpeg-turbo is covered by three compatible BSD-style open source licenses: This license applies to the libjpeg API library and associated programs (any code inherited from libjpeg, and any modifications to that code.) -- The Modified (3-clause) BSD License, which is listed in - [turbojpeg.c](turbojpeg.c) +- The Modified (3-clause) BSD License, which is listed below - This license covers the TurboJPEG API library and associated programs. + This license covers the TurboJPEG API library and associated programs, as + well as the build system. -- The zlib License, which is listed in [simd/jsimdext.inc](simd/jsimdext.inc) +- The [zlib License](https://opensource.org/licenses/Zlib) This license is a subset of the other two, and it covers the libjpeg-turbo SIMD extensions. @@ -66,7 +66,7 @@ best of our understanding. 2. If your binary distribution includes or uses the TurboJPEG API, then your product documentation must include the text of the Modified BSD - License. + License (see below.) **Origin** - Clause 2 of the Modified BSD License @@ -86,3 +86,47 @@ best of our understanding. - IJG License - Modified BSD License - zlib License + + +The Modified (3-clause) BSD License +=================================== + +Copyright (C)2009-2022 D. R. Commander. All Rights Reserved.<br> +Copyright (C)2015 Viktor Szathmáry. All Rights Reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: + +- Redistributions of source code must retain the above copyright notice, + this list of conditions and the following disclaimer. +- Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. +- Neither the name of the libjpeg-turbo Project nor the names of its + contributors may be used to endorse or promote products derived from this + software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS", +AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE +LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +POSSIBILITY OF SUCH DAMAGE. + + +Why Three Licenses? +=================== + +The zlib License could have been used instead of the Modified (3-clause) BSD +License, and since the IJG License effectively subsumes the distribution +conditions of the zlib License, this would have effectively placed +libjpeg-turbo binary distributions under the IJG License. However, the IJG +License specifically refers to the Independent JPEG Group and does not extend +attribution and endorsement protections to other entities. Thus, it was +desirable to choose a license that granted us the same protections for new code +that were granted to the IJG for code derived from their software. diff --git a/media/libjpeg/MOZCHANGES b/media/libjpeg/MOZCHANGES index 6e7824cdd7..4e65df2222 100644 --- a/media/libjpeg/MOZCHANGES +++ b/media/libjpeg/MOZCHANGES @@ -48,6 +48,34 @@ To upgrade to a new revision of libjpeg-turbo, do the following: $ hg addremove +== February 28, 2022 (libjpeg-turbo v2.1.3 c5f269eb9665435271c05fbcaf8721fa58e9eafa 2022-02-25) == + +* Updated to v2.1.3 release. + +== September 9, 2021 (libjpeg-turbo v2.1.1 0a9b9721782d3a60a5c16c8c9a7abf3d4b1ecd42 2020-08-10) == + +* Updated to v2.1.1 release. + +== November 19, 2020 (libjpeg-turbo v2.0.6 10ba6ed3365615ed5c2995fe2d240cb2d5000173 2020-11-16) == + +* Updated to v2.0.6 release. + +== January 6, 2020 (libjpeg-turbo v2.0.4 166e34213e4f4e2363ce058a7bcc69fd03e38b76 2019-12-31) == + +* Updated to v2.0.4 release. + +== September 5, 2019 (libjpeg-turbo v2.0.3 5db6a6819d0f904e0b58f34ae928fea234adb1a0 2019-09-04) == + +* Updated to v2.0.3 release. + +== October 4, 2018 (libjpeg-turbo v2.0.0 574f3a772c96dc9db2c98ef24706feb3f6dbda9a 2018-06-27) == + +* Updated to v2.0.0 release. + +== July 13, 2017 (libjpeg-turbo v1.5.2 e5c1613ccdfeffcd060fd94248b7c8ac7c0cfb0f 2017-08-09) == + +* Updated to v1.5.2 release. + == September 22, 2016 (libjpeg-turbo v1.5.1 cb88e5da8003afcdc443b787fdcb77285e5a8a02 2016-09-20) == * Updated to v1.5.1 release. diff --git a/media/libjpeg/README.ijg b/media/libjpeg/README.ijg index 9c450ceb07..9453c19501 100644 --- a/media/libjpeg/README.ijg +++ b/media/libjpeg/README.ijg @@ -43,7 +43,7 @@ User documentation: change.log Version-to-version change highlights. Programmer and internal documentation: libjpeg.txt How to use the JPEG library in your own programs. - example.c Sample code for calling the JPEG library. + example.txt Sample code for calling the JPEG library. structure.txt Overview of the JPEG library's internal structure. coderules.txt Coding style rules --- please read if you contribute code. @@ -128,7 +128,7 @@ with respect to this software, its quality, accuracy, merchantability, or fitness for a particular purpose. This software is provided "AS IS", and you, its user, assume the entire risk as to its quality and accuracy. -This software is copyright (C) 1991-2016, Thomas G. Lane, Guido Vollbeding. +This software is copyright (C) 1991-2020, Thomas G. Lane, Guido Vollbeding. All Rights Reserved except as specified below. Permission is hereby granted to use, copy, modify, and distribute this @@ -159,25 +159,6 @@ commercial products, provided that all warranty or liability claims are assumed by the product vendor. -The Unix configuration script "configure" was produced with GNU Autoconf. -It is copyright by the Free Software Foundation but is freely distributable. -The same holds for its supporting scripts (config.guess, config.sub, -ltmain.sh). Another support script, install-sh, is copyright by X Consortium -but is also freely distributable. - -The IJG distribution formerly included code to read and write GIF files. -To avoid entanglement with the Unisys LZW patent (now expired), GIF reading -support has been removed altogether, and the GIF writer has been simplified -to produce "uncompressed GIFs". This technique does not use the LZW -algorithm; the resulting GIF files are larger than usual, but are readable -by all standard GIF decoders. - -We are required to state that - "The Graphics Interchange Format(c) is the Copyright property of - CompuServe Incorporated. GIF(sm) is a Service Mark property of - CompuServe Incorporated." - - REFERENCES ========== @@ -185,8 +166,8 @@ We recommend reading one or more of these references before trying to understand the innards of the JPEG software. The best short technical introduction to the JPEG compression algorithm is - Wallace, Gregory K. "The JPEG Still Picture Compression Standard", - Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44. + Wallace, Gregory K. "The JPEG Still Picture Compression Standard", + Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44. (Adjacent articles in that issue discuss MPEG motion picture compression, applications of JPEG, and related topics.) If you don't have the CACM issue handy, a PDF file containing a revised version of Wallace's article is @@ -220,21 +201,21 @@ Continuous-tone Still Images, Part 2: Compliance testing" and has document numbers ISO/IEC IS 10918-2, ITU-T T.83. The JPEG standard does not specify all details of an interchangeable file -format. For the omitted details we follow the "JFIF" conventions, revision -1.02. JFIF 1.02 has been adopted as an Ecma International Technical Report -and thus received a formal publication status. It is available as a free -download in PDF format from -http://www.ecma-international.org/publications/techreports/E-TR-098.htm. -A PostScript version of the JFIF document is available at -http://www.ijg.org/files/jfif.ps.gz. There is also a plain text version at -http://www.ijg.org/files/jfif.txt.gz, but it is missing the figures. - -The TIFF 6.0 file format specification can be obtained by FTP from -ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation scheme -found in the TIFF 6.0 spec of 3-June-92 has a number of serious problems. -IJG does not recommend use of the TIFF 6.0 design (TIFF Compression tag 6). -Instead, we recommend the JPEG design proposed by TIFF Technical Note #2 -(Compression tag 7). Copies of this Note can be obtained from +format. For the omitted details, we follow the "JFIF" conventions, revision +1.02. JFIF version 1 has been adopted as ISO/IEC 10918-5 (05/2013) and +Recommendation ITU-T T.871 (05/2011): Information technology - Digital +compression and coding of continuous-tone still images: JPEG File Interchange +Format (JFIF). It is available as a free download in PDF file format from +https://www.iso.org/standard/54989.html and http://www.itu.int/rec/T-REC-T.871. +A PDF file of the older JFIF 1.02 specification is available at +http://www.w3.org/Graphics/JPEG/jfif3.pdf. + +The TIFF 6.0 file format specification can be obtained from +http://mirrors.ctan.org/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation +scheme found in the TIFF 6.0 spec of 3-June-92 has a number of serious +problems. IJG does not recommend use of the TIFF 6.0 design (TIFF Compression +tag 6). Instead, we recommend the JPEG design proposed by TIFF Technical Note +#2 (Compression tag 7). Copies of this Note can be obtained from http://www.ijg.org/files/. It is expected that the next revision of the TIFF spec will replace the 6.0 JPEG design with the Note's design. Although IJG's own code does not support TIFF/JPEG, the free libtiff library @@ -249,28 +230,26 @@ The most recent released version can always be found there in directory "files". The JPEG FAQ (Frequently Asked Questions) article is a source of some -general information about JPEG. -It is available on the World Wide Web at http://www.faqs.org/faqs/jpeg-faq/ -and other news.answers archive sites, including the official news.answers -archive at rtfm.mit.edu: ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/. -If you don't have Web or FTP access, send e-mail to mail-server@rtfm.mit.edu -with body - send usenet/news.answers/jpeg-faq/part1 - send usenet/news.answers/jpeg-faq/part2 - - -FILE FORMAT WARS -================ - -The ISO/IEC JTC1/SC29/WG1 standards committee (also known as JPEG, together -with ITU-T SG16) currently promotes different formats containing the name -"JPEG" which are incompatible with original DCT-based JPEG. IJG therefore does -not support these formats (see REFERENCES). Indeed, one of the original -reasons for developing this free software was to help force convergence on -common, interoperable format standards for JPEG files. -Don't use an incompatible file format! -(In any case, our decoder will remain capable of reading existing JPEG -image files indefinitely.) +general information about JPEG. It is available at +http://www.faqs.org/faqs/jpeg-faq. + + +FILE FORMAT COMPATIBILITY +========================= + +This software implements ITU T.81 | ISO/IEC 10918 with some extensions from +ITU T.871 | ISO/IEC 10918-5 (JPEG File Interchange Format-- see REFERENCES). +Informally, the term "JPEG image" or "JPEG file" most often refers to JFIF or +a subset thereof, but there are other formats containing the name "JPEG" that +are incompatible with the DCT-based JPEG standard or with JFIF (for instance, +JPEG 2000 and JPEG XR). This software therefore does not support these +formats. Indeed, one of the original reasons for developing this free software +was to help force convergence on a common, interoperable format standard for +JPEG files. + +JFIF is a minimal or "low end" representation. TIFF/JPEG (TIFF revision 6.0 as +modified by TIFF Technical Note #2) can be used for "high end" applications +that need to record a lot of additional data about an image. TO DO diff --git a/media/libjpeg/README.md b/media/libjpeg/README.md index ca8866e06c..01e391ea7c 100755..100644 --- a/media/libjpeg/README.md +++ b/media/libjpeg/README.md @@ -1,13 +1,14 @@ Background ========== -libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2, -NEON, AltiVec) to accelerate baseline JPEG compression and decompression on -x86, x86-64, ARM, and PowerPC systems. On such systems, libjpeg-turbo is -generally 2-6x as fast as libjpeg, all else being equal. On other types of -systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by -virtue of its highly-optimized Huffman coding routines. In many cases, the -performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs. +libjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate +baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and +MIPS systems, as well as progressive JPEG compression on x86, x86-64, and Arm +systems. On such systems, libjpeg-turbo is generally 2-6x as fast as libjpeg, +all else being equal. On other types of systems, libjpeg-turbo can still +outperform libjpeg by a significant amount, by virtue of its highly-optimized +Huffman coding routines. In many cases, the performance of libjpeg-turbo +rivals that of proprietary high-speed JPEG codecs. libjpeg-turbo implements both the traditional libjpeg API as well as the less powerful but more straightforward TurboJPEG API. libjpeg-turbo also features @@ -42,21 +43,25 @@ Using libjpeg-turbo libjpeg-turbo includes two APIs that can be used to compress and decompress JPEG images: -- **TurboJPEG API** +- **TurboJPEG API**<br> This API provides an easy-to-use interface for compressing and decompressing JPEG images in memory. It also provides some functionality that would not be straightforward to achieve using the underlying libjpeg API, such as generating planar YUV images and performing multiple simultaneous lossless transforms on an image. The Java interface for libjpeg-turbo is written on - top of the TurboJPEG API. + top of the TurboJPEG API. The TurboJPEG API is recommended for first-time + users of libjpeg-turbo. Refer to [tjexample.c](tjexample.c) and + [TJExample.java](java/TJExample.java) for examples of its usage and to + <http://libjpeg-turbo.org/Documentation/Documentation> for API documentation. -- **libjpeg API** +- **libjpeg API**<br> This is the de facto industry-standard API for compressing and decompressing JPEG images. It is more difficult to use than the TurboJPEG API but also more powerful. The libjpeg API implementation in libjpeg-turbo is both API/ABI-compatible and mathematically compatible with libjpeg v6b. It can also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8 - (see below.) + (see below.) Refer to [cjpeg.c](cjpeg.c) and [djpeg.c](djpeg.c) for examples + of its usage and to [libjpeg.txt](libjpeg.txt) for API documentation. There is no significant performance advantage to either API when both are used to perform similar operations. @@ -130,28 +135,27 @@ without recompiling. libjpeg-turbo does not claim to support all of the libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all cases (see below.) -By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, or -an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build a -version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that -programs that are built against libjpeg v7 or v8 can be run with libjpeg-turbo. -The following section describes which libjpeg v7+ features are supported and -which aren't. +By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you +can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so +that programs that are built against libjpeg v7 or v8 can be run with +libjpeg-turbo. The following section describes which libjpeg v7+ features are +supported and which aren't. ### Support for libjpeg v7 and v8 Features #### Fully supported -- **libjpeg: IDCT scaling extensions in decompressor** +- **libjpeg API: IDCT scaling extensions in decompressor**<br> libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8, 1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4 and 1/2 are SIMD-accelerated.) -- **libjpeg: Arithmetic coding** +- **libjpeg API: Arithmetic coding** -- **libjpeg: In-memory source and destination managers** +- **libjpeg API: In-memory source and destination managers**<br> See notes below. -- **cjpeg: Separate quality settings for luminance and chrominance** +- **cjpeg: Separate quality settings for luminance and chrominance**<br> Note that the libpjeg v7+ API was extended to accommodate this feature only for convenience purposes. It has always been possible to implement this feature with libjpeg v6b (see rdswitch.c for an example.) @@ -175,19 +179,19 @@ which aren't. NOTE: As of this writing, extensive research has been conducted into the usefulness of DCT scaling as a means of data reduction and SmartScale as a -means of quality improvement. The reader is invited to peruse the research at -<http://www.libjpeg-turbo.org/About/SmartScale> and draw his/her own conclusions, +means of quality improvement. Readers are invited to peruse the research at +<http://www.libjpeg-turbo.org/About/SmartScale> and draw their own conclusions, but it is the general belief of our project that these features have not demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo. -- **libjpeg: DCT scaling in compressor** +- **libjpeg API: DCT scaling in compressor**<br> `cinfo.scale_num` and `cinfo.scale_denom` are silently ignored. There is no technical reason why DCT scaling could not be supported when emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and 8/9 would be available, which is of limited usefulness. -- **libjpeg: SmartScale** +- **libjpeg API: SmartScale**<br> `cinfo.block_size` is silently ignored. SmartScale is an extension to the JPEG format that allows for DCT block sizes other than 8x8. Providing support for this new format would be @@ -200,15 +204,15 @@ demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo. interest in providing this feature would be as a means of supporting additional DCT scaling factors. -- **libjpeg: Fancy downsampling in compressor** +- **libjpeg API: Fancy downsampling in compressor**<br> `cinfo.do_fancy_downsampling` is silently ignored. This requires the DCT scaling feature, which is not supported. -- **jpegtran: Scaling** +- **jpegtran: Scaling**<br> This requires both the DCT scaling and SmartScale features, which are not supported. -- **Lossless RGB JPEG files** +- **Lossless RGB JPEG files**<br> This requires the SmartScale feature, which is not supported. ### What About libjpeg v9? @@ -226,7 +230,7 @@ generally accomplish anything that can't already be accomplished better with existing, standard lossless formats. Therefore, at this time it is our belief that there is not sufficient technical justification for software projects to upgrade from libjpeg v8 to libjpeg v9, and thus there is not sufficient -echnical justification for us to emulate the libjpeg v9 ABI. +technical justification for us to emulate the libjpeg v9 ABI. In-Memory Source/Destination Managers ------------------------------------- @@ -242,15 +246,14 @@ don't, and it allows those functions to be provided in the "official" libjpeg-turbo binaries. Those who are concerned about maintaining strict conformance with the libjpeg -v6b or v7 API can pass an argument of `--without-mem-srcdst` to `configure` or -an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to building -libjpeg-turbo. This will restore the pre-1.3 behavior, in which +v6b or v7 API can pass an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to +building libjpeg-turbo. This will restore the pre-1.3 behavior, in which `jpeg_mem_src()` and `jpeg_mem_dest()` are only included when emulating the libjpeg v8 API/ABI. On Un*x systems, including the in-memory source/destination managers changes -the dynamic library version from 62.0.0 to 62.1.0 if using libjpeg v6b API/ABI -emulation and from 7.0.0 to 7.1.0 if using libjpeg v7 API/ABI emulation. +the dynamic library version from 62.2.0 to 62.3.0 if using libjpeg v6b API/ABI +emulation and from 7.2.0 to 7.3.0 if using libjpeg v7 API/ABI emulation. Note that, on most Un*x systems, the dynamic linker will not look for a function in a library until that function is actually used. Thus, if a program @@ -284,12 +287,13 @@ following reasons: (and slightly faster) floating point IDCT algorithm introduced in libjpeg v8a as opposed to the algorithm used in libjpeg v6b. It should be noted, however, that this algorithm basically brings the accuracy of the floating - point IDCT in line with the accuracy of the slow integer IDCT. The floating - point DCT/IDCT algorithms are mainly a legacy feature, and they do not - produce significantly more accuracy than the slow integer algorithms (to put - numbers on this, the typical difference in PNSR between the two algorithms - is less than 0.10 dB, whereas changing the quality level by 1 in the upper - range of the quality scale is typically more like a 1.0 dB difference.) + point IDCT in line with the accuracy of the accurate integer IDCT. The + floating point DCT/IDCT algorithms are mainly a legacy feature, and they do + not produce significantly more accuracy than the accurate integer algorithms + (to put numbers on this, the typical difference in PNSR between the two + algorithms is less than 0.10 dB, whereas changing the quality level by 1 in + the upper range of the quality scale is typically more like a 1.0 dB + difference.) - If the floating point algorithms in libjpeg-turbo are not implemented using SIMD instructions on a particular platform, then the accuracy of the @@ -326,7 +330,7 @@ in a way that makes the rest of the libjpeg infrastructure happy, so it is necessary to use the slow Huffman decoder when decompressing a JPEG image that has restart markers. This can cause the decompression performance to drop by as much as 20%, but the performance will still be much greater than that of -libjpeg. Many consumer packages, such as PhotoShop, use restart markers when +libjpeg. Many consumer packages, such as Photoshop, use restart markers when generating JPEG images, so images generated by those programs will experience this issue. @@ -337,5 +341,17 @@ The algorithm used by the SIMD-accelerated quantization function cannot produce correct results whenever the fast integer forward DCT is used along with a JPEG quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization function in those cases. This causes performance to drop by as much as 40%. -It is therefore strongly advised that you use the slow integer forward DCT +It is therefore strongly advised that you use the accurate integer forward DCT whenever encoding images with a JPEG quality of 98 or higher. + + +Memory Debugger Pitfalls +======================== + +Valgrind and Memory Sanitizer (MSan) can generate false positives +(specifically, incorrect reports of uninitialized memory accesses) when used +with libjpeg-turbo's SIMD extensions. It is generally recommended that the +SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0` +to `cmake` when configuring the build or by setting the environment variable +`JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind, +MSan, or other memory debuggers. diff --git a/media/libjpeg/moz.build b/media/libjpeg/moz.build index 6519c30fbd..0da04dabc3 100644 --- a/media/libjpeg/moz.build +++ b/media/libjpeg/moz.build @@ -1,4 +1,5 @@ # -*- Mode: python; indent-tabs-mode: nil; tab-width: 40 -*- +# vim: set filetype=python: # This Source Code Form is subject to the terms of the Mozilla Public # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/. @@ -22,6 +23,7 @@ SOURCES += [ 'jdcolor.c', 'jddctmgr.c', 'jdhuff.c', + 'jdicc.c', 'jdinput.c', 'jdmainct.c', 'jdmarker.c', @@ -54,6 +56,7 @@ SOURCES += [ 'jccolor.c', 'jcdctmgr.c', 'jchuff.c', + 'jcicc.c', 'jcinit.c', 'jcmainct.c', 'jcmarker.c', @@ -70,88 +73,188 @@ if CONFIG['LIBJPEG_TURBO_USE_YASM']: if CONFIG['LIBJPEG_TURBO_ASFLAGS']: if CONFIG['CPU_ARCH'] == 'arm': + LOCAL_INCLUDES += [ + '/media/libjpeg/simd/arm', + '/media/libjpeg/simd/arm/aarch32', + ] SOURCES += [ - 'simd/jsimd_arm.c', - 'simd/jsimd_arm_neon.S', + 'simd/arm/aarch32/jchuff-neon.c', + 'simd/arm/aarch32/jsimd.c', + 'simd/arm/aarch32/jsimd_neon.S', + 'simd/arm/jcgray-neon.c', + 'simd/arm/jcphuff-neon.c', + 'simd/arm/jcsample-neon.c', + 'simd/arm/jdcolor-neon.c', + 'simd/arm/jdmerge-neon.c', + 'simd/arm/jdsample-neon.c', + 'simd/arm/jfdctfst-neon.c', + 'simd/arm/jfdctint-neon.c', + 'simd/arm/jidctred-neon.c', + 'simd/arm/jquanti-neon.c', ] elif CONFIG['CPU_ARCH'] == 'aarch64': + LOCAL_INCLUDES += [ + '/media/libjpeg/simd/arm', + '/media/libjpeg/simd/arm/aarch64', + ] + SOURCES += [ + 'simd/arm/aarch64/jsimd.c', + 'simd/arm/aarch64/jsimd_neon.S', + 'simd/arm/jcgray-neon.c', + 'simd/arm/jcphuff-neon.c', + 'simd/arm/jcsample-neon.c', + 'simd/arm/jdmerge-neon.c', + 'simd/arm/jdsample-neon.c', + 'simd/arm/jfdctfst-neon.c', + 'simd/arm/jidctfst-neon.c', + 'simd/arm/jidctred-neon.c', + 'simd/arm/jquanti-neon.c', + ] + elif CONFIG['CPU_ARCH'] == 'mips32': SOURCES += [ - 'simd/jsimd_arm64.c', - 'simd/jsimd_arm64_neon.S', + 'simd/mips/jsimd.c', + 'simd/mips/jsimd_dspr2.S', ] - elif CONFIG['CPU_ARCH'] == 'mips': + if CONFIG['CC_TYPE'] == 'clang': + SOURCES['simd/mips/jsimd_dspr2.S'].flags += [ + '-fno-integrated-as', + ] + elif CONFIG['CPU_ARCH'] == 'mips64': + LOCAL_INCLUDES += ['/media/libjpeg/simd/mips64'] SOURCES += [ - 'simd/jsimd_mips.c', - 'simd/jsimd_mips_dspr2.S', + 'simd/mips64/jccolor-mmi.c', + 'simd/mips64/jcgray-mmi.c', + 'simd/mips64/jcsample-mmi.c', + 'simd/mips64/jdcolor-mmi.c', + 'simd/mips64/jdmerge-mmi.c', + 'simd/mips64/jdsample-mmi.c', + 'simd/mips64/jfdctfst-mmi.c', + 'simd/mips64/jfdctint-mmi.c', + 'simd/mips64/jidctfst-mmi.c', + 'simd/mips64/jidctint-mmi.c', + 'simd/mips64/jquanti-mmi.c', + 'simd/mips64/jsimd.c', ] elif CONFIG['CPU_ARCH'] == 'x86_64': SOURCES += [ - 'simd/jccolor-sse2-64.asm', - 'simd/jcgray-sse2-64.asm', - 'simd/jchuff-sse2-64.asm', - 'simd/jcsample-sse2-64.asm', - 'simd/jdcolor-sse2-64.asm', - 'simd/jdmerge-sse2-64.asm', - 'simd/jdsample-sse2-64.asm', - 'simd/jfdctflt-sse-64.asm', - 'simd/jfdctfst-sse2-64.asm', - 'simd/jfdctint-sse2-64.asm', - 'simd/jidctflt-sse2-64.asm', - 'simd/jidctfst-sse2-64.asm', - 'simd/jidctint-sse2-64.asm', - 'simd/jidctred-sse2-64.asm', - 'simd/jquantf-sse2-64.asm', - 'simd/jquanti-sse2-64.asm', - 'simd/jsimd_x86_64.c', + 'simd/x86_64/jccolor-avx2.asm', + 'simd/x86_64/jccolor-sse2.asm', + 'simd/x86_64/jcgray-avx2.asm', + 'simd/x86_64/jcgray-sse2.asm', + 'simd/x86_64/jchuff-sse2.asm', + 'simd/x86_64/jcphuff-sse2.asm', + 'simd/x86_64/jcsample-avx2.asm', + 'simd/x86_64/jcsample-sse2.asm', + 'simd/x86_64/jdcolor-avx2.asm', + 'simd/x86_64/jdcolor-sse2.asm', + 'simd/x86_64/jdmerge-avx2.asm', + 'simd/x86_64/jdmerge-sse2.asm', + 'simd/x86_64/jdsample-avx2.asm', + 'simd/x86_64/jdsample-sse2.asm', + 'simd/x86_64/jfdctflt-sse.asm', + 'simd/x86_64/jfdctfst-sse2.asm', + 'simd/x86_64/jfdctint-avx2.asm', + 'simd/x86_64/jfdctint-sse2.asm', + 'simd/x86_64/jidctflt-sse2.asm', + 'simd/x86_64/jidctfst-sse2.asm', + 'simd/x86_64/jidctint-avx2.asm', + 'simd/x86_64/jidctint-sse2.asm', + 'simd/x86_64/jidctred-sse2.asm', + 'simd/x86_64/jquantf-sse2.asm', + 'simd/x86_64/jquanti-avx2.asm', + 'simd/x86_64/jquanti-sse2.asm', + 'simd/x86_64/jsimd.c', + 'simd/x86_64/jsimdcpu.asm', ] elif CONFIG['CPU_ARCH'] == 'x86': SOURCES += [ - 'simd/jccolor-mmx.asm', - 'simd/jccolor-sse2.asm', - 'simd/jcgray-mmx.asm', - 'simd/jcgray-sse2.asm', - 'simd/jchuff-sse2.asm', - 'simd/jcsample-mmx.asm', - 'simd/jcsample-sse2.asm', - 'simd/jdcolor-mmx.asm', - 'simd/jdcolor-sse2.asm', - 'simd/jdmerge-mmx.asm', - 'simd/jdmerge-sse2.asm', - 'simd/jdsample-mmx.asm', - 'simd/jdsample-sse2.asm', - 'simd/jfdctflt-3dn.asm', - 'simd/jfdctflt-sse.asm', - 'simd/jfdctfst-mmx.asm', - 'simd/jfdctfst-sse2.asm', - 'simd/jfdctint-mmx.asm', - 'simd/jfdctint-sse2.asm', - 'simd/jidctflt-3dn.asm', - 'simd/jidctflt-sse.asm', - 'simd/jidctflt-sse2.asm', - 'simd/jidctfst-mmx.asm', - 'simd/jidctfst-sse2.asm', - 'simd/jidctint-mmx.asm', - 'simd/jidctint-sse2.asm', - 'simd/jidctred-mmx.asm', - 'simd/jidctred-sse2.asm', - 'simd/jquant-3dn.asm', - 'simd/jquant-mmx.asm', - 'simd/jquant-sse.asm', - 'simd/jquantf-sse2.asm', - 'simd/jquanti-sse2.asm', - 'simd/jsimd_i386.c', - 'simd/jsimdcpu.asm', + 'simd/i386/jccolor-avx2.asm', + 'simd/i386/jccolor-mmx.asm', + 'simd/i386/jccolor-sse2.asm', + 'simd/i386/jcgray-avx2.asm', + 'simd/i386/jcgray-mmx.asm', + 'simd/i386/jcgray-sse2.asm', + 'simd/i386/jchuff-sse2.asm', + 'simd/i386/jcphuff-sse2.asm', + 'simd/i386/jcsample-avx2.asm', + 'simd/i386/jcsample-mmx.asm', + 'simd/i386/jcsample-sse2.asm', + 'simd/i386/jdcolor-avx2.asm', + 'simd/i386/jdcolor-mmx.asm', + 'simd/i386/jdcolor-sse2.asm', + 'simd/i386/jdmerge-avx2.asm', + 'simd/i386/jdmerge-mmx.asm', + 'simd/i386/jdmerge-sse2.asm', + 'simd/i386/jdsample-avx2.asm', + 'simd/i386/jdsample-mmx.asm', + 'simd/i386/jdsample-sse2.asm', + 'simd/i386/jfdctflt-3dn.asm', + 'simd/i386/jfdctflt-sse.asm', + 'simd/i386/jfdctfst-mmx.asm', + 'simd/i386/jfdctfst-sse2.asm', + 'simd/i386/jfdctint-avx2.asm', + 'simd/i386/jfdctint-mmx.asm', + 'simd/i386/jfdctint-sse2.asm', + 'simd/i386/jidctflt-3dn.asm', + 'simd/i386/jidctflt-sse.asm', + 'simd/i386/jidctflt-sse2.asm', + 'simd/i386/jidctfst-mmx.asm', + 'simd/i386/jidctfst-sse2.asm', + 'simd/i386/jidctint-avx2.asm', + 'simd/i386/jidctint-mmx.asm', + 'simd/i386/jidctint-sse2.asm', + 'simd/i386/jidctred-mmx.asm', + 'simd/i386/jidctred-sse2.asm', + 'simd/i386/jquant-3dn.asm', + 'simd/i386/jquant-mmx.asm', + 'simd/i386/jquant-sse.asm', + 'simd/i386/jquantf-sse2.asm', + 'simd/i386/jquanti-avx2.asm', + 'simd/i386/jquanti-sse2.asm', + 'simd/i386/jsimd.c', + 'simd/i386/jsimdcpu.asm', ] +elif CONFIG['CPU_ARCH'].startswith('ppc'): + # PowerPC has no assembly files, but still needs its own headers. + LOCAL_INCLUDES += ['/media/libjpeg/simd/powerpc'] + + # For libjpeg's internal runtime detection to work, jsimd.c must NOT + # be compiled with -maltivec (otherwise it gets statically set), + # but everything else should be. If -maltivec was already + # specified in .mozconfig, though, then this won't harm anything. + ppc_vmx_sources = [ + 'simd/powerpc/jccolor-altivec.c', + 'simd/powerpc/jcgray-altivec.c', + 'simd/powerpc/jcsample-altivec.c', + 'simd/powerpc/jdcolor-altivec.c', + 'simd/powerpc/jdmerge-altivec.c', + 'simd/powerpc/jdsample-altivec.c', + 'simd/powerpc/jfdctfst-altivec.c', + 'simd/powerpc/jfdctint-altivec.c', + 'simd/powerpc/jidctfst-altivec.c', + 'simd/powerpc/jidctint-altivec.c', + 'simd/powerpc/jquanti-altivec.c', + ] + SOURCES += ppc_vmx_sources + SOURCES += [ + 'simd/powerpc/jsimd.c', + ] + for srcfile in ppc_vmx_sources: + SOURCES[srcfile].flags += CONFIG['PPC_VMX_FLAGS'] else: # No SIMD support? SOURCES += [ 'jsimd_none.c', ] ASFLAGS += CONFIG['LIBJPEG_TURBO_ASFLAGS'] -ASFLAGS += ['-I%s/media/libjpeg/simd/' % TOPSRCDIR] -if CONFIG['GKMEDIAS_SHARED_LIBRARY']: - NO_VISIBILITY_FLAGS = True +# Make sure the x86 & x86-64 ASM files can see the necessary includes. +if CONFIG['CPU_ARCH'] == 'x86': + ASFLAGS += ['-I%s/media/libjpeg/simd/nasm/' % TOPSRCDIR] + ASFLAGS += ['-I%s/media/libjpeg/simd/i386/' % TOPSRCDIR] +if CONFIG['CPU_ARCH'] == 'x86_64': + ASFLAGS += ['-I%s/media/libjpeg/simd/nasm/' % TOPSRCDIR] + ASFLAGS += ['-I%s/media/libjpeg/simd/x86_64/' % TOPSRCDIR] # We allow warnings for third-party code that can be updated from upstream. ALLOW_COMPILER_WARNINGS = True diff --git a/media/libjpeg/mozilla.diff b/media/libjpeg/mozilla.diff index 24b235b401..bc1bcb3066 100644 --- a/media/libjpeg/mozilla.diff +++ b/media/libjpeg/mozilla.diff @@ -1,32 +1,7 @@ -diff --git jmemmgr.c jmemmgr.c ---- jmemmgr.c -+++ jmemmgr.c -@@ -28,16 +28,17 @@ - */ - - #define JPEG_INTERNALS - #define AM_MEMORY_MANAGER /* we define jvirt_Xarray_control structs */ - #include "jinclude.h" - #include "jpeglib.h" - #include "jmemsys.h" /* import the system-dependent declarations */ - #include <stdint.h> -+#include <limits.h> /* some NDKs define SIZE_MAX in limits.h */ - - #ifndef NO_GETENV - #ifndef HAVE_STDLIB_H /* <stdlib.h> should declare getenv() */ - extern char *getenv (const char *name); - #endif - #endif - - diff --git jmorecfg.h jmorecfg.h --- jmorecfg.h +++ jmorecfg.h -@@ -9,16 +9,17 @@ - * For conditions of distribution and use, see the accompanying README.ijg - * file. - * - * This file contains additional configuration options that customize the +@@ -13,8 +13,9 @@ * JPEG software for special applications or support machine-dependent * optimizations. Most users will not need to touch this file. */ @@ -35,29 +10,13 @@ diff --git jmorecfg.h jmorecfg.h /* * Maximum number of components (color channels) allowed in JPEG image. - * To meet the letter of the JPEG spec, set this to 255. However, darn - * few applications need more than 4 channels (maybe 5 for CMYK + alpha - * mask). We recommend 10 as a reasonable compromise; use 4 if you are - * really short on memory. (Each allowed component costs a hundred or so - * bytes of storage, whether actually used in an image or not.) -@@ -118,39 +119,25 @@ typedef char JOCTET; - * They must be at least as wide as specified; but making them too big - * won't cost a huge amount of memory, so we don't provide special - * extraction code like we did for JSAMPLE. (In other words, these - * typedefs live at a different point on the speed/space tradeoff curve.) + * To meet the letter of Rec. ITU-T T.81 | ISO/IEC 10918-1, set this to 255. +@@ -95,23 +96,17 @@ typedef unsigned char JOCTET; */ /* UINT8 must hold at least the values 0..255. */ --#ifdef HAVE_UNSIGNED_CHAR -typedef unsigned char UINT8; --#else /* not HAVE_UNSIGNED_CHAR */ --#ifdef __CHAR_UNSIGNED__ --typedef char UINT8; --#else /* not __CHAR_UNSIGNED__ */ --typedef short UINT8; --#endif /* __CHAR_UNSIGNED__ */ --#endif /* HAVE_UNSIGNED_CHAR */ +typedef uint8_t UINT8; /* UINT16 must hold at least the values 0..65535. */ @@ -79,23 +38,15 @@ diff --git jmorecfg.h jmorecfg.h /* INT32 must hold at least signed 32-bit values. * * NOTE: The INT32 typedef dates back to libjpeg v5 (1994.) Integers were - * sometimes 16-bit back then (MS-DOS), which is why INT32 is typedef'd to - * long. It also wasn't common (or at least as common) in 1994 for INT32 to be - * defined by platform headers. Since then, however, INT32 is defined in - * several other common places: -@@ -167,25 +154,17 @@ typedef short INT16; - * This is a recipe for conflict, since "long" and "int" aren't always - * compatible types. Since the definition of INT32 has technically been part - * of the libjpeg API for more than 20 years, we can't remove it, but we do not - * use it internally any longer. We instead define a separate type (JLONG) +@@ -136,17 +131,9 @@ typedef short INT16; * for internal use, which ensures that internal behavior will always be the * same regardless of any external headers that may be included. */ -#ifndef XMD_H /* X11/xmd.h correctly defines INT32 */ --#ifndef _BASETSD_H_ /* Microsoft defines it in basetsd.h */ --#ifndef _BASETSD_H /* MinGW is slightly different */ --#ifndef QGLOBAL_H /* Qt defines it in qglobal.h */ +-#ifndef _BASETSD_H_ /* Microsoft defines it in basetsd.h */ +-#ifndef _BASETSD_H /* MinGW is slightly different */ +-#ifndef QGLOBAL_H /* Qt defines it in qglobal.h */ -typedef long INT32; -#endif -#endif @@ -106,7 +57,3 @@ diff --git jmorecfg.h jmorecfg.h /* Datatype used for image dimensions. The JPEG standard only supports * images up to 64K*64K due to 16-bit fields in SOF markers. Therefore * "unsigned int" is sufficient on all machines. However, if you need to - * handle larger images and you don't mind deviating from the spec, you - * can change this datatype. (Note that changing this datatype will - * potentially require modifying the SIMD code. The x86-64 SIMD extensions, - * in particular, assume a 32-bit JDIMENSION.) |