- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
thanks
abhishek
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
could you please attache your test stream here to help us reproduce your case?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
regards
abhishek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the problem is that I can't reproduce the issue on ANY stream. The streams I have does not show that issue.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Abhishek,
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,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
I do
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.
regards
abhishek mehrotra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good day.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good day.
Hard to say. I want to finish this before New Year holidays. If I'll findsomething, I'll give you a point how to fix it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
any update on the fix for this issue would be hugely appriciated becoz we are in a tight spot for this.
regards
abhishek mehrotra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any updates????
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We only reproduced with IPP 7.0 for Linux/Mac sample. The threading code hassome change in the 7.0 sample. We will providemore update on the fix.
Thanks,
Chao
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[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
[cpp]pthread_mutexattr_settype(&mutex_attr, PTHREAD_MUTEX_RECURSIVE);[/cpp]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To everyone,
IPP 7.0.3 release today. The multithreading h.264 hang issue should be fixed in the version.
The sample can be gotten from l_ipp-samples_p_7.0.3.040.tgz
Regards,
Ying
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page