Subject: [codec] G.722

From: Koen Vos <[email-masked]>
Date: Tue, 04 Aug 2009 17:47:15 -0700

Stéphane,

G.722 has weaknesses:
- High bitrate.
- The original G.722 was not suited for the Internet because it lacked  
a PLC. In recent years, this problem has been addressed by extending  
the standard with appendices III and IV.

Deployment on a few million hardware devices does not mean a codec is  
widely and easily distributable. Indeed, such a requirement is not  
among the codec selection criteria mentioned in the DECT Liaison.

koen.

Quoting [email-masked]:

> G.722 is already massively deployed and used for mass market WB  
> telephony services overs IP and provides a very good wideband voice  
> quality at 64 kbit/s confirmed by the feedback from customers.
>
> Please have a look on the LS from DECT (distributed by Cullen  
> Jenning on this e-mail reflector in attached e-mail in  
> "DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf")
>
> Extract :
>
> "Additionally, ETSI TC DECT would like to point out that millions of  
> devices implementing ITU-T G.722
> codec were manufactured, sold in several countries and are available  
> worldwide now"
>
> Stéphane
>
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la  
> part de Alan Johnston
> Envoyé : jeudi 30 juillet 2009 01:42
> À : [email-masked]
> Objet : [codec] Comments
>
> I'm not going to comment on the details of the charter but instead  
> just talk about the high level issues.
>
> The situation today is awful - there are a number of good new  
> Internet codecs, but few have deployed them - no one wants to be the  
> first, and in the meantime, we are stuck with G.711 et al.  We need  
> to try something to break us out of this situation, and this effort  
> seems like it could really help.  I can't see how it could harm the  
> situation.
>
> Secondly, it seems like all previous codecs have been designed in  
> isolation, or with the needs of some specific layer 2 transport in  
> mind.  What if we really thought hard and came up with the  
> requirements for our ultimate Internet codec?  What kinds of things  
> could we think of?  If we don't do the work, we will never know, and  
> we may yet come up with a codec that has a compelling deployment  
> story.
>
> And then we'd really be getting somewhere...
>
> Thanks,
> Alan
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: Steve Underwood <[email-masked]>
Date: Wed, 05 Aug 2009 09:01:04 +0800

> the standard with appendices III and IV.
These definitions of PLC schemes in standards puzzle me. They have no 
effect on the signal on the wire, so why are they defined? The 
implementer of the receiving side is actually free to implement anything 
interesting they can come up with.
> among the codec selection criteria mentioned in the DECT Liaison.

Steve

---

From: Koen Vos <[email-masked]>
Date: Tue, 04 Aug 2009 20:22:09 -0700

Quoting Steve Underwood:

> These definitions of PLC schemes in standards puzzle me. They have  
> no effect on the signal on the wire, so why are they defined? The  
> implementer of the receiving side is actually free to implement  
> anything interesting they can come up with.

The same is true for the rest of the decoder. One purpose of a  
standard is to guarantee a certain quality level over a range of  
conditions. Having the PLC in the standard extends that range to  
include packet loss.

On a technical level: For good results, a PLC operates on  
decoder-internal parameters and states, which requires tight  
algorithmic integration. Also, a good PLC method for one codec may  
perform poorly with another codec. So the PLC is as much part of a  
decoder as any other decoder module. The complete package is compiled  
together to create the optimized binary library typically sold by  
vendors. You can't mix-and-match binary decoder modules from different  
vendors.

The above also applies to time compression/stretching methods, for  
handling network jitter.

koen.