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

stephen botzko <stephen.botzko@gmail.com> Thu, 21 January 2010 16:14 UTC

Return-Path: <stephen.botzko@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29263A6A57; Thu, 21 Jan 2010 08:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0Q-0xplGrcr; Thu, 21 Jan 2010 08:14:00 -0800 (PST)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 6DC693A6822; Thu, 21 Jan 2010 08:13:56 -0800 (PST)
Received: by gxk9 with SMTP id 9so132887gxk.8 for <multiple recipients>; Thu, 21 Jan 2010 08:13:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Wxva2YDxJEKEjaNyh/4P5fz8c7kbxuvzJVAqKjzKI0s=; b=KZKsqKT77BPuNYWZMIY2MCenuv0gbyZofQZu3XxqddmlNkYFWTEpT/XNzDm6T2+/ww dUu9Vu84isWJrfBZnOgfgDFupx8/TBsnHGfdyonXzjjinzPluGn5TOb1iuq8OyXy0tPN jXUBiBWy90jNngMlSG2UGhNn5lMdmveS0bU6I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cS97Ag49o9J4OEXm/t4IWHM2nBQlGTyLs4rvavIksNulGCLRu7VC00+RH7phQ/oARw Wj7zafGO/Fsge1Kbzrkr0WEM8Ue29Pg5pBuahlFCXYWLI0MpH41KAw7AIdTFI4sjN6hf 7NKNAdR1fNskS2486BSEDb8gE/iyN2nSqfcuE=
MIME-Version: 1.0
Received: by 10.103.80.24 with SMTP id h24mr815719mul.113.1264090422991; Thu, 21 Jan 2010 08:13:42 -0800 (PST)
In-Reply-To: <4B5870B1.5000306@octasic.com>
References: <20091223171501.7BAE33A697D@core3.amsl.com> <20100121000303.GA1250@besserwisser.org> <130EBB38279E9847BAAAE0B8F9905F8C02959FE1@esealmw109.eemea.ericsson.se> <20100121121352.GD1250@besserwisser.org> <130EBB38279E9847BAAAE0B8F9905F8C0295A258@esealmw109.eemea.ericsson.se> <6e9223711001210509k1bc134bav224a619971d04a77@mail.gmail.com> <22C4C922A49C4C0693FAEAB73E719E72@your029b8cecfe> <7AC6CC7B-C253-4719-9EB9-1B13D4B76250@bbn.com> <D7CF5A82420741EDAF61595F3B20EF78@your029b8cecfe> <4B5870B1.5000306@octasic.com>
Date: Thu, 21 Jan 2010 11:13:42 -0500
Message-ID: <6e9223711001210813q4305b67dw9f1680b90367177e@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Jean-Marc Valin <jean-marc.valin@octasic.com>
Content-Type: multipart/alternative; boundary="0016e65b625ea05af8047daefca8"
Cc: ietf@ietf.org, "Richard L. Barnes" <rbarnes@bbn.com>, codec@ietf.org, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, iesg@ietf.org, Mans Nilsson <mansaxel@besserwisser.org>, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 16:14:09 -0000

Here's what I've seen (maybe some other ITU-T attendees can comment).

The charter of SG16 (and its "questions" - like WGs in the IETF) is handled
somewhat differently than the IETF charter process.  The entire ITU-T
charter and organization is re-approved every study period (3 years), and
the organization and leadership is kept for the entire period.  Each
question has its own focus, specified in the charter.  This does not include
specific work items.  When new work is proposed, first the question agrees
to add them to its work program. Then the work program is approved by the
working party (one layer up), and finally the full study group (in a plenary
session). This happens fairly rapidly (within the same meeting session).

The ITU-T questions that do audio codecs first identify the application need
(reasonably detailed requirements) for the proposed codec, and makes sure it
does not duplicate ITU-T previous work (and other work the members know
about).  If there is agreement to proceed, the codec is added to the ITU-T
work program.  The approved work program is published, and usually sent to
other interested SDOs in liason statements.

