Re: H.264 Decoder Crashes

Omnisip · ‎08-26-2007

Hi guys,

I'm having issues with the H.264 Decoder in Intel in which causes either one of two issues. The first issue is that it spinlocks in the H.264 TaskScheduler, and the second is that the application Segmentation Faults.

I wrote an application which is a video conferencing server and am trying to move away from ffmpeg(for low reliability reasons) to Intel IPP. I'm initializing the decoder properly as the width and height are appropriately set on the videodata frame (yuv420). I'm feeding it SPS, PPS, I-Frame in that order first. I have an access unit processor that makes sure the decoder is only fed full access units. I modified the H.264 AnnexB Splitter distributed with the samples to allow me to add H.264 Nals to a queue instead of reading from a file. As for the segfaults, it usually happens in one of the luma processing functions.

Here's the backtrace of where it loops endlessly:
==4631== by 0x47272D: UMC::TaskSupplier::AddSlice(UMC::H264MemoryPiece*, UMC::MediaData*) (umc_h264_task_supplier.cpp:2202)
==4631== by 0x4732AA: UMC::TaskSupplier::AddSource(UMC::MediaData*&, UMC::MediaData*) (umc_h264_task_supplier.cpp:1992)
==4631== by 0x46D5BC: UMC::H264VideoDecoder::ParseFrame(UMC::MediaData*, UMC::MediaData*) (umc_h264_dec_decode_pic.cpp:201)
==4631== by 0x46D771: UMC::H264VideoDecoder::GetFrame(UMC::MediaData*, UMC::MediaData*) (umc_h264_dec_decode_pic.cpp:169)

particularly at parse frame.

Any help is well welcomed.

Thanks,
Dan

Omnisip · ‎08-26-2007

I rebuilt the ipp-samples with debugging assertions turned on, and full debugging symbols (-O0 -g3), It is now asserting false in area where it appears to be getting an h.264 exception.

#0 0x0000003f60430065 in raise () from /lib64/libc.so.6
#1 0x0000003f60431b00 in abort () from /lib64/libc.so.6
#2 0x0000003f60429766 in __assert_fail () from /lib64/libc.so.6
#3 0x000000000048f2d7 in UMC::H264SegmentDecoderMultiThreaded::ProcessSegment (this=0x154e460) at src/umc_h264_segment_decoder_mt.cpp:221
#4 0x0000000000471644 in UMC::TaskSupplier::RunDecoding (this=0x12f3780, dst=0x130a270, src=0x1626c00, force=false) at src/umc_h264_task_supplier.cpp:2575
#5 0x000000000047354a in UMC::TaskSupplier::AddSource (this=0x12f3780, pSource=@0x409ff7d8, dst=0x130a270) at src/umc_h264_task_supplier.cpp:2062
#6 0x000000000046d5bd in UMC::H264VideoDecoder::ParseFrame (this=0x130b130, pDestination=0x130a270, pSource=0x1626c00) at src/umc_h264_dec_decode_pic.cpp:201
#7 0x000000000046d772 in UMC::H264VideoDecoder::GetFrame (this=0x130b130, src=0x1626c00, dst=0x130a270) at src/umc_h264_dec_decode_pic.cpp:169
#8 0x000000000042e3b4 in msoup::video::H264FrameManager::popNextFrame (this=0x1309d38) at ../H264FrameManager.cpp:356

Omnisip · ‎08-26-2007

The above was with number of threads set to 1. When the thread count is set to 0, it is having race conditions so it seems as seen below:

