topic Re: Problem with G729 VAD processing in Intel® Integrated Performance Primitives

Problem with G729 VAD processing

deepak_shenoy — Sat, 14 May 2005 00:56:00 GMT

I am passing RTP stream directly to G729 decode function.

Now the decode function expects to pass frame_type as one argument

frame_type = 3 (voice)
= 2 (SID)
= 0 (null)
= -1 (missing frame)

Since this all happens in real-time there is no way for me
to know if there was a missing frame

so I set frame_type to be -1 even when there is a normal NULL frame

But this causes a very abd spike in the beginning of the decoded speech recording.

I have no problem if I do the same with ITU implementation of g729.

which tells me something is different with your g729 implementation.

Can you please help..or suggest a workaround for this problem?

Re: Problem with G729 VAD processing

Vyacheslav_Baranniko — Mon, 16 May 2005 18:41:08 GMT

Per G729 spec information aboutnull frames alsomustbe communicated to receiver other than in the bitstream.For exampl, RTP sents null frameinthe packet of zero size (only header).

Vyacheslav

Re: Problem with G729 VAD processing

deepak_shenoy — Mon, 16 May 2005 20:26:18 GMT

Yes that is for NULL frames , but how do you communicate about missing frames to the decoder.

Re: Problem with G729 VAD processing

Vyacheslav_Baranniko — Wed, 18 May 2005 16:27:53 GMT

Missing or lost framesdetection is responsibility ofRX (receive) side.There is some probability (typically 2-4%) for any packet be not delivered to RX "in time" or be actually lost due to low network bandwidth or/and network outage.The receiver decidesabout what "in time" means.In thereal-timesystem this is generally relates to "playout" time when all packets yet not arrived shoud betreated as "lost" eitherby decoder with PLC or just omitted or replaced bylately arrived packet (duplicated)and then dropped out (rejected)even if arrived later.

Vyacheslav