Later on, the group works out even more specific requirements (called "terms
of reference") and develops a test plan for candidates. Often there are two
batteries of tests - a "lower bar" for qualifying reasonable candidates, and
a "higher bar" for choosing between the candidates that pass the first test.

Then it calls for proposals, accepts candidates, and starts the selection
process and characterization/testing.

Stephen Botzko
Polycom


On Thu, Jan 21, 2010 at 10:20 AM, Jean-Marc Valin <
jean-marc.valin@octasic.com> wrote:

> Hi,
>
> Actually, maybe we can look at how other SDOs are handling this issue.
> Considering that ITU-T, 3GPP/3GPP2 and (to a lesser extent) MPEG all
> standardise codecs in the same space, how do these SDOs coordinate? For
> example, does the ITU-T SG16 have some text in it's "charter" that says "we
> will communicate the requirements to 3GPP and other SDOs to see if they
> have codecs that fill these requirements"? Can someone more familiar than I
> am with the ITU-T/3GPPx/MPEG/... explain how this issue is being handled?
>
>        Jean-Marc
>
> Adrian Farrel wrote:
> > Richard,
> >
> > I think I agree...
> >
> >> It's not clear to me why SDOs need to be involved in the process of
> >> determining whether existing codecs satisfy the requirements.
> >
> > However, no-one can make the determination without requirements to make
> an
> > evaluation against.
> >
> > And to be sure that all the candidates are in the melting pot, it is at
> > worst harmless to poll the other SDOs for their input and suggestions.
> >
> > I would expect that one of the tasks of this WG is to coordinate and
> > document (i.e. make) the evaluation.
> >
> > Cheers,
> > Adrian
> >
> >> Information on standard codecs -- including their technical and legal
> >> aspects -- is pretty widely available.  And if information about a
>  codec
> >> isn't generally available (e.g., if standards are being closely  held),
> >> then that codec fails to meet the requirements by definition --
> >> there's a
> >> requirement that it by widely implementable, which requires  its
> >> specification to be widely available.
> >>
> >> I've only been following this discussion off and on, but I don't  really
> >> see anyone really challenging the requirements in the current  draft
> >> charter, and I don't really see anyone proposing codecs that  meet those
> >> requirements. Unless one of those two changes, it seems  evident that
> the
> >> requirements are not being satisfied, so we should  just move on with
> >> forming the WG.
> >>
> >> --Richard
> >>
> >>
> >>
> >> On Jan 21, 2010, at 8:39 AM, Adrian Farrel wrote:
> >>
> >>> [snip]
> >>>
> >>>>> What I try to say is that first the requirements must be set, only
> >>>>> then
> >>>>> will it be possible for representatives of other SDOs to determine
>  if
> >>>>> already standarddized codecs (or codecs under standardization)  meet
> >>>>> them.
> >>>>
> >>>> I agree.  Obviously no one (inside or outside the IETF) can tell
> >>>> exactly
> >>>> how existing codecs in other SDOs relate to this work until the
> >>>> detailed
> >>>> requirements are locked down.
> >>>>
> >>>> Also, I think the burden is mostly on CODEC to make this  assessment.
> >>>> Other
> >>>> SDOs may offer their views in liason statements, and can respond  with
> >>>> their
> >>>> own work programs.  But in the end it would be up the IETF to
> >>>> decide if
> >>>> there is too much overlap.
> >>>
> >>> Right, and this is surely easy to achieve and good project  management,
> >>> anyway.
> >>>
> >>> Document the requirements to a reasonable level of detail.
> >>> Circulate the requirements explicitly requesting suggestions.
> >>> Evaluate the suggestions and give reasons for rejecting existing
> >>> Codecs.
> >>> Go on and develop a new Codec if required.
> >>>
> >>> It does not follow that people cannot start work on a new Codec  before
> >>> completion of the third step, but the WG would be premature  to adopt a
> >>> Codec solution draft before having formally surveyed the  landscape.
> >>>
> >>> The first step has to be done anyway, and I don't see that it can be
> >>> considered as slowing down the development of a solution since it is
> >>> impossible to build a solution without knowing the requirements. The
> >>> second step might add a few weeks to the cycle. The third step, if  we
> >>> are to believe the comments in this thread, will not take long.
> >>>
> >>> So why does anyone object to such a process?
> >>>
> >>> As to whether this sequence of steps should be codified in the
>  charter,
> >>> my experience is that if you don't write down a process, it  is very
> >>> hard
> >>> to get interoperable implementations.
> >>>
> >>> Thanks,
> >>> Adrian
> >>>
> >>>
> >>> _______________________________________________
> >>> Ietf mailing list
> >>> Ietf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >>
> >
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://www.ietf.org/mailman/listinfo/codec
>
>