Re: [codec] #16: Multicast?

[Koen Vos <[e-mail]>]

Hi Raymond,

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

Processing time matters on low-end hardware - a small fraction of  
today's VoIP end points.  Even then, the higher coding efficiency of  
longer frames can be translated into lower complexity.

And transmission delay increases (perhaps) linearly with the *packet  
size*, not with the *frame size*.  For a 32 kbps codec with 5 ms  
frames, packets are just 30% smaller than with a 16 kbps codecs with  
20 ms frames.

Let me ask you something: how often is G.729 used with 10 ms packets,  
or Broadvoice with 5 ms packets?

best,
koen.



Quoting "Raymond (Juin-Hwey) Chen":

> 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.
>
>
>