Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

reads some additional data and returns when one of the indicated significant

events occurs. (If called after the EOI marker is reached, it will

immediately return JPEG_REACHED_EOI without attempting to read more data.)

The library's output processing will automatically call jpeg_consume_input()

whenever the output processing overtakes the input; thus, simple lockstep

display requires no direct calls to jpeg_consume_input(). But by adding

calls to jpeg_consume_input(), you can absorb data in advance of what is

being displayed. This has two benefits:

* You can limit buildup of unprocessed data in your input buffer.

* You can eliminate extra display passes by paying attention to the

state of the library's input processing.

The first of these benefits only requires interspersing calls to

jpeg_consume_input() with your display operations and any other processing

you may be doing. To avoid wasting cycles due to backtracking, it's best to

call jpeg_consume_input() only after a hundred or so new bytes have arrived.

This is discussed further under "I/O suspension", above. (Note: the JPEG

library currently is not thread-safe. You must not call jpeg_consume_input()

from one thread of control if a different library routine is working on the

same JPEG object in another thread.)

When input arrives fast enough that more than one new scan is available

before you start a new output pass, you may as well skip the output pass

corresponding to the completed scan. This occurs for free if you pass

cinfo.input_scan_number as the target scan number to jpeg_start_output().

The input_scan_number field is simply the index of the scan currently being

consumed by the input processor. You can ensure that this is up-to-date by

emptying the input buffer just before calling jpeg_start_output(): call

jpeg_consume_input() repeatedly until it returns JPEG_SUSPENDED or

JPEG_REACHED_EOI.

The target scan number passed to jpeg_start_output() is saved in the

cinfo.output_scan_number field. The library's output processing calls

jpeg_consume_input() whenever the current input scan number and row within

that scan is less than or equal to the current output scan number and row.

Thus, input processing can "get ahead" of the output processing but is not

allowed to "fall behind". You can achieve several different effects by

manipulating this interlock rule. For example, if you pass a target scan

number greater than the current input scan number, the output processor will

wait until that scan starts to arrive before producing any output. (To avoid

an infinite loop, the target scan number is automatically reset to the last

scan number when the end of image is reached. Thus, if you specify a large

target scan number, the library will just absorb the entire input file and

then perform an output pass. This is effectively the same as what

jpeg_start_decompress() does when you don't select buffered-image mode.)

When you pass a target scan number equal to the current input scan number,

the image is displayed no faster than the current input scan arrives. The