#0 0x0000003f60430065 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003f60430065 in raise () from /lib64/libc.so.6
#1 0x0000003f60431b00 in abort () from /lib64/libc.so.6
#2 0x0000003f60429766 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000499793 in UMC::Mutex::Lock (this=0x14bdb58) at /home/dweber/Desktop/intel-ipp/ipp-samples/audio-video-codecs/core/vm_plus/include/umc_mutex.h:63
#4 0x0000000000496e69 in UMC::TaskBroker::Lock (this=0x14bdb50) at src/umc_h264_task_broker.cpp:115
#5 0x00000000004974c5 in UMC::TaskBrokerTwoThread::Reset (this=0x14bdb50) at src/umc_h264_task_broker.cpp:918
#6 0x0000000000496452 in UMC::TaskBroker::Release (this=0x14bdb50) at src/umc_h264_task_broker.cpp:110
#7 0x000000000049749c in UMC::TaskBrokerTwoThread::Release (this=0x14bdb50) at src/umc_h264_task_broker.cpp:927
#8 0x0000000000498237 in UMC::TaskBroker::Init (this=0x14bdb50, iConsumerNumber=8) at src/umc_h264_task_broker.cpp:90
#9 0x0000000000498289 in UMC::TaskBrokerTwoThread::Init (this=0x14bdb50, iConsumerNumber=8) at src/umc_h264_task_broker.cpp:896
#10 0x0000000000473ef1 in UMC::TaskSupplier::Init (this=0x14bd930, pInit=0x130a1e0) at src/umc_h264_task_supplier.cpp:277
#11 0x000000000046daed in UMC::H264VideoDecoder::Init (this=0x130b130, pInit=0x130a1e0) at src/umc_h264_dec_decode_pic.cpp:87
#12 0x000000000042db39 in msoup::video::H264FrameManager::popNextFrame (this=0x1309d38) at ../H264FrameManager.cpp:303

Omnisip · ‎08-26-2007

dan@marketsoup.com:
I rebuilt the ipp-samples with debugging assertions turned on, and full debugging symbols (-O0 -g3), It is now asserting false in area where it appears to be getting an h.264 exception.

#0 0x0000003f60430065 in raise () from /lib64/libc.so.6
#1 0x0000003f60431b00 in abort () from /lib64/libc.so.6
#2 0x0000003f60429766 in __assert_fail () from /lib64/libc.so.6
#3 0x000000000048f2d7 in UMC::H264SegmentDecoderMultiThreaded::ProcessSegment (this=0x154e460) at src/umc_h264_segment_decoder_mt.cpp:221
#4 0x0000000000471644 in UMC::TaskSupplier::RunDecoding (this=0x12f3780, dst=0x130a270, src=0x1626c00, force=false) at src/umc_h264_task_supplier.cpp:2575
#5 0x000000000047354a in UMC::TaskSupplier::AddSource (this=0x12f3780, pSource=@0x409ff7d8, dst=0x130a270) at src/umc_h264_task_supplier.cpp:2062
#6 0x000000000046d5bd in UMC::H264VideoDecoder::ParseFrame (this=0x130b130, pDestination=0x130a270, pSource=0x1626c00) at src/umc_h264_dec_decode_pic.cpp:201
#7 0x000000000046d772 in UMC::H264VideoDecoder::GetFrame (this=0x130b130, src=0x1626c00, dst=0x130a270) at src/umc_h264_dec_decode_pic.cpp:169
#8 0x000000000042e3b4 in msoup::video::H264FrameManager::popNextFrame (this=0x1309d38) at ../H264FrameManager.cpp:356

#3 0x000000000048f2d7 in UMC::H264SegmentDecoderMultiThreaded::ProcessSegment (this=0x12f25d0) at src/umc_h264_segment_decoder_mt.cpp:221
ex = (const UMC::h264_exception &) @0x18a7760: {_vptr.h264_exception = 0x11b1e30, m_Status = -882}
Task = {pFunction = {__pfn = 0x21, __delta = 0}, m_pBuffer = 0x0, m_WrittenSize = 0, m_pSlice = 0x18d4410, m_pSlicesInfo = 0x1706290, m_iThreadNumber = 0,
m_iFirstMB = 0, m_iMaxMB = 300, m_iMBToProcess = 300, m_iTaskID = 0, m_bDone = false, m_bError = false}
umcRes = 0
__PRETTY_FUNCTION__ = "virtual UMC::Status UMC::H264SegmentDecoderMultiThreaded::ProcessSegment()"

