Subject: [codec] #32: Playout/Dejittering Buffer

From: "codec issue tracker" <[email-masked]>
Date: Sun, 09 May 2010 17:42:37 -0000

#32: Playout/Dejittering Buffer
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 This ticket summarized the discussions regarding dejittering buffer
 issues...

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/32>
codec <http://tools.ietf.org/codec/>

---

From: "codec issue tracker" <[email-masked]>
Date: Sun, 09 May 2010 17:43:12 -0000

Comment(by hoene@…):

 [Koen]: Also, note that for a given probability of packets arriving too
 late   to be played out, the jitter buffer delay is independent of the
 frame size.

 [Raymond]: That may be true theoretically, but in practical
 implementations, selecting a jitter buffer delay that is not divisible by
 the packet size would make the adaptive jitter buffer pretty messy to
 implement.  If we make the it divisible by the packet size, then a smaller
 packet size gives you more granularity to work with and can result in
 lower average delay as the codec frames go through the adaptive jitter
 buffer.

 [Koen]:  Jitter buffers have no problem implementing a non-integer-frame
 delay, because packets are queued and read non-synchronously.

 [Raymond]: I am talking about adaptive jitter buffer that tries to
 minimize the delay through the jitter buffer dynamically depending on the
 observed network jitter.  If the jitter is small, you decrease that delay,
 and if it is large, you increase that delay. An engineer who actually
 implemented such an adaptive jitter buffer in an IP phone told me that the
 non-integer-frame delay made it pretty messy to implement (I didn’t say it
 was not possible; it’s just messy), so for implementation simplicity’s
 sake, the jitter delay was often chosen to be an integer number of frames.
 He also said that a smaller frame size gives you more frequent
 observations of the network jitter and thus makes the jitter estimate more
 responsive and accurate.

 [Mikhael]:
 2 seconds jitter and 10% continous random packet loss should definitely be
 handled gracefully (during the tsunami where several fiber optic cables
 were severed in asia, packet loss from the region to the rest of the world
 was continous 5-7% due to remaining paths being extremely congested). 2
 seconds is for multiple links in a row being full (typically Cisco 12000
 routers can buffer 600ms of data when congestion occurs). There are
 numerous cases (ADSL2+ without interleave, high speed links with CRC
 errors, ethernet duplex errors) where random packet loss can be seen.
 Typically this is less than 1%, otherwise people tend to fix the problem
 because TCP works very badly.

 We then have the 3G/wifi network issue, where jitter can also be at least
 2 seconds, plus packet loss as well (some networks seem to buffer X
 kilobytes, some Y number of packets, after that they tail drop. I've seen
 both behaviours).

 Burst loss, where when you have a network re-route, you might lose
 typically 0.05 - 2 seconds of data, and you might get re-ordering during
 the convergence. Since this is a transient event, I don't think much can
 be done about it but try to play data as they come in and just ignore out
 of order packets. Perhaps jitter buffer should be increased when
 out-of-order packets is seen, but when things calm down again it needs to
 be reduced again.

 I've also seen networks which re-order packets constantly, I don't know
 what the load-sharing algorithm used is, but I think the jitter buffer
 size should be adapted and handle out of order packets so they're
 presented to the codec correctly.

 When running voice over GSM GPRS, typically there is very low bandwidth
 and high delay. Here bw should be kept as low as possible and the IP
 header is a big overhead and pps should thus be kept at a minimum, for
 instance 3-5 pps and the very lowest quality setting should be used.

 So, the SYSTEM (I'm not just talking codec here), as far as I can see it,
 needs to gracefully handle at least 10% packet loss, out of order packets
 (analyse the time they might be re-ordered and adapt jitter buffer
 accordingly), or just plain jitter up to 2s.

 My reasoning here is mainly focused on voice over Internet, but as far as
 I can see this applies to all sound, even though if it's not interactive I
 guess the focus can be switched from low latency (it might be better for a
 voice call to have lower latency than actually getting perfect sound) to
 reliable sound delivery with higher latency (by increasing jitter buffer
 and putting sound information in multiple packets so that single packet
 loss doesn't mean silence in that interval). Basically I'd like to see
 that as soon as jitter buffer is increased, the resiliancy to packet loss
 should be increased as well by telling the other end that it can start to
 do packet loss concealment information in the packets as well (whatever
 it's called, I'm not a codec guy). If sender knows what the receiver
 jitter buffer is, then this can be used to increase resiliency (I guess).

 [Michael]:
 >Thanks for the very useful industry examples and metrics. Handling of
 >these examples fall either into jitter buffer design (which so far in
 >the BoF email correspondence, other than noting the need for some form
 >of adaptive jitter buffer algorithm, is being treated as largely
 >outside the scope of the proposed WG)

 [Christian]:
 Jitter buffering is not explicitly mentioned in the Codec BOF. However, it
 must be considered because the requirements regarding testing. As stated
 in http://www.ietf.org/mail-archive/web/codec/current/msg01527.html, we
 shall test the codec using real trace of IP packets.
 These tests can only be made with some kind of dejitter buffer between
 packets and codec. Thus, at some point of time, we must agree which
 playout buffer to take for the testing.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/32#comment:1>
codec <http://tools.ietf.org/codec/>