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 : codec-bounces(_at_)ietf(_dot_)org
[mailto:codec-bounces(_at_)ietf(_dot_)org] De la part de Christian Hoene
Envoyé : mardi 12 janvier 2010 01:28
À : MARJOU Xavier RD-CORE-LAN
Cc : 'IAB IAB'; codec(_at_)ietf(_dot_)org; '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
codec(_at_)ietf(_dot_)org
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.
********************************
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf