Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

to consume input as it makes this pass. If you use a suspending data source,

you need to check for a FALSE return from jpeg_start_output() under these

conditions. The combination of 2-pass quantization and a not-yet-fully-read

target scan is the only case in which jpeg_start_output() will consume input.

Application authors who support buffered-image mode may be tempted to use it

for all JPEG images, even single-scan ones. This will work, but it is

inefficient: there is no need to create an image-sized coefficient buffer for

single-scan images. Requesting buffered-image mode for such an image wastes

memory. Worse, it can cost time on large images, since the buffered data has

to be swapped out or written to a temporary file. If you are concerned about

maximum performance on baseline JPEG files, you should use buffered-image

mode only when the incoming file actually has multiple scans. This can be

tested by calling jpeg_has_multiple_scans(), which will return a correct

result at any time after jpeg_read_header() completes.

It is also worth noting that when you use jpeg_consume_input() to let input

processing get ahead of output processing, the resulting pattern of access to

the coefficient buffer is quite nonsequential. It's best to use the memory

manager jmemnobs.c if you can (ie, if you have enough real or virtual main

memory). If not, at least make sure that max_memory_to_use is set as high as

possible. If the JPEG memory manager has to use a temporary file, you will

probably see a lot of disk traffic and poor performance. (This could be

improved with additional work on the memory manager, but we haven't gotten

around to it yet.)

In some applications it may be convenient to use jpeg_consume_input() for all

input processing, including reading the initial markers; that is, you may

wish to call jpeg_consume_input() instead of jpeg_read_header() during

startup. This works, but note that you must check for JPEG_REACHED_SOS and

JPEG_REACHED_EOI return codes as the equivalent of jpeg_read_header's codes.

Once the first SOS marker has been reached, you must call

jpeg_start_decompress() before jpeg_consume_input() will consume more input;

it'll just keep returning JPEG_REACHED_SOS until you do. If you read a

tables-only file this way, jpeg_consume_input() will return JPEG_REACHED_EOI

without ever returning JPEG_REACHED_SOS; be sure to check for this case.

If this happens, the decompressor will not read any more input until you call

jpeg_abort() to reset it. It is OK to call jpeg_consume_input() even when not

using buffered-image mode, but in that case it's basically a no-op after the

initial markers have been read: it will just return JPEG_SUSPENDED.

Abbreviated datastreams and multiple images

-------------------------------------------

A JPEG compression or decompression object can be reused to process multiple

images. This saves a small amount of time per image by eliminating the