Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
88
be the last one, so it's not necessary to have reached EOF before starting
the final output pass; rather, what you want to test is whether the output
pass was performed in sync with the final input scan. This form of the loop
will avoid an extra output pass whenever the decoder is able (or nearly able)
to keep up with the incoming data.
When the data transmission speed is high, you might begin a display pass,
then find that much or all of the file has arrived before you can complete
the pass. (You can detect this by noting the JPEG_REACHED_EOI return code
from jpeg_consume_input(), or equivalently by testing jpeg_input_complete().)
In this situation you may wish to abort the current display pass and start a
new one using the newly arrived information. To do so, just call
jpeg_finish_output() and then start a new pass with jpeg_start_output().
A variant strategy is to abort and restart display if more than one complete
scan arrives during an output pass; this can be detected by noting
JPEG_REACHED_SOS returns and/or examining cinfo.input_scan_number. This
idea should be employed with caution, however, since the display process
might never get to the bottom of the image before being aborted, resulting
in the lower part of the screen being several passes worse than the upper.
In most cases it's probably best to abort an output pass only if the whole
file has arrived and you want to begin the final output pass immediately.
When receiving data across a communication link, we recommend always using
the current input scan number for the output target scan number; if a
higher-quality final pass is to be done, it should be started (aborting any
incomplete output pass) as soon as the end of file is received. However,
many other strategies are possible. For example, the application can examine
the parameters of the current input scan and decide whether to display it or
not. If the scan contains only chroma data, one might choose not to use it
as the target scan, expecting that the scan will be small and will arrive
quickly. To skip to the next scan, call jpeg_consume_input() until it
returns JPEG_REACHED_SOS or JPEG_REACHED_EOI. Or just use the next higher
number as the target scan for jpeg_start_output(); but that method doesn't
let you inspect the next scan's parameters before deciding to display it.
In buffered-image mode, jpeg_start_decompress() never performs input and
thus never suspends. An application that uses input suspension with
buffered-image mode must be prepared for suspension returns from these
routines:
* jpeg_start_output() performs input only if you request 2-pass quantization
and the target scan isn't fully read yet. (This is discussed below.)
* jpeg_read_scanlines(), as always, returns the number of scanlines that it
was able to produce before suspending.
* jpeg_finish_output() will read any markers following the target scan,
up to the end of the file or the SOS marker that begins another scan.
(But it reads no input if jpeg_consume_input() has already reached the