H264 decoder problem

H264 decoder problem

Hi all. I'm using IPP lib version 7.0.4 with the latest IPP sample7.0.4.054I have got a crash with the H264 decoder when I'm decoding a 1280x720 stream. Not all the HD ready stream get this problem, but this sistematically crash.
I attach the stream that cause me the problem.I write the stack trace that cause me the problem:void H264SegmentDecoder::DeblockMacroblockPSlice()void H264SegmentDecoder::PrepareDeblockingParametersPSlice()void H264SegmentDecoder::PrepareDeblockingParametersPSlice16x16Vert()inline size_t H264SegmentDecoder::GetReferencePSlice(Ipp32s iMBNum, Ipp32s iBlockNum)iMBNum=1840iBlockNum=0size_t DeblockPicID(Ipp32s index)index=0return m_ID[index]; //this row cause the problemit's seems thatm_ID is not null but is in an inconsistent stateCan you reproduce the problem?

31 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I re-attach the file

Attachments: 

AttachmentSize
Download h264_1280x720.mkv956.64 KB

Anyway I think that the problem is the address of the m_ID array. When the decoder crash m_IDhas a very strange address like someone has corrupt the array's address

Someone has check this problem? just to know if it's a library bug or something else

I had this problem as well. Sometimes it works and sometimes it crash with this error.Anyone has a solution?

Good,
I'm not alone :) I got always the error. I think it's some kind of
buffer corruption. Perhaps something related to the resolution.

