Comment 3 for bug 1012861

Adding SRU template with information.

[IMPACT]

 * This update is an opportunity to sync with the upstream stable release of 1.2.1 (as of SVN853)

 * This update includes a number of changes, they are:

* update to stable release 1.2.1 r853
* Cosmetic fixes to argument lists
* Added flags to the TurboJPEG API that allow the caller to force
the use of either the fast or the accurate DCT/IDCT algorithms
in the underlying codec.
* More recent versions of autoconf add -traditional-cpp to the CPP
flags, which causes jsimdcfg.inc.h to not preprocess correctly
unless we expand all of the instances of the #definev macro.
* Fixed regression caused by a bug in the 32-bit strict memory access
code in jdmrgss2.asm (contributed by Chromium to stop valgrind from
whining whenever the output buffer size was not evenly divisible by
16 bytes.) On Linux/x86, this regression generated incorrect
pixels on the right-hand side of images whose rows were not 16-byte
aligned, whenever fancy upsampling was used. This patch also
enables the strict memory access code on all platforms, not just
Linux (it does no harm on other platforms) and removes a couple of
pcmpeqb instructions that were rendered unnecessary by r835.
* Accelerated 4:2:2 upsampling routine for ARM (improves
performance ~20-30% when decompressing 4:2:2 JPEGs using
fancy upsampling)
* Eliminate the use of the MASKMOVDQU instruction, to speed
up decompression performance by 10x on AMD Bobcat embedded
processors (and ~5% on AMD desktop processors.)
* add tjbench to libjpeg-turbo-test packages
* Guard against num_components being a ridiculous
value due to a corrupt header
* Preserve all 128 bits of xmm6 and xmm7

[TESTCASE]

 * make test passes which runs the libjpeg-turbo test suite. This has been run on armhf and x86_64 and x86

[Regression Potential]

 * libjpeg-turbo is fairly stable. Libjpeg however can be considered a core library and a number of applications do link to it. If there is an error, image effects in eog, or other graphical applications will be the likely result.

[Other Info]

 * There are fixes included in the java source code bindings, however since this is not built, these changes do not have an effect.
 * None of the changes since the last version in the archive and this candidate version are for security.