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?
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?
連結已複製
3 回應
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
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
