- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This doesn't happen very often but I have seen this issue couple times.
I didn't manage to capture a sequence causing the issue but it seems that sometimes that while decoding aCAVLC segment, the decoder goes past the end of the slice and try to reconstruct a bogus macroblock.
If the reference index of the bogus MB is out of the range of the reference list the decoder will crash.
A simple hack to avoid the issue is to make sure the reference index is within the range before reconstructing the macroblock and exit the slice decoding loop when that happen. (in DecodeSegmentCAVLC_Single)
Note that the issue is not seen in CABAC segements.
I didn't manage to capture a sequence causing the issue but it seems that sometimes that while decoding aCAVLC segment, the decoder goes past the end of the slice and try to reconstruct a bogus macroblock.
If the reference index of the bogus MB is out of the range of the reference list the decoder will crash.
A simple hack to avoid the issue is to make sure the reference index is within the range before reconstructing the macroblock and exit the slice decoding loop when that happen. (in DecodeSegmentCAVLC_Single)
Note that the issue is not seen in CABAC segements.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Which version of Intel IPP sample code you are using? There was one issue on ippiDecodeCAVLCCoeffs_H26 before IPP 6.1 update 4. The problem has been fixed in the latest release.
Also it need to use option /EH (instead of /EHsc) to compile the sample code to handle the exception data in the bit stream.
Thanks,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Chao,
I was indeed testing on a machine with IPP 6.1 update 3 runtimes.
The usage of SEH is not an option for me (running on Linux 64) .
Emmanuel
I was indeed testing on a machine with IPP 6.1 update 3 runtimes.
The usage of SEH is not an option for me (running on Linux 64) .
Emmanuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Emmanuel,
Could it be upgraded to the latest release? The problem happens with IPP function, not the sample code.
Thanks,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have upgraded and havn't see the crash so far. It was very sporadic to begin with so its hard to say if the problem is solved. I will raise the issue again if I encounter the issue after the latest update.
Thanks,
Emmanuel
Thanks,
Emmanuel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have seen the crash again today.
The IPP version reported by ippGetVersion is 6.1.137.810 6.1 build 137.56 Mar 16 2010 which I believe is after update 4.
I have a core dump saved in case you want me to gather specific info.
The crash is in ippiDecodeCAVLCCoeffs_H264_1u16s while trying to decode an I4x4 MB.
There is no obvious parameter that is incorrect.
Emmanuel
I have seen the crash again today.
The IPP version reported by ippGetVersion is 6.1.137.810 6.1 build 137.56 Mar 16 2010 which I believe is after update 4.
I have a core dump saved in case you want me to gather specific info.
The crash is in ippiDecodeCAVLCCoeffs_H264_1u16s while trying to decode an I4x4 MB.
There is no obvious parameter that is incorrect.
Emmanuel
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page