Hi, This sample doesn't designed to measure performance of IPP speech codecs. Its goal to demonstrate using of our codecs in VOIP environtment. If you would like to time speech codecs, please use usc_speech_codec sample.
As for discovered bottleneck - you cannot optime it. The purpuse of jitter buffer to aligh arrived packets in time i.e. to remove jitter becase usually packets' arrive time different: 20 ms +- some jitter time. Actually UMC::JitterBuffer class designed to work in real time modewith theusing of system time to provide recived packet in time, i.e. exactly every 20 ms for example. More over some packets can be discartedif they arrive very late. So this class waits as long as possible to provide output packet and hence its performce shalln't be measured.
Hi Eric, In case of UDP underlying transport protocol andoffline decoding you deal with just the follwing simple problems which you need to solve: 1. Packets reordering. 2. Lost packets.
Both of them can be solved based on "sequence_namber" and "timestamp" fields from RTP packet header.If you are able to do two passesthrough pcap file than during first pass you should build correct packets map and decode them during second path.
If you wouldn't do two passes then pretty simple decision to have dynamic list of packets (something like std::list from STL)with several packets lookahead. Push arrived packed to the correct place (mostly at the end in normal network conditions) and pop old one from the beggining. Don't start decoding untill list will be fully filled. Adiitionally you should check and discard very late arrived packets (with arrive time more than lookahead window). I suggestlookahead window size in 5 to 8 packets. This will resulted in 100 - 160 ms playout delay.