| March 17, 2009 10:00 AM PDT | |
Problem Description :
When developing a vidoe decoder based on the MPEG4 or H263 sample code included in IPP audio_video_codec sample. The decoding usually work, but occasionally it crashed as an exception 'inside' the function UMC::MPEG4VideoDecoder::GetFrame. Decoding the same frame does not always produce the exception. The core dump information looks like
XXXXX!v8_ippiDecodeDCIntra_MPEG4_1u16s+0x61
XXXXX!mp4_DecodeIntraMB+0x145
XXXXX!mp4_DecodeVOP_I+0xb21
XXXXX!mp4_DecodeVideoObjectPlane+0x2d8
XXXXX!UMC::MPEG4VideoDecoder::GetFrame+0x474
XXXXX!UMC::cGenericDecodec::Decode+0x10d
XXXXX!UMC::cGenericDecodec::Decode+0xb1
XXXXX!CIPPVideoDecoder::Decode+0x93
Cause:
Using 'DevPartner' tools you may see that some operations can produce a 'read over-run' reading beyond the limit of the buffer that contains the encoded data, in some cases it can produce a memory error. The problem did happen when allocating 3 more bytes of memory for this buffer.
Solution:
It is a known problem - our decoders do not check the end of buffer and can read after buffer.
There are several ways to avoid this
1. To put few zero bytes at the and of buffer before calling of decoder.
2. To copy input buffer inside decoder in temporal buffer and pad it by few zero bytes.
e.g. use temporal buffer of bigger size and copy data to it and put four zero bytes after real data.
3. To implement try-except handling.
When developing a vidoe decoder based on the MPEG4 or H263 sample code included in IPP audio_video_codec sample. The decoding usually work, but occasionally it crashed as an exception 'inside' the function UMC::MPEG4VideoDecoder::GetFrame. Decoding the same frame does not always produce the exception. The core dump information looks like
XXXXX!v8_ippiDecodeDCIntra_MPEG4_1u16s+0x61
XXXXX!mp4_DecodeIntraMB+0x145
XXXXX!mp4_DecodeVOP_I+0xb21
XXXXX!mp4_DecodeVideoObjectPlane+0x2d8
XXXXX!UMC::MPEG4VideoDecoder::GetFrame+0x474
XXXXX!UMC::cGenericDecodec::Decode+0x10d
XXXXX!UMC::cGenericDecodec::Decode+0xb1
XXXXX!CIPPVideoDecoder::Decode+0x93
Cause:
Using 'DevPartner' tools you may see that some operations can produce a 'read over-run' reading beyond the limit of the buffer that contains the encoded data, in some cases it can produce a memory error. The problem did happen when allocating 3 more bytes of memory for this buffer.
Solution:
It is a known problem - our decoders do not check the end of buffer and can read after buffer.
There are several ways to avoid this
1. To put few zero bytes at the and of buffer before calling of decoder.
2. To copy input buffer inside decoder in temporal buffer and pad it by few zero bytes.
e.g. use temporal buffer of bigger size and copy data to it and put four zero bytes after real data.
3. To implement try-except handling.
Do you need more help?
This article applies to: Intel® Integrated Performance Primitives Knowledge Base
For more complete information about compiler optimizations, see our Optimization Notice.
Comments (2) 
| February 20, 2010 1:14 AM PST
Ying H (Intel)
|
Hello, As I recalled, the problem is reported in IPP 5.3 update 3. The problem is produced by SSE instruction itself, which required 128 bit data chunk. It is not a bug, so we haven't fixed it in function ippiDecodeDCIntra_MPEG4 internal and provide workaround to pad the input data by several zero bytes at that time. I guess, the problem should be still in IPP 6.1. What is your problem? You may add more information by IPP forum <<http://software.intel.com/en-us/forums/intel-integrated-perf.....es/>>; Regards, Ying |
Trackbacks (0)
Leave a comment 
To obtain technical support, please go to Software Support.
Author
Ying H (Intel)
|
mdaoud
15