Changes between Initial Version and Version 2 of Ticket #969


Ignore:
Timestamp:
Jan 20, 2010 12:44:51 AM (15 years ago)
Author:
nanang
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #969

    • Property Summary changed from Improvement in jitter buffer algoritm to make space for new frames when it is full (thanks Emil Sturniolo for the suggestion) to Improvement in jitter buffer algoritm for low bandwidth network (thanks Emil Sturniolo for the suggestion)
    • Property Milestone changed from release-1.5 to release-1.6

  • Ticket #969 – Description

    initial v2  
    1 Currently when the jitter buffer is full, it will drop 1/4th of its size when new frame arrives. This causes large portion of a conversation to be dropped. A better algorithm is to progressively discard frames as the buffer fills up. 
     1On low bandwidth network, high jitter and frame lost are usually the issues. The first issue is basically jitter buffer (JB) responsibility area. 
     2 
     3One simple way to detect jitter is by detecting the existence of burst, i.e: number of incoming frames from network between two playout clockticks, where without jitter, it should be always equal to one. Current JB uses such mechanism to measure actual burst level and use the burst level to manage the latency (due to clock drift) by periodically dropping/discarding frames. However as clock drift usually increases the latency very smoothly, JB will only drop/discard a frame at least every 200ms. 
     4 
     5In fact, it's been reported that as the burst is rather extreme in low bandwidth network, discard rate of 200ms seems to be insufficient as frequently JB tends to get full (high latency). Moreover, when it is full, it will drop 1/4th of its size when new frame arrives. This causes large portion of a conversation to be dropped. So, the issues identified here are latency and audio cut. 
     6 
     7A better algorithm to optimize latency and avoid bulk drops, let's say progressive discard algorithm, will progressively discard frames as the buffer fills up. 
     8 
     9The algorithm specifications: 
     10 1. Instead of dropping large consecutive frames, it should discard frames in spread. 
     11 1. The discard rate/aggressiveness should be adaptive to the network condition, notice some useful real-time indicators such as latency/size, burst level. 
     12 1. JB discards a frame by marking the frame with specific internal frame type, such as PJMEDIA_JB_DISCARDED_FRAME. 
     13 1. Discarded frames will not be returned to application, it will just get ignored/skipped in GET operation. So application will never get a frame with type PJMEDIA_JB_DISCARDED_FRAME. 
     14 1. Avoid discarding back-to-back frames. 
     15 1. Pass jbuf_test (of pjmedia_test), it may also need a test case of periodic large-burst spikes.