Problem of Huffman algorithm in IPP6.1

[Ricky_Wang]

Hi,

We are using IPP6.1 in our product, when I was evaluating the algorithms in IPP6.1, I ran into a problem.

See the below code, whereEncodeHuffman andDecodeHuffman are from IPP6.1 samples(ipp-samples\\data-compression\\ipp_compress):http://registrationcenter.intel.com/irc_nas/1910/w_ipp-samples_p_6.1.6.065.zip

I have narrowed down the problem down to the below simple code, and I carefully debugged the code to prevent misusage and silly mistakens.

would you please take a look?

Thanks a lot.

Ricky

code segament below.

_______________________________________________________________________

//the following code encodes 11-byte long buffer using Huffman,

//then decode the encoded-buffer,

//but the result is 12-byte long

//I am using Visual Studio 2008 with SP1

int stateSize;

ippsHuffGetSize_8u(&stateSize);

IppHuffState_8u* pHuffState = (IppHuffState_8u*)ippsMalloc_8u(stateSize);

// the 11-byte long source buffer

BYTE src[] = {0xff, 0x00, 0x00, 0xfc, 0x01, 0x00, 0x00, 0xff, 0x00, 0x00, 0xfb};

BYTE dst[256];

BYTE decode[256];

int dstlen = sizeof(dst);

int dstlen2;

int ret = EncodeHuffman( src, sizeof(src), dst, &dstlen, pHuffState ) ;

dstlen2 = sizeof(decode);

ret = DecodeHuffman( dst, dstlen, decode, &dstlen2, pHuffState ) ;

if( dstlen2 != sizeof(src) || memcmp(decode, src, sizeof(src)))

{// the result decoded-buffer is 12-byte long:

//{0xff, 0x00, 0x00, 0xfc, 0x01, 0x00, 0x00, 0xff, 0x00, 0x00, 0xfb, 0xFF}, one extra 0xFF added.

printf("failed\\n");

}

//Clean up code below

[Chao_Y_Intel]

Ricky,

Have you checked the latest 7.04 release? Several issues were fixed for data compression functions in 7.0 release. The new package also can be downloaded in registraction center: http://registrationcenter.intel.com

Thanks,
Chao

[Ricky_Wang]

Hi Chao,

Thanks for your response.

I didn't test this problem with IPP7 yet.

We knew from Intel that IPP7 does NOT support some legacy CPU models, so we'd like to use IPP6.1 in our product to make customers happy.

Would you please to investigate further? If it's a bug of IPP6.1, it will be a good reason for our management team to make the decision to adopt IPP7.

Regards,

Ricky

[Chao_Y_Intel · Accepted solution]

Hi Ricky,

The EncodeHuffman() function actually doesnt write any stop symbol in the end of encoded stream and, as the result, this stream contains a garbage in the end. The decode function couldnt detect the end of input stream and decodes this garbage. Actually, such could be used with another approach an user should store the encoded elements number and set such number as destination size. You can see it at ipp_compress sample where such approach is used.

Also our function owner had a bit change on huffman.c file(from ipp_compress sample) for your approach, and you can find full functional example in the attached file.

Thanks,
Chao

[Ricky_Wang]

This workaround works. The samples need upgrade.

Thanks,