"Invalid Stream Error" == -882 (this is single thread)

Omnisip · ‎08-26-2007

Results can be reproduced for both conditions with the umc_h264_dec tool shipped with the ipp sample pack.

Here is a link to a file that can be tested with:
http://share.robotics.net/10.10.0.62-15000.264

The modifications I made to the ipp-sample source: Changed CXXFLAGS for LINUX32 from -02 to -O0 -g3. I turned on VM_DEBUG debugging assertions only (none of the other debugging info). This was acheived by changing the define:
#define VM_ASSERT (void*)0 something
to #define VM_ASSERT assert

#include

Summary of Issues:
1 Thread: Decoder INVALID_STREAM_ERROR (decodes in ffmpeg)
N Threads: Race condition with mutices.

Dan

Vladimir_Dudnik · ‎08-26-2007

Hi Dan,

thanks for your issue report. Could you please specify what version of IPP and media sample do you use? It seems you are running decoder on 64-bit Linux?

Regards,
Vladimir

Omnisip · ‎08-27-2007

Linux EMT64
Processor(s): Dual Intel Quad Core Xeons

IPP version: l_ipp_em64t_p_5.2.059

Media sample was produced through a grandstream gxv-3000 h.264 videophone. I am not sure on the exact version, and I will ask Grandstream to supply that info. I would like to note, that even with the umc_dec_h264 tool, it does spit out 19mb of yuv frames on the above sample before dieing.

Dan

Omnisip · ‎08-27-2007

Quick Update:

Decodes perfectly fine with latest JM reference decoder. Spits this warning, but it is not at all serious:

warning: zero_byte shall exist

Vladimir_Dudnik · ‎08-28-2007

Hi Dan,

thank a lot for help in identification of issue. I've submitted issue report for you on Intel Premier Support,please expectyou will be contacted soon by our technical support engineers who will update you on issue status.

Regards,
Vladimir

Omnisip · ‎08-28-2007

I'm hoping you gave this thread for input to the technical support team, and I think I may have located at least one of the issues:

#0 0x0000000000475de3 in UMC::TaskSupplier::AddSlice (this=0x15f3170, pMem=0x107b790, pSource=0x409ff7e0) at src/umc_h264_task_supplier.cpp:2123
2123 pSlice->m_pSeqParamSet = m_Headers.GetSeqParamSet(pSlice->m_pPicParamSet->seq_parameter_set_id);
(gdb) bt
#0 0x0000000000475de3 in UMC::TaskSupplier::AddSlice (this=0x15f3170, pMem=0x107b790, pSource=0x409ff7e0) at src/umc_h264_task_supplier.cpp:2123
#1 0x0000000000476cdb in UMC::TaskSupplier::AddSource (this=0x15f3170, pSource=@0x409ff630, dst=0x107ac50) at src/umc_h264_task_supplier.cpp:1992
#2 0x0000000000470f42 in UMC::H264VideoDecoder::ParseFrame (this=0x107eb20, pDestination=0x107ac50, pSource=0x409ff7e0) at src/umc_h264_dec_decode_pic.cpp:202
#3 0x00000000004711a2 in UMC::H264VideoDecoder::GetFrame (this=0x107eb20, src=0x409ff7e0, dst=0x107ac50) at src/umc_h264_dec_decode_pic.cpp:170
#4 0x0000000000431783 in msoup::video::H264FrameManager::popNextFrame (this=0x107d5e8) at ../H264FrameManager.cpp:351

pSlice->m_pPicParamSet == 0 which causes the segfault.

Dan

Omnisip · ‎09-05-2007

Hey Vladimir,

I haven't received any response yet. When should I be expecting something?

Dan

Vladimir_Dudnik · ‎09-08-2007

Hi Dan,

sorry for the delay, I hope one of our technical support engineers contacted with you recently.

Regards,
Vladimir