Bug in umc_speech_RTP_codec sample.

Bug in umc_speech_RTP_codec sample.

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:

umc_speech_rtp_codec -r18000 -format IPP_MSRTAwb_FP soundno.rtp soundno.wav

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

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

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

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:

umc_speech_rtp_codec -f16000 -r18000 -format IPP_MSRTA_FP soundno.rtp soundno.wav

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

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

Dear Ying,

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

soundyes.rtp -> works

souundno.rtp -> crashes

Thx!

microintel99

Attachments: 

AttachmentSize
Downloadapplication/cap soundno.cap2.58 MB
Downloadapplication/octet-stream soundno.rtp1.68 MB
Downloadapplication/cap soundyes.cap2.58 MB
Downloadapplication/octet-stream soundyes.rtp1.68 MB

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

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:

        if(m_pParams->m_pTimer->isTime() && pcktSize < inMediaBuffer.GetDataSize()) {

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

Regards,
Sergey

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

Attachments: 

AttachmentSize
Downloadapplication/cap crash.cap2.72 MB
Downloadapplication/octet-stream crash.rtp1.24 MB

Hi Sergej,

I tried with IPP 6.x too, same behaviour as IPP 7.x.

I added a printf before the check:

printf("packetsize %d, buffer %dn",pcktSize,inMediaBuffer.GetDataSize());

The following are last packets before the crash:

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

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

Hi,
any update about this IPP framework bug?

thx
microintel99

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

Leave a Comment

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