Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
87
final possibility is to pass a target scan number less than the current input
scan number; this disables the input/output interlock and causes the output
processor to simply display whatever it finds in the image buffer, without
waiting for input. (However, the library will not accept a target scan
number less than one, so you can't avoid waiting for the first scan.)
When data is arriving faster than the output display processing can advance
through the image, jpeg_consume_input() will store data into the buffered
image beyond the point at which the output processing is reading data out
again. If the input arrives fast enough, it may "wrap around" the buffer to
the point where the input is more than one whole scan ahead of the output.
If the output processing simply proceeds through its display pass without
paying attention to the input, the effect seen on-screen is that the lower
part of the image is one or more scans better in quality than the upper part.
Then, when the next output scan is started, you have a choice of what target
scan number to use. The recommended choice is to use the current input scan
number at that time, which implies that you've skipped the output scans
corresponding to the input scans that were completed while you processed the
previous output scan. In this way, the decoder automatically adapts its
speed to the arriving data, by skipping output scans as necessary to keep up
with the arriving data.
When using this strategy, you'll want to be sure that you perform a final
output pass after receiving all the data; otherwise your last display may not
be full quality across the whole screen. So the right outer loop logic is
something like this:
do {
 absorb any waiting input by calling jpeg_consume_input()
 final_pass = jpeg_input_complete(&cinfo);
 adjust output decompression parameters if required
 jpeg_start_output(&cinfo, cinfo.input_scan_number);
 ...
 jpeg_finish_output()
} while (! final_pass);
rather than quitting as soon as jpeg_input_complete() returns TRUE. This
arrangement makes it simple to use higher-quality decoding parameters
for the final pass. But if you don't want to use special parameters for
the final pass, the right loop logic is like this:
for (;;) {
 absorb any waiting input by calling jpeg_consume_input()
 jpeg_start_output(&cinfo, cinfo.input_scan_number);
 ...
 jpeg_finish_output()
 if (jpeg_input_complete(&cinfo) &&
 cinfo.input_scan_number == cinfo.output_scan_number)
 break;
}
In this case you don't need to know in advance whether an output pass is to