Subject: RE: [Sipping] RE: draft-stein-great-00.txt

From: "Yaakov Stein" <[email-masked]>
Date: Sat, 8 Oct 2005 21:26:40 +0200

(disclaimer for those who don't know: I'm the author of Speex)

> Sounds like a good idea to me.
> And we should design it from day one for the modern Internet
> environment.

Both Speex and iLBC (as far as I know) *are* designed from day one for
the Internet.

[YJS]  These are a good start, and I have said so several times in the past.

However, I believe that much more can be done.

> The G-series codecs put 90% effort into low rate, and 10% into low
> delay.

Untrue. Many G.* codecs are into low bit-delay, G.729 is 10 ms and G.728
is < 1ms.

[YJS] Well, G.728 is indeed low delay, but is stuck at a relatively high bit rate.

[YJS] And G.729 is not 10 ms delay - it is 10 ms frame duration. To that you have to add the lookahead, processing time, and SW thread times, and the fact that most Internet implementations of 729 use superpackets.

> It is critical for them to be CBR, and there is no attention to packet
> loss, etc.

I think CBR (or at least having a max bit-rate) *is* important for VoIP.

[YJS] That's interesting. Why ?

As for packet loss, I wouldn't say the G.* don't pay attention to it at
all, but of course the focus is more on bit corruption.

[YJS] The only "attention" was the addition, at a relatively late stage, of the annexes for PLC.

> Only the IETF has the motivation to design a codec for:
> 1) no 4kHz (or 8kHz) limitation

Speex already does wideband, which is already much better than
narrowband. Yet, I'm still trying to convince people to use wideband
instead of narrowband (even those already using Speex).

> 2) high perceptual quality (not "toll quality")

Try Speex at quality >= 8.

> 3) not necessarily CBR

Why not? While Speex supports VBR, I don't think it's really useful in
VoIP unless you have a large number of connections for the "law of the
average" to apply.

[YJS] Once again, I am not following you here. Since packets can have arbitrary size, you save immediately if you exploit the variability.

> 4) low delay

Current standard is around 20-30 ms, which is fine for many uses. Of
course lower would be nice, but the overhead becomes important. With 20
ms frames, you pay almost 16 kbps just for the overhead of IP/UDP/RTP.

[YJS] Once again, you are confusing frame duration with delay. The most common codec for VoIP seems to be 723 which with lookahead and processing and software overhead is about 50 millisec each way. To this you have to add the propagation through the network. Round trip times of 200 millisec are very common.

> 5) resilient to bursty packet loss

If by bursty, you mean 5-10 lost packets in a row, I'm sorry, but
there's just *nothing* that can really be done about it (unless you are
willing to really screw up latency). For more "conventional" (random,
10-20%) loss, then I think Speex and iLBC already do a good job.

[YJS] I disagree that nothing can be done. Nothing can be done in a pure jitter buffer system, but several good shock absorber systems are out there.

        Jean-Marc

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jean-Marc Valin <[email-masked]>
Date: Sun, 09 Oct 2005 08:33:08 +1000

> However, I believe that much more can be done.

Go ahead, we're all waiting for your low-delay, high-quality, low
bit-rate codec.

> [YJS] Well, G.728 is indeed low delay, but is stuck at a relatively
high bit rate.

You're not serious, are you? G.728 is 16 kbps. Sending audio in 5 ms
frames will cost you 64 kbps just for headers. For very low latency
you're always going to pay more in overhead than what the codec costs
you.

> [YJS] And G.729 is not 10 ms delay - it is 10 ms frame duration. To
that you have to 
> add the lookahead, processing time, and SW thread times, and the fact
that most 
> Internet implementations of 729 use superpackets.

If the implementation is bad, then it's not the codec's fault.

> [YJS] That's interesting. Why ?

Because if I have a modem that has ~30 kbps upload and I subtract the
header 16 kbps overhead and about 5 kbps for being safe, I'm left with 9
kbps. Using a 8 kbps codec CBR will work. Using a 8 kbps (average) VBR
codec will not. It's a matter of never exceeding the max bandwidth of
your channel. If you do DTX or VBR, if will save a few bits, but it
cannot make your communication better.

> [YJS] The only "attention" was the addition, at a relatively late
stage, of the annexes for PLC.

PLC for those codecs is usually known as "frame erasure" (because of the
wireless focus) and AFAIK it was included in G.729 from the start.

> [YJS] Once again, you are confusing frame duration with delay. The
> most common codec for VoIP seems to be 723 which with lookahead and
> processing and software overhead is about 50 millisec each way. To
> this you have to add the propagation through the network. Round trip
> times of 200 millisec are very common.

So because G.723.1 is bad, then everything else is?

> [YJS] I disagree that nothing can be done. Nothing can be done in a 
> pure jitter buffer system, but several good shock absorber systems are
out there.

It's not a jitter buffer thing, it's a fundamental issue. You are
playing packets as you receive them (need to reduce latency) and then
nothing comes for 200 ms (10 packets in a row). Now what? The jitter
buffer won't help you. The codec might reconstruct about 2-3 packets
decently, but after than it's going to be silence and there's just
nothing you can do about it (unless you have some revolutionary network
time machine?).

	Jean-Marc