I have same problem too :(, and it's very easy to crash when multiple threads are decoding concurrently.There is no such problem when using IPP 5.And when upgrade to IPP7, the diaster is coming...

I think we have to wait for a bugfixed release of the h264 decoder.Same stream with different resolution (lower or higher doesn't matter) do not have the problem

For me, it happens seems randomly. It seems to happen more frequently at frames that are bigger in size. 720x576This does not happen at IPP 6 as well

Dear all,

Sorry for the slow response as summur vacation season :)

The simple_player doesn't recoginze the fileof h264_1280x720.mkv. Could any one of you please provide another test stream or tell how to feed the video stream to decoder?

Thanks
Ying

Dear Ying the file I submitted is a standard matroska (mkv) file that contain an h264 stream.If you want you can convert it with avidemux or virtualdub mod. Anyway you should not recode the stream otherwise you lost the problem. I think anyway you should be able to open the mkv stream in a standard way. Anyway if I have enough time I try to produce an avi stream

ok here you are an avi file. Try this and you can get the decode problem (crash)

Attachments: 

AttachmentSize
Download h264_1280x720.avi958.25 KB

Hi Selea,

Thank you for the file.But i can't decode the file with simple_player.exe or umc_h264_dec_con, whatever under linux or windows, IPP 6.1 or IPP 7.0.4

What platform are you working on? I'mlooking at thediscussion in forum81357too.
http://software.intel.com/en-us/forums/showthread.php?t=81357&o=a&s=lr
It included a 1280x960 stream. Could you try the stream and see if the crash can be reproduced?

Thanks
Ying

Windows 7.0.4:
C:\Users\yhu5\Desktop\IPP7.0\w_ipp-samples_p_7.0.4.054\ipp-samples\audio-video-c
odecs\_bin\ia32_icl120>simple_player.exe -vdx C:\Users\yhu5\Desktop\UMC\h264_128
0x720.avi

Stream Type : AVI

Linux 6.1:

[yhu5@NHM02 linuxem64t_gcc4]$ ./simple_player -t3 /tmp/h264_1280x720.avi

Stream Type : AVI
[yhu5@NHM02 linuxem64t_gcc4]$ pwd
/home/yhu5/IPP6.1/ipp-samples/audio-video-codecs/_bin/linuxem64t_gcc4

I'm usingsamples_p_7.0.4.054 and I'm working on windows xp.Anyway the problem is that I can't decode it, or I can decode only a frame and than the decoder crash. Have you try to continue to decode the frame till the end of the file? did you see a decoder crash? anyway if you open the file with VLC player you can see some frame decoded.Anyway the stream come from a camera that should produce 1280x720 h264 frames. You tell me that the stream you see is 1280x960: that could be the problem. If for some reason the SPS or PPS is declaring 1280x720 and the stream inside is 960 or vice-versa, that could be a problem for the decoderI'm going to try the h264 stream from the discussion you tell me, and I let you know

In my case, single stream decoding is not so easy to crash.
But it's quite easy to crash when there areover 4 threads, each
decoding different video stream.

The video stream coming from different IP Cameras(Samsung
&HikVision..)

Most of the time, I found the crash happened like:
One or twothreads are decoding normally, and then,
there is another thread entering "init" stage, the init thread get crashed.

To me, I have no idea how to send you the data to debug.

Hello Selea,

The docoder doesn't recognize the format of h264_1280x720.avi, it quits right away aftershow the error"Video Decoder creation failed". so i can't decode theh264_1280x720.avi.

the "1280x960"is fromthestream inforum U81357.Just verify that the decoder can decodewith the HD streamat my sides.

Thanks,
Ying

I'm trying to use the h264 stream I took from the post you suggest me, but how can I read frame by frame to decode the file in my application? I can't see header that describe the of each frame, because seems a pure stream without container. I can start for the start code00000001 but it's not so fast to get a try. I let you know when I make a try

In my case I got the decoder problem even with one stream.I can useUMC::H264VideoDecoder to get the information about the stream, and the decoder tell me that the stream is 1280x720.I attach the Info struct that is theH264VideoDecoderParams after the GetInfo that I do after the Init of the h264 decoder. All operation succesfull for me
Anyway if you want I can create a stream .h264 without avi container so perhaps you could succesfull decode it. Give me the time to save the file

Attachments: 

AttachmentSize
Download h264Info.jpg187.76 KB

Ok done: I make a file .h264 that contain only the h264 stream, like that one you tell me to download from the other post.Try that and tell me if you can decode it and if you got the error

Attachments: 

AttachmentSize
Download 1280x720.h264955.52 KB

Can you read the file I attached in the previews message? can you reproduce the problem?

Hello Selea,

Great!. The file you attached can work now.Idecodeit with umc_h264_dec_con.exe and simpledecoder.cpp under debug mode several times. It seems work no problem.

I'm on Window ia32UMC sample7.0.4.054.

Regards,
Ying

try to decode in 2 separeted thread.I'm on Window ia32UMC sample7.0.4.054 too, and I'm using static lib version of the IPP

Hi Selea,

if with
DataIn.SetBufferPointer(cVideoData,VideoDataSize);
DataIn.SetDataSize(VideoDataSize);

Params.m_pData = &DataIn; Params.lFlags=0; Params.numThreads=4;
if(status = H264Decoder.Init(&Params)!=UMC::UMC_OK)
return;

H264Decoder.GetInfo(&Params);
imgWidth=Params.info.clip_info.width; imgHeight=Params.info.clip_info.height;
it works fine.
how you to decode in 2 separeted thread? any detials?

Regards,
Ying

No, I mean to decode multiple streams in separated thread: for example 2 threads that decode the h264 stream.set the Params.numThreads=1 and try to create 2 thread that decode the stream...anyway I can't understand why you can decompress without problem.Have you used the static IPP library version?

Hi Selea,

Yes, I have tried static IPP library (both sequential(ipp*_l.lib) or parallel (ipp*_t.lib)).They can decompressyour stream fine.

So the problemlooks bemultiple threading. How do you create 2 threads by Win32 Windows API?Could you provide methe simple test code?

(if it is confidential, you may use private post).

Regards,
Ying

Usually
when I have to create 2 thread I use the function _beginthreadex.So
you can create a function to decode the stream, create 2 thread with
_beginthreadex that execute this function and run it at the same
time. Try and let me know. Anyway I can reproduce the problem
decoding even in 1 thread. Have you tried with the latest lib and
sample?

After
some days of try with the umc_h264_dec_con sample and my application
I found the problem.

Was
in my application, so I apologize with youYing to waste your
time.

Anyway,
I explain what was the problem.

Usually
we read the H264 stream from the network or from an mkv video file:
instead the samples works on a h264 bitstream. I make a
H264->GetFrame on every frame I got, but I always consider that
the decoder consume all the video data of the frame (usually it's
so). Anyway in this particular case I got some frame that are not
totally consumed but got me a complete image. For example I have a
frame read from a the stream of 35kb and after GetFrame I have
consumed only 15kb. I did not check the reamain bytes that now
I put in the decoder again.

So
probably after I wrong and discard the remain data without fill it in
the GetFrame, next frame cause me a crash of the decoder.

Was
my error, but I think you can check why the decoder crash.

To
simulate the decoder crash change the sample code like this:

from

if
((3 > in->GetDataSize()) &&

to

if
(/*(3 > in->GetDataSize()) &&*/

and
comment out the continue; after initialization

try
that with the 1280x720.h264 I attached and you can get the exception

let
me know

Attachments: 

AttachmentSize
Download 1280x720.h264955.52 KB
Best Reply

Hi Selea,

Glad to know you make progress. and thank you very much to share your experience here.

You are exact right, the GetFrame() is not always produce a frame. There is some data remain in buffer.I guessthismay be the most importantpointwhendevelop H.264 decoderwith stream data.We may need take care of the loop and condition in the loop very carefully.

See the explanation in the UMC docu

Syntax virtual UMC::Status GetFrame(UMC::MediaData* pSrc, UMC::MediaData* pDst)
Description
The method processes data.
Ifthe user allocates input and output buffers. If GetFrame does
not use all data from the input buffer, the method updates data pointer, value of the actual
data in the buffer and start time.

If the codec uses internal frame buffering it can return UMC::UMC_ERR_NOT_ENOUGH_DATA
at the beginning of the processing. This error code means that the input data is buffered
but the output data is not ready to be delivered. The application has to continue to call
GetFrame with the next input data.

To retrieve buffered data at the end of the processing, the application should call GetFrame
with NULL input pointer while output is not empty.

(and ifwe did search, there aremany discussion about the h.264 decoder's delay or get UMC_ERR_NOT _ENOUGH_DATA in the forum.Unfortunately whentheapplication become large and complex, the basic problem weresubmerged)

With comment if (/*(3 > in->GetDataSize()) &&*/ andif (UMC_ERR_NOT_ENOUGH_DATA == ret)
{
if (bEndOfStream)
break;
// else
// continue;
}

//if (UMC_OK != ret)
// continue;
numDecodedFrames++;
printf("Frame decoder %d\n", numDecodedFrames);

I can't reproduce the crash, butI believedyou will getwrong result if discard someremain data by some condition clause.
For example, with above comment,iwill get 27 frame and thereal frame with thestream is 24 frame. some frame is actually black.

Best Regards,
Ying

thanks Ying, my application already take care of theUMC_ERR_NOT _ENOUGH_DATA that's ok. The only problem was that I never saw in all the h264 stream before a behaviour like that. So I never see before the GetFrame consume only some bytes of the input buffer. Now I got it and I fix it.Anyway with the code you modify, if you look at the VisualStudio output you will see an exception throw at the line size_t DeblockPicID(Ipp32s index) { return m_ID[index]; }That cause me the crash before, but looking at the code I see the exception is caught correctly, so it's ok.Sorry again to waste your time, but the problem was that I did not see that "bytes consuming behaviour" before. Probably it's a difficult condition to obtain in a live stream that come from a camera.

Now, it is unclear why there is an exception thrown at the lines given but I suspect it could be an access violation or similar due to out-of-bounds indexing. Such should never occur! No access violations ever in a decoder library under normal circumstances! (And certainly, they should not be swept under the carpet by merely catching them). So even if the way the decoder has been used by not delivering the right amount of data (or whatever) is not as intended, the decoder should be sufficiently fail-safe in a way that it does not crash. As long as the user does not misuse the library and does provide proper and accessible data, it should be fail-safe even if the user has misunderstood some details in the use. There will obviously be ways that people can misuse a library and those cases will not be able to be handled perfectly and it could even crash then. But this case does not seem like such a case. And the internal DeblockPicID function should obviously always work without access violations!

- Jay

Leave a Comment

Please sign in to add a comment. Not a member? Join today