- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes that is for NULL frames , but how do you communicate about missing frames to the decoder.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page