Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

the input buffer, and repeat the call. In the case of jpeg_read_scanlines(),

increment the passed pointers past any scanlines successfully read.

Just as with compression, the decompressor will typically backtrack to a

convenient restart point before suspending. When fill_input_buffer() is

called, next_input_byte/bytes_in_buffer point to the current restart point,

which is where the decompressor will backtrack to if FALSE is returned.

The data beyond that position must NOT be discarded if you suspend; it needs

to be re-read upon resumption. In most implementations, you'll need to shift

this data down to the start of your work buffer and then load more data after

it. Again, this behavior means that a several-Kbyte work buffer is essential

for decent performance; furthermore, you should load a reasonable amount of

new data before resuming decompression. (If you loaded, say, only one new

byte each time around, you could waste a LOT of cycles.)

The skip_input_data() source manager routine requires special care in a

suspension scenario. This routine is NOT granted the ability to suspend the

decompressor; it can decrement bytes_in_buffer to zero, but no more. If the

requested skip distance exceeds the amount of data currently in the input

buffer, then skip_input_data() must set bytes_in_buffer to zero and record the

additional skip distance somewhere else. The decompressor will immediately

call fill_input_buffer(), which should return FALSE, which will cause a

suspension return. The surrounding application must then arrange to discard

the recorded number of bytes before it resumes loading the input buffer.

(Yes, this design is rather baroque, but it avoids complexity in the far more

common case where a non-suspending source manager is used.)

If the input data has been exhausted, we recommend that you emit a warning

and insert dummy EOI markers just as a non-suspending data source manager

would do. This can be handled either in the surrounding application logic or

within fill_input_buffer(); the latter is probably more efficient. If

fill_input_buffer() knows that no more data is available, it can set the

pointer/count to point to a dummy EOI marker and then return TRUE just as

though it had read more data in a non-suspending situation.

The decompressor does not attempt to suspend within standard JPEG markers;

instead it will backtrack to the start of the marker and reprocess the whole

marker next time. Hence the input buffer must be large enough to hold the

longest standard marker in the file. Standard JPEG markers should normally

not exceed a few hundred bytes each (DHT tables are typically the longest).

We recommend at least a 2K buffer for performance reasons, which is much

larger than any correct marker is likely to be. For robustness against

damaged marker length counts, you may wish to insert a test in your

application for the case that the input buffer is completely full and yet

the decoder has suspended without consuming any data --- otherwise, if this

situation did occur, it would lead to an endless loop. (The library can't

provide this test since it has no idea whether "the buffer is full", or

even whether there is a fixed-size input buffer.)