H.264 Decoder H264SegmentDecoder InitDeblockingOnceEv Crash

[thompson_ng]

Hi,

H.264 decoder is crashing with the following crash log from Java.

It seems that something is wrong with H264SegmentDecoder InitDeblockingOnceEX. But, all I can find in the native code is InitDeblockingOnce.

The crash comes and goes. I would like to give more detail but I could not predict the crash. Any suggestion is welcome.

C [libtsimaging.so+0x204306] _ZN3UMC18H264SegmentDecoder18InitDeblockingOnceEv+0x196

C [libtsimaging.so+0x204d26] _ZN3UMC18H264SegmentDecoder14DeblockSegmentEii+0x66

C [libtsimaging.so+0x2977d1] _ZN3UMC31H264SegmentDecoderMultiThreaded18DeblockSegmentTaskEiRi+0x5d

C [libtsimaging.so+0x29741f] _ZN3UMC31H264SegmentDecoderMultiThreaded14ProcessSegmentEv+0x107

C [libtsimaging.so+0x2a6dc5] _ZN3UMC12TaskSupplier11RunDecodingEbPPNS_16H264DecoderFrameE+0x59

C [libtsimaging.so+0x17a961] _ZN3UMC16H264VideoDecoder16GetFrameInternalEPNS_9MediaDataES2_+0x95

C [libtsimaging.so+0x17aa80] _ZN3UMC16H264VideoDecoder8GetFrameEPNS_9MediaDataES2_+0xe8

C [libtsimaging.so+0x14abf2] _ZN11H264Decoder16decodeVideoFrameEPhi+0x72

C [libtsimaging.so+0x14b060] _ZN14H264Transcoder9TranscodeEPhiPN7IJGJPEG10_tJpegDataE+0x20

C [libtsimaging.so+0x1498d4] Java_com_srt_tsmedia_imaging_TranscoderUtils_h264Frame2Jpeg+0x118

C [libtsimaging.so+0x204306] _ZN3UMC18H264SegmentDecoder18InitDeblockingOnceEv+0x196C [libtsimaging.so+0x204d26] _ZN3UMC18H264SegmentDecoder14DeblockSegmentEii+0x66C [libtsimaging.so+0x2977d1] _ZN3UMC31H264SegmentDecoderMultiThreaded18DeblockSegmentTaskEiRi+0x5dC [libtsimaging.so+0x29741f] _ZN3UMC31H264SegmentDecoderMultiThreaded14ProcessSegmentEv+0x107C [libtsimaging.so+0x2a6dc5] _ZN3UMC12TaskSupplier11RunDecodingEbPPNS_16H264DecoderFrameE+0x59C [libtsimaging.so+0x17a961] _ZN3UMC16H264VideoDecoder16GetFrameInternalEPNS_9MediaDataES2_+0x95C [libtsimaging.so+0x17aa80] _ZN3UMC16H264VideoDecoder8GetFrameEPNS_9MediaDataES2_+0xe8C [libtsimaging.so+0x14abf2] _ZN11H264Decoder16decodeVideoFrameEPhi+0x72C [libtsimaging.so+0x14b060] _ZN14H264Transcoder9TranscodeEPhiPN7IJGJPEG10_tJpegDataE+0x20C [libtsimaging.so+0x1498d4] Java_com_srt_tsmedia_imaging_TranscoderUtils_h264Frame2Jpeg+0x118

I had provided the full log but not sure of it usefulness.

I found a similar post but no solutionhttp://software.intel.com/en-us/forums/showthread.php?t=84628

[Ying_H_Intel]

Hi Thompson.ng,

As you see, we need test stream to reproduce the problem.
If possible, could you writeyour rawstream (the input of H264decoder->Geframe())to a file so we can analyse the issue?

Thanks
Ying

[thompson_ng]

Hi Ying,

It really take me some time to reproduce to crash and get the frames as it is a production live camera.

Attached are the raw frames + SDP from the camera that crashes the IPP H.264 decoder.

But, please note that they does not always crashes the IPP H.264 decoder and that really make me hard to give you additional information.

Hope they crashes on your side.

