Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
80
called when the buffer is filled, you should NOT write out the entire buffer
after a suspension. Write only the data up to the current position of
next_output_byte/free_in_buffer. The data beyond that point will be
regenerated after resumption.
Because of the backtracking behavior, a good-size output buffer is essential
for efficiency; you don't want the compressor to suspend often. (In fact, an
overly small buffer could lead to infinite looping, if a single MCU required
more data than would fit in the buffer.) We recommend a buffer of at least
several Kbytes. You may want to insert explicit code to ensure that you don't
call jpeg_write_scanlines() unless there is a reasonable amount of space in
the output buffer; in other words, flush the buffer before trying to compress
more data.
The compressor does not allow suspension while it is trying to write JPEG
markers at the beginning and end of the file. This means that:
* At the beginning of a compression operation, there must be enough free
space in the output buffer to hold the header markers (typically 600 or
so bytes). The recommended buffer size is bigger than this anyway, so
this is not a problem as long as you start with an empty buffer. However,
this restriction might catch you if you insert large special markers, such
as a JFIF thumbnail image, without flushing the buffer afterwards.
* When you call jpeg_finish_compress(), there must be enough space in the
output buffer to emit any buffered data and the final EOI marker. In the
current implementation, half a dozen bytes should suffice for this, but
for safety's sake we recommend ensuring that at least 100 bytes are free
before calling jpeg_finish_compress().
A more significant restriction is that jpeg_finish_compress() cannot suspend.
This means you cannot use suspension with multi-pass operating modes, namely
Huffman code optimization and multiple-scan output. Those modes write the
whole file during jpeg_finish_compress(), which will certainly result in
buffer overrun. (Note that this restriction applies only to compression,
not decompression. The decompressor supports input suspension in all of its
operating modes.)
Decompression suspension:
For decompression suspension, use a fill_input_buffer() routine that simply
returns FALSE (except perhaps during error recovery, as discussed below).
This will cause the decompressor to return to its caller with an indication
that suspension has occurred. This can happen at four places:
* jpeg_read_header(): will return JPEG_SUSPENDED.
* jpeg_start_decompress(): will return FALSE, rather than its usual TRUE.
* jpeg_read_scanlines(): will return the number of scanlines already
completed (possibly 0).
* jpeg_finish_decompress(): will return FALSE, rather than its usual TRUE.
The surrounding application must recognize these cases, load more data into