Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

Bug in umc_speech_RTP_codec sample.

Pippo_Pippo
Beginner
359 Views

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

0 Kudos
10 Replies
Pippo_Pippo
Beginner
360 Views

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

0 Kudos
Pippo_Pippo
Beginner
360 Views

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

0 Kudos
Ying_H_Intel
Employee
360 Views
Hi Microintel99,

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
0 Kudos
Pippo_Pippo
Beginner
360 Views

Dear Ying,

thanks for your answer, let me know if you can test those attached files.

soundyes.rtp -> works

souundno.rtp -> crashes

Thx!

microintel99

0 Kudos
Ying_H_Intel
Employee
360 Views
Dear Microintel99,

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
0 Kudos
Sergey_K_Intel
Employee
360 Views
Hi,
Could you try the following (may be it's just a workaround, needs additional investigation)?
In the file umc_speech_rtp_codec/src/timedplayer.cpp @ line 130 improve condition check:
[cpp] if(m_pParams->m_pTimer->isTime() && pcktSize < inMediaBuffer.GetDataSize()) { [/cpp] instead of simple if(...isTime()).
It must work.
The question about files attached: is it true that provided RTP files are produced from corresponding CAP files?
Regards,
Sergey
0 Kudos
Pippo_Pippo
Beginner
360 Views

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

0 Kudos
Pippo_Pippo
Beginner
360 Views

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

0 Kudos
Pippo_Pippo
Beginner
360 Views
Hi,
any update about this IPP framework bug?

thx
microintel99
0 Kudos
Ying_H_Intel
Employee
360 Views
Hi Microintel99, May you please try this? Function SampleTimer::IsTime (speech-codecs\application\umc_speech_rtp_codec\src\timer.cpp) should be: int SampleTimer::isTime() { if(m_CurrTime <= m_nextTime) { return 1; } return 0; } Function RTP_Packet::GetPayloadDataPointer(void) (speech-codecs\codec\speech_rtp\src\umc_rtp_packet.cpp(150)) void *RTP_Packet::GetPayloadDataPointer(void) { return (void *)((Ipp8s*)m_pDataPointer+(sizeof(sRTP_Header)+(m_Header->cc * sizeof(Ipp32u)))); } Regards, Ying
0 Kudos
Reply