Re: [codec] #16: Multicast?

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

Hi Koen,



My comments in-line below.



Best Regards,



Raymond



-----Original Message-----
From: Koen Vos [mailto:[e-mail]]
Sent: Saturday, April 24, 2010 6:16 PM
To: Raymond (Juin-Hwey) Chen
Cc: [e-mail]
Subject: RE: [codec] #16: Multicast?



Quoting "Raymond (Juin-Hwey) Chen":

> My main point, though, is not in the exact one-way delay value for a

> codec with a 5 ms frame size, but rather that with a 5 ms frame size

> you can get a much lower one-way delay than with a 20 ms frame size.



It would be about 15 ms lower - don't know if that counts as "much" :)



[Raymond]: I don't agree that it will be only 20 - 5 = 15 ms lower.  That will be true only if your one-way delay formula below is true, but theoretically it cannot be.  See my comment below your formula.



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.



>> - most delay comes from the network and is not codec related, and

>> - one-way delay grows almost linearly with frame size.

>

> Doesn't your last line above contradicts with the second last line?



I meant that approximately:

    one-way delay = codec-independent delay + frame size



("codec algorithmic delay" would be more accurate than "frame size")



[Raymond]: First, I agree that codec algorithmic buffering delay is more accurate than frame size since it can also include the "look-ahead" delay and filtering delay if sub-band analysis/synthesis is used.  However, your formula implies that for the codec-related delay, the "multiplier" to be used for the codec frame size is only 1.  That's unrealistic and theoretically impossible.  For that to happen, after you wait one frame of time for the current frame of input audio samples to arrive at your input signal buffer (that's one frame of codec-related delay already), you need an infinitely fast processor to finish the encoding operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed frame to the decoder instantly, and then you need an infinitely fast processor to finish decoding the frame instantly and start playing back the current frame of audio without any delay.  That's just impossible.

In reality, if the processor is just barely fast enough to implement the codec in real time, then you need nearly a full frame of time to finish the encoding and decoding operations. That makes the multiplier to be 2 already.  If your communication link is just barely fast enough to transmit your packets at the same speed they are generated without piling up unsent packets, then it takes another frame of time to finish transmitting the compressed bits in a frame to the decoder.  That makes the multiplier to be 3 already.

Granted, in practice the processor and the communication link are usually faster than just barely enough, so the processing delay and the transmission delay can be less than 1 frame each.  However, there are other miscellaneous uncounted delays that tends to depend on the codec size in various ways.  Thus, a typical IP phone implementation would have

  One-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any).

Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference).

Consequently, for the conference bridge application, the total difference in one-way delay can easily be in the 90 to 100 ms range. When adding this delay difference to all the other codec-independent delay components, it is still a huge difference that the users can easily notice, especially since it will most likely push the total one-way delay significantly beyond the 150 ms limit.



> I am aware of a header compression technology for VoIP over Cable

> applications that can compress the header size to a very small

> fraction of the original size, but it is probably not widely used.



Yes, header compression works between end-points on a cable.  That's

different from "between arbitrary Internet end points".



[Raymond]: The cable operators' networks are still IP networks.  If the technology can work there, I don't see why it cannot work elsewhere in the Internet.  I know it is currently not available between arbitrary Internet end points.  I am just saying that technologies exist that can potentially be deployed in the Internet to compress the packet headers to a very small fraction of the uncompressed headers.



best,

koen.