Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

[<[e-mail]>]

Hello

> Obviously, the current requirements document does contain features which are not supported by today's standardized codecs. As an example, take time
> stretching and time compression. Thus, everybody following the discussion must come to the conclusion that (2) has been answered with no.  

The requirements document is part of the deliverables identified in the Charter for May 2010. So it has to be produced by the Group once agreed to be launched : work has still to be done and drawing conclusions now on the basis of this document is not acceptable.

It is also stated in the Charter :  "The working group will communicate detailed description of the requirements and goals to other SDOs including the  ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements"
Why then bother other SDOs with this if the answer is already known and is so obviously "no" ?

Regarding the point related to time stretching and shortening, if it is the only requirement not met, we all now that adaptive jitter management can be considered as an additional function at the decoder side that can be handled outside the codec itself. And if you really still need to increase performance by some modifications at encoder side (on the basis on "non existing yet" performance requirements ) it would be much easier to have an existing standard extended by ITU-T or 3GPP than developping a fully new codec for this !

So I disagree with your conclusion and related arguments : let's establish and agree on real technical requirements first and then analyse existing standards and possible efficient adaptations before starting developping et new codec ! 

Best regards

Stephane

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Christian Hoene
Envoyé : mardi 12 janvier 2010 01:28
À : MARJOU Xavier RD-CORE-LAN
Cc : 'IAB IAB'; [e-mail]; 'IETF Discussion'; 'IESG IESG'
Objet : Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Dear Xavior Marjou,

> We fully share the points 1) and 2) stated in the e-mail below from 
> Cullen since implementing and deploying a new codec in networks 
> (gateways, service plate-forms, mediaservers...) and in terminals 
> represents high costs for service providers, manufacturers and chipset 
> providers in terms of development, deployment and testing with risks 
> to create bugs and problems affecting customers. Furthermore, this 
> multiplies the problems of interoperability with already deployed 
> codecs and the transcoding needs to be addressed with related costs
> (gateways) and quality degradations.

I have heard similar concerns from German traditional telcos, too. However, the currently envisioned codec is based on a more Internet like scenario: a dumb network and smart end terminal. This means: fewer gateways and less transcoding inside the network but smarter end terminals (=phones). Also, the codec is intended to be used in an end-to-end fashion with the encoding and decoding done at the Internet phones. 

If a phone needs to communicate with a gateway, it can use G.729 or G.711.
Thus, I do not see an immediate need to enhance gateways to support the new codec nor any costs involved with that. Similar, phones must not be updated if the old small or wideband quality is sufficient. 

Every new technology comes with bugs and problems at the beginning. But the new codec will have new features and better quality (e.g. playing music and listening to music, higher reliability because of rate adaptation, etc.), which will attract customers. Thus, one should bear the costs to deploy it; otherwise a provider will lose its market share.

> Therefore, the 3 stages mentionned are essential to be run
> sequentially:
> "(1) get consensus on the requirements, (2) see if an existing codec 
> meets the requirements, and (3) specify a new codec only if none are 
> found in stage 2. Initially the WG would be chartered for (1) and when 
> that was done it would be re-charted for (2) and so on. "

Obviously, the current requirements document does contain features which are not supported by today's standardized codecs. As an example, take time stretching and time compression. Thus, everybody following the discussion must come to the conclusion that (2) has been answered with no. 

> Requirements established first in stage 1 shall be sent for stage 2 to 
> other SDOs as stated in the current version of the Charter:
> 
> " The working group will communicate detailed description of the 
> requirements and goals to other SDOs including the ITU-T, 3GPP, and 
> MPEG to help determine if existing codecs meet the requirements 
> "(however in the current version of the Charter, it is inconsistent to 
> state first that the goal of the WG is to develop of a new codec and 
> to state some lines after that existing codecs will be considered...)
> 
> Based on the answers collected from these SDOs, conclusion for stage 2 
> shall be delivered and constitute the input and prerequisit for any 
> decision to continue in stage 3 to produce a new codec and re-Charter 
> the Group for this

Your changes look like an attempt to slow down and hinder the work. As Monty, I have to object your arguments.

With best regards,

 Christian


_______________________________________________
codec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/codec

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************