- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I found a bug in umc_speech_RTP_codec sample compiled with IPP 7.0 and Microsoft Visual Studio 10.
I tried to decode a rtp sample (perfectly decoded with pcap2wav tool at http://pcap2wav.xplico.org) but the umc_speech_RTP_codec.exe application crashes at packet number 18747 (the last in the sample)
The bugged DLL seems to be ippsp8-7.0.dll.
I made some experiments with different samples and often this crash happens so I can say this application is not reliable now.
The bug seems not related to a specific packet because if you try to decode last packets in the sample you don't obtain the crash. It seems a memory leak in the dll that cause the crash when it reaches some particular conditions.
The command used is:
[bash]umc_speech_rtp_codec -r18000 -format IPP_MSRTAwb_FP soundno.rtp soundno.wav[/bash]
Hint: if you discard the last packet the application works correctly, but last packet it's not bugged in any way: soundno.rtp doesn't work, soundyes.rtp works correctly (last packet cut).
Can you check please the attached sample ?
A second issue I noted in correctly decoded samples (like attached soundyes.rtp) is the added comfort noise during silences. This tone is really annoying (tooloud) and is really a "discomfort noise".
Any way to modify in the source code the volumeof the comfort noise?
Thx a lot!
microintel99
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can add more debug info about the crash:
Exception at 0x022092bb in umc_speech_rtp_codec.exe:
0xC0000005: unhandled exception access violation 0x026cd000.
Anybody can test umc_speech_rtp_codec sample with attached .rtp?
Thx a lot
microintel99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Followup..
I tried to compile umc_speech_rtp_codec version 6.x and IPP 6.x (32bit version).
In this case you need to specify also the frequency:
[bash]umc_speech_rtp_codec -f16000 -r18000 -format IPP_MSRTA_FP soundno.rtp soundno.wav[/bash]
The application crashes in similar way as IPP 7.x (it behave correctly with soundyes.rtp sample instead)
It seems that the issue pertains lockout procedures in multithreading.
So again, the IPP 6.x and IPP 7.x frameworks seems to have a serious flaw with attached sample soundno.rtp.
Is it possible to open a ticket to reproduce and debug this?
Thx
microintel99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot for the reports. But we can't see the attatched files. Could you please attachthem again?
When you reply the message, you will see a Button "Add Files", where you can add a zip file to your post.
Thanks
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks much. I got the files and be able to reproduce the problem as you reported. I have escalated it to USC team for further check. I will keep you update if any news.
Best Regards,
Ying
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Sergey,
the workaround works for that sample but doesn't seems conclusive.
Please try this other sample in attach, it crashes in the same way.
>>The question about files attached: is it true that provided RTP files are produced from corresponding CAP files?
Correct. To obtain rtp files you can use Wireshark loading .cap:
-Analyze/DecodeAs/RTP
-Telephony/RTP/Show_all_streams/SaveAs .rtp
Hope crash.rtp can give you more hints about these anomalous crashes.
Thx a lot!
microintel99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sergej,
I tried with IPP 6.x too, same behaviour as IPP 7.x.
I added a printf before the check:
[cpp]printf("packetsize %d, buffer %d\n",pcktSize,inMediaBuffer.GetDataSize());[/cpp]
The following are last packets before the crash:
[plain]packetsize 25600, buffer 1144316
packetsize 100, buffer 1144316
packetsize 25600, buffer 1144316
packetsize 100, buffer 1144316
packetsize 99, buffer 1144208
packetsize 90, buffer 1144101
packetsize 23040, buffer 1144101
packetsize 90, buffer 1144101
packetsize 90, buffer 1144003
packetsize 90, buffer 1143905
packetsize 23040, buffer 1143905
packetsize 90, buffer 1143905
packetsize 90, buffer 1143807
packetsize 98, buffer 1143709
packetsize 102, buffer 1143603
packetsize 26112, buffer 1143603
packetsize 102, buffer 1143603
packetsize 76, buffer 1143493
packetsize 19456, buffer 1143493
packetsize 76, buffer 1143493
packetsize 77, buffer 1143409
packetsize 19712, buffer 1143409[/plain]
packetsize values are anomalous, I can't justify those big values (19712, 19456, 26112..)
I see those strange numbers also for other samples (soundyes.rtp, soundno.rtp).
It appears a tricky bug...
Let me now thx!
microintel99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
any update about this IPP framework bug?
thx
microintel99
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page