I was trying to run H264 decoder using the IPP 7 libraries and Sample code but H264 decoder enters in infinite loop. while trying to debug i found that an error UMC_ERR_NOT_ENOUGH_BUFFER is continuously returned due to which the while loop in function GetFrameInternal() function becomes infinite. The number of frames decoded and outputted varies before the problem occurs. I am running it on 64 bit linux with gcc4 compiler. Any help would be very useful.
you can use any encoded file or encode a file using your own ipp 7.0 encoder. The decoder either never exits gracefully or rarely gives a abort. Also the o/p decoded file sizes produced are of different sizes on different runs of the same input encoded bitstream.
Regarding UMC_ERR_NOT_ENOUGH_BUFFER message, in most of the case, this comes from users code error.
So could you try to run your test stream with simpleplayer application in the UMC sample code? Can it work for you?
Also there is some simple code at this page, which can provide help for learning from start: http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-unified-media-classes-sample...
Thanks for the support.
the bitstream qs.h264 used as input to H264 decoder is produced by me from a yuv file using your own ipp encoder and giving following command: ./umc_video_enc_con h264 -w 528 -h 480 -i out.yuv -o qs.h264.
I am using the application given by intel umc_h264_dec_con.I first build the ipp_samples and intel sample application umc_h264_dec_conusing your script build_intel64.sh gcc4.
source /opt/intel/composerxe-2011.0.084/bin/compilervars.sh intel64
source /opt/intel/composerxe-2011.0.084/ipp/bin/ippvars.sh intel64
Then i try to execute theumc_h264_dec_con exe produced by giving commands :
./umc_h264_dec_con -i qs.h264 -o out1.yuv
So this is intel ipp 7.0 code and the application umc_h264_dec_con in the package. i have not done any changes to the package (l_ipp-samples_p_7.0.1.029.tar.gz)andthere is no contamination of code from my side. I had just build the package using your script thats all.
The result ofof executing umc_h264_dec_con is that either there is an abort or the execution just hangs. If you are lucky it may execute for a couple of times before it hangs but if you see the decoded output size (that is out1.yuv here) it will be different size on different h264-decoder executions when input bitstreamremains same.
I'am aware of this problem and havebeen alreadyworking on it for some time. This is abugin multithread h264decoderspecific for macos/linux. You can use single thread mode by using -t1 argument as a temporary workaround.
Thanks for the information. Actually we are stuck in a customer delivery and urgently need the multithreaded version of H264 decoder. Can you please tell me an estimated time by which we can expect a fix for the above issue.
We are planning to move to IPP7.0. We would like to know if this bug exists only in 7.0 or 6.1 too? Does this bug happen with specific resolution? Does this bug happen when decoding any h.264 stream?
[cpp]#if defined(OSX32) || defined(__FreeBSD__) pthread_mutexattr_settype(&mutex_attr, PTHREAD_MUTEX_RECURSIVE); #else pthread_mutexattr_settype(&mutex_attr, PTHREAD_MUTEX_ERRORCHECK_NP); #endif[/cpp]with this