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

["Christian Hoene" <[e-mail]>]

Dear Herve,

> "According to reports from developers of Internet audio applications
> and
> operators of Internet audio services, there are no standardized,
> high-quality audio codecs that meet all of the following three
> conditions:
> 1. Are optimized for use in interactive Internet applications.
> 2. Are published by a recognized standards development organization
> (SDO) and therefore subject to clear change control.
> 3. Can be widely implemented and easily distributed among application
> developers, service operators, and end users."
> 
> I think it was already pointed out a few times (at least see email from
> Ingemar Johannson in November 2009), that this part needs to be
> modified as
> some existing standard codecs (at least G.711, G.722) are already
> optimized
> for interactive Internet applications, are published by recognized SDO
> (ITU-T) and can be widely implemented

... with the difference that G.711 and G.722 are not audio but narrow and
wideband speech codecs. 
They are not very efficient (=high-quality) either.

With best regards,

 Christian



> 
> Besides if easily implemented means RF it should certainly be
> explicitely
> written. Many of the codecs from e.g. ITU-T or 3GPP can be considered
> as
> easily implementable and distributable, optimized for internet
> applications
> and published by recognized SDOs.
> 
> Best regards
> 
> Herve
> 
> 
> 
> 
> On Dec 23, 2009, at 9:15 , IESG Secretary wrote:
> 
> > A new IETF working group has been proposed in the Real-time
> Applications
> > and Infrastructure Area.  The IESG has not made any determination as
> yet.
> > The following draft charter was submitted, and is provided for
> > informational purposes only.  Please send your comments to the IESG
> > mailing list ([e-mail]) by January 20, 2010.
> >
> > Internet Wideband Audio Codec (codec)
> > ---------------------------------------------------------------------
> ----
> > Last Modified: 2009-12-17
> >
> > Proposed Chair(s):
> > * TBD
> >
> > Real-time Applications and Infrastructure Area Director(s):
> > * Robert Sparks <[e-mail]>
> > * Cullen Jennings <[e-mail]>
> >
> > Real-time Applications and Infrastructure Area Advisor:
> > * Cullen Jennings <[e-mail]>
> >
> > Mailing Lists:
> > General Discussion: [e-mail]
> > To Subscribe: [e-mail]
> > In Body: subscribe
> > Archive: https://www.ietf.org/mailman/listinfo/codec
> >
> > Description of Working Group
> > Problem Statement
> >
> > According to reports from developers of Internet audio applications
> and
> > operators of Internet audio services, there are no standardized,
> > high-quality audio codecs that meet all of the following three
> > conditions:
> >
> > 1. Are optimized for use in interactive Internet applications.
> >
> > 2. Are published by a recognized standards development organization
> > (SDO) and therefore subject to clear change control.
> >
> > 3. Can be widely implemented and easily distributed among application
> > developers, service operators, and end users.
> >
> > There exist codecs that provide high quality encoding of audio
> > information, but that are not optimized for the actual conditions of
> the
> > Internet; according to reports, this mismatch between design and
> > deployment has hindered adoption of such codecs in interactive
> Internet
> > applications.
> >
> > There exist codecs that can be widely implemented and easily
> > distributed, but that are not standardized through any SDO; according
> to
> > reports, this lack of standardization and clear change control has
> > hindered adoption of such codecs in interactive Internet
> applications.
> >
> > There exist codecs that are standardized, but that cannot be widely
> > implemented and easily distributed; according to reports, the
> presence
> > of various usage restrictions (e.g., in the form of requirements to
> pay
> > royalty fees, obtain a license, enter into a business agreement, or
> meet
> > other special conditions imposed by a patent holder) has hindered
> > adoptions of such codecs in interactive Internet applications.
> >
> > According to application developers and service operators, an audio
> > codec that meets all three of these would: (1) enable protocol
> > designers to more easily specify a mandatory-to-implement codec in
> > their protocols and thus improve interoperability; (2) enable
> > developers to more easily easily build innovative, interactive
> > applications for the Internet; (3) enable service operators to more
> > easily deploy affordable, high-quality audio services on the
> Internet;
> > and (4) enable end users of Internet applications and services to
> enjoy
> > an improved user experience.
> >
> > Objectives
> >
> > The goal of this working group is to develop a single high-quality
> audio
> > codec that is optimized for use over the Internet and that can be
> widely
> > implemented and easily distributed among application developers,
> service
> > operators, and end users.  Core technical considerations include, but
> > are not necessarily limited to, the following:
> >
> > 1. Designing for use in interactive applications (examples include,
> but
> > are not limited to, point-to-point voice calls, multi-party voice
> > conferencing, telepresence, teleoperation, in-game voice chat, and
> live
> > music performance)
> >
> > 2. Addressing the real transport conditions of the Internet as
> > identified and prioritized by the working group
> >
> > 3. Ensuring interoperability with the Real-time Transport Protocol
> > (RTP), including secure transport via SRTP
> >
> > 4. Ensuring interoperability with Internet signaling technologies
> such
> > as Session Initiation Protocol (SIP), Session Description Protocol
> > (SDP), and Extensible Messaging and Presence Protocol (XMPP);
> however,
> > the result should not depend on the details of any particular
> signaling
> > technology
> >
> > Optimizing for very low bit rates (typically below 2.4 kbps) and for
> > non-interactive audio is out of scope because such work might
> > necessitate specialized optimizations.
> >
> > Although the codec produced by the working group might be used as a
> > mandatory-to-implement technology by designers of particular Internet
> > protocols, it is explicitly not a goal of the working group to
> produce a
> > codec that will be mandated for use across the entire IETF or
> Internet
> > community nor would their be any expectation that this would be the
> only
> > mandatory-to-implement codec.
> >
> > The goal of the working group is to produce only one codec.  Based on
> > the working group's analysis of the design space, the working group
> > might determine that it needs to produce more than one codec, or a
> codec
> > with multiple modes; however, it is not the goal of working group to
> > produce more than one codec, and to reduce confusion in the
> marketplace
> > the working group shall endeavor to produce as few codecs as
> possible.
> >
> > In completing its work, the working group should collaborate with
> other
> > IETF working groups to complete particular tasks.  These might
> include,
> > but would not be limited to, the following:
> >
> > - Within the AVT WG, define the codec's payload format for use with
> the
> >  Real-time Transport Protocol (RTP).
> >
> > - Collaborate with working groups in the Transport Area to identify
> >  important aspects of packet transmission over the Internet.
> >
> > - Collaborate with working groups in the Transport Area to understand
> >  the degree of rate adaptation desirable, and to reflect that
> >  understanding in the design of a codec that can adjust its
> >  transmission in a way that minimizes disruption to the audio.
> >
> > - Collaborate with working groups in the RAI Area to ensure that
> >  information about and negotiation of the codec can be easily
> >  represented at the signaling layer.
> >
> > The working group will inform the ITU-T (Study group 16) of each new
> > revision of working group drafts, with the intent of submitting the
> > completed codec RFC for co-publication by the ITU-T if the ITU-T
> finds
> > that appropriate. 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 and would therefore enable co-publication of an existing
> > standard at the IETF. The working group will also continue to discuss
> > with other standards bodies to determine if it becomes possible to
> > satisfy the IETF requirements through a new or revised standard at
> other
> > bodies.
> >
> > Suggested Codec Standardization Guidelines and Requirements for
> > achieving the foregoing objectives are provisionally outlined in
> > draft-valin-codec-guidelines and draft-valin-codec-requirements
> > respectively; these documents will form the starting point for
> working
> > toward consensus and, if accepted as work items of the working group,
> > will be refined by the working group in accordance with the usual
> IETF
> > procedures.
> >
> > A codec that can be widely implemented and easily distributed among
> > application developers, service operators, and end users is
> preferred.
> > Many existing codecs that might fulfill some or most of the technical
> > attributes listed above are encumbered in various ways.  For example,
> > patent holders might require that those wishing to implement the
> codec
> > in software, deploy the codec in a service, or distribute the codec
> in
> > software or hardware need to request a license, enter into a business
> > agreement, pay licensing fees or royalties, or attempt to adhere to
> > other special conditions or restrictions.
> >
> > Because such encumbrances have made it difficult to widely implement
> and
> > easily distribute high-quality audio codecs across the entire
> Internet
> > community, the working group prefers unencumbered technologies in a
> way
> > that is consistent with BCP 78 and BCP 79.  In particular, the
> working
> > group shall heed the preference stated in BCP 79: "In general, IETF
> > working groups prefer technologies with no known IPR claims or, for
> > technologies with claims against them, an offer of royalty-free
> > licensing."  Although this preference cannot guarantee that the
> working
> > group will produce an unencumbered codec, the working group shall
> > attempt to adhere to the spirit of BCP 79.  This preference does not
> > explicitly rule out the possibility of adapting encumbered
> technologies;
> > such decisions will be made in accordance with the rough consensus of
> > the working group.
> >
> > Deliverables
> >
> > 1. A set of Codec Standardization Guidelines that define the work
> > processes of the working group. This document shall be Informational.
> >
> > 2. A set of technical Requirements. This document shall be
> > Informational.
> >
> > 3. Specification of a codec that meets the agreed-upon requirements,
> in
> > the form of an Internet-Draft that defines the codec algorithm along
> > with source code for a reference implementation.  The text
> description
> > of the codec shall indicate which components of the encoder and
> decoder
> > are mandatory, recommended, and optional.  It is envisioned that this
> > document shall be a Proposed Standard document.
> >
> > Milestones
> >
> > Mar-2010: WGLC on Codec Standardization Guidelines
> > May-2010: Codec Standardization Guidelines to IESG (Informational)
> > May-2010: WGLC on Requirements
> > Jul-2010: Requirements to IESG (Informational)
> > Dec-2010: Freeze codec structure
> > Jun-2011: Finalize codec parameters
> > Jul-2011: WGLC on codec specification
> > Oct-2011: Submit codec specification to IESG (Standards Track)
> > _______________________________________________
> > codec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/codec
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
> 
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec