topic IPP LZSS is totally in Intel® Integrated Performance Primitives

IPP LZSS stream format/description

Maier__Adrian_Nicuso — Mon, 03 Feb 2014 20:32:37 GMT

Hello everyone,

I'm looking for Intel's IPP LZSS description. What I've found so far is that it uses 32KB window and MAX_MATCH=256 (Why?)

The most well-known LZSS implementation is Haruhiko Okumura's "LZSS.C". Even Microsoft Compress is based on his code - it's 4KB window, MAX_MATCH=17 (or 18 in some siblings)

Any ideas?

Hi Ilya,

Sergey_K_Intel — Tue, 04 Feb 2014 07:34:46 GMT

Hi Ilya,

It is a specific of implementation. Now it's hard to recall why it was done so. Probably, because longer lengthes provide better compression ratio on standard data sets.

Regards,
Sergey

It's understood. But original

Maier__Adrian_Nicuso — Tue, 04 Feb 2014 08:52:34 GMT

It's understood. But original LZSS is byte-aligned - 8 literal/match flags are packet into one byte, 16-bit LZ token consists of 4-bit match length + 12-bit offset/match distance. Is Intel's LZSS byte-aligned as well? How exactly literals and matches are coded? Is this LZSS totally undocumented??

IPP LZSS is totally

Sergey_K_Intel — Tue, 04 Feb 2014 10:24:46 GMT

IPP LZSS is totally undocumented, since we haven't assumed decoding of IPP LZSS-coded sequences with something else than IPP decoder. As far as I see from source code, the format is compatible with other LZSS implementations. That is, 1-bit flag, then either byte literal or offset-length pair (15-bit offset and 8-bit length).

The LZSS functions are oriented on source byte stream, so the LZSS encoder output is not byte-aligned (i.e. bit-oriented). Each EncodeLZSS function produces as much output as necessary dependending on input stream data and destination buffer length. The byte alignment happens only when EncodeLZSSFlush function is called.

Regards,
Sergey