[Ying_H_Intel]

Hi Thompson,

Thank you a lot. I will try the stream and let you know if result.

For your information, there are some progress about H.264 decoder crahsed within the forum
http://software.intel.com/en-us/forums/showthread.php?t=84603&o=a&s=lr.

where selea share their experiences. Theyget h.264 decoder crashedwith stream input also. The problem is
that asucessful call ofH264->GetFrame() may produceoneframe, but there is still remain data in decode pipeline,discard remain datacause problem. So you may need take care of the buffer and the loop.

Thanks
Ying

[Ying_H_Intel]

Hi Thompson,

I have tried the frames you send to me. Here is some interesting pieces of news.

1) IPP release a new version. and IPP sample can be get from <<http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-code-samples/>>.

A h.264 decoder issuewas fixed there.Please upgrade it if possible.
http://software.intel.com/en-us/forums/showthread.php?t=82978

2)I getnews from another user who were working on h.264 decode with stream input beside ofSelea,almost similiar, the problem is not in h.264 decoder itself, but wrongly set the buffer pointerin their FIFO decoder pipeline when dealing with streaming input.

3)The testframes you uploaded makemy testdoable. Thanks. But as the current UMC sample only accept file read/write, I combine all frames to a file and try with simple_player.exe and umc_h264_decode with several model, debug/release, static/dynamic link/threading/no threading.Unlucky,i can't reproducethe crash.The streamsworkwithout any exception.

your original inputworks without problem in file format,so I guessthe problem should still bethe decoder pipeline logicor streaming buffer.

Best Regards,
Ying H.

[thompson_ng]

Hi Ying,

Thanks for the response.

Actually, I have more crash frames for you. This time round the frames are much smaller. 352x288 frames.

I am currently using IPP 7 update 3 and I have checked my version that theTableInitializer still exist in my umc file. Moreover, I am only using single thread for decoding.

So, I got a feeling that my issue is slightly different?

Regarding upgrade to new version, do I need to purchase 7.0.5 in order for the new sample to work?

Or, can I use the new sample with 7.0.3?

[Ying_H_Intel]

Hi thompson, Thanks much. with the test file, It seems the problem can be reproduced under debug mode. We will look into detials and let you know if any update. In general, we recommend to use same library version + same sample version. As the problem is only related to sample code, so it should be ok using new sample with 7.0.3. Regards, Ying H.

[Pavel_V_Intel · Accepted solution]

This problem usually occures due to data losses in stream, propably some additional checks will help you:

Gotoumc_h264_frame.cpp and add ippSet_8u function after memory allocation on line 349 to fill memory with invalid values

[cpp]        // allocate buffer
        size_t nMemSize = GetFrameDataSize(m_lumaSize);

        m_pParsedFrameDataNew = m_pObjHeap->Allocate((Ipp8u*)0, (Ipp32s)nMemSize);
        ippsSet_8u(0xFF, (Ipp8u*)m_pParsedFrameDataNew, (Ipp32u)nMemSize);[/cpp]

Then gotoumc_h264_segment_decoder_deblocking.cpp and add slice id checks on lines 79 and 144

[cpp]    // set initial macroblock coordinates
    m_CurMB_X = ((m_CurMBAddr >> (Ipp32s) m_isMBAFF) % mb_width);
    m_CurMB_Y = ((m_CurMBAddr >> (Ipp32s) m_isMBAFF) / mb_width) - MBYAdjust;
    m_CurMB_Y <<= (Ipp32s) m_isMBAFF;

    // check mbs info for possible data losses
    if(m_gmbinfo->mbs[m_CurMBAddr].slice_id < 0)
        return;[/cpp]

[cpp]void H264SegmentDecoder::DeblockMacroblockMSlice()
{
    // check mbs info for possible data losses
    if(m_gmbinfo->mbs[m_CurMBAddr].slice_id < 0)
        return;[/cpp]

[Ying_H_Intel]

Thanks Pavel,the additional checks for proper data initialization before deblocking in order to allow codec to skip deblocking of missing macroblocks have been added to the latest IPP sample version 7update 6 and update 7.

Thanks
Ying