Re: [rtcweb] RTCWEB needs an Internet Codec

Ron <ron@debian.org> Sat, 01 September 2012 06:12 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2121F84AE for <rtcweb@ietfa.amsl.com>; Fri, 31 Aug 2012 23:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC3oo23VlZft for <rtcweb@ietfa.amsl.com>; Fri, 31 Aug 2012 23:12:42 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8D21F84A1 for <rtcweb@ietf.org>; Fri, 31 Aug 2012 23:12:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkHAK6lQVB5LWvi/2dsb2JhbABFtnmEJYEIgiABAQQBOg0PIwULCw4KLhQYDSQTiAcFq2mOZIsNhyMDiE2FKIdiAZAagnM
Received: from ppp121-45-107-226.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.107.226]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Sep 2012 15:42:38 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 6B6F04F8F3; Sat, 1 Sep 2012 15:42:37 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oBaMXF5qemcm; Sat, 1 Sep 2012 15:42:36 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4FB9B4F902; Sat, 1 Sep 2012 15:42:36 +0930 (CST)
Date: Sat, 01 Sep 2012 15:42:36 +0930
From: Ron <ron@debian.org>
To: Cameron Byrne <cb.list6@gmail.com>
Message-ID: <20120901061236.GH23434@audi.shelbyville.oz>
References: <CAC8DBE4E9704C41BCB290C2F3CC921A162D278D@nasanexd01h.na.qualcomm.com> <503FC1BF.5020004@alvestrand.no> <CAC8DBE4E9704C41BCB290C2F3CC921A162D2B0F@nasanexd01h.na.qualcomm.com> <5040541C.5020008@alvestrand.no> <20120831133845.GW72831@verdi> <5040CE32.5050003@jesup.org> <20120831151247.GY72831@verdi> <CAD6AjGToznJtNdSzyFbxKhhXQTLTuOWnPutOYDCQCVH_8mRZ5w@mail.gmail.com> <20120901031955.GF23434@audi.shelbyville.oz> <CAD6AjGTN6JTQ50bj-6v2vvw56HOWNA7VmP-BZFwNWiX-c0AAnA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAD6AjGTN6JTQ50bj-6v2vvw56HOWNA7VmP-BZFwNWiX-c0AAnA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Sep 2012 06:12:43 -0000

On Fri, Aug 31, 2012 at 09:38:11PM -0700, Cameron Byrne wrote:
> On Fri, Aug 31, 2012 at 8:19 PM, Ron <ron@debian.org> wrote:
> > On Fri, Aug 31, 2012 at 08:40:43AM -0700, Cameron Byrne wrote:
> >> Agree with the above. G.711 for mti only.
> >>
> >> I want to push Opus and promote its use, but MTI is not the right method
> >> for that.
> >
> > I haven't got the impression from this discussion that anybody thinks it
> > is about "pushing Opus" at all.  The question is what is best for rtcweb.
> >
> > Since the charter of this group is to produce a standard that facilitates
> > "direct interactive rich communication", using things that already exist
> > as much as possible - I thought it was clear that the only important point
> > is that all this engineering work to produce rtcweb should not be a complete
> > waste of time for the people actually implementing it, and produce something
> > that gives such a poor experience in its baseline configuration that nobody
> > would ever actually want to use it for any of its intended purposes.
> >
> > That Opus is a very obvious choice of existing technology, which no other
> > single codec comes anywhere close to matching for this purpose, stands out
> > like an elephant in the room.  Blind men might argue about whether it is a
> > pillar or a brush, or whether enough double blinded men have yet touched it
> > to be sure of this, but no amount of "pushing" is going to realistically
> > move it from that position one way or the other.
> >
> > Pretending that other much-poorer codecs could fill this role is abandoning
> > the "rich communication" part of the charter, and condemning this group to
> > an embarrassing failure to achieve its goals in any meaningful way.
> >
> > Let's not do that shall we.  It seems quite clear that many people have an
> > intense interest in its success.  Delaying this indefinitely, or selecting
> > poorer options than are already available today do not seem like the choices
> > that rational people who actually do want this to succeed would make.
> >
> > Interoperability requires an adequate MTI codec.  Nobody has proposed an
> > alternative codec that is not clearly inadequate by comparison to Opus.
> > In a room full of clever engineers who want rtcweb to excel as a best of
> > breed specification, this decision should be a total no-brainer.
> >
> 
> MTI is not about a room full of clever engineers, this thread and the
> position statements from XYZ companies should make that clear.  MTI is
> about the least common denominator for a series of latent issues,

Yes, and least common denominator here doesn't mean "the worst possible
codec that we can think of which might be called a codec".  Nobody has
proposed any credible alternative to Opus that might reasonably be seen
as a plausible common denominator to a broad spectrum of the use cases.

Opus doesn't just simply cover that range.  It trounces pretty much every
other codec across the whole spectrum, except for a tiny little corner of
the extreme low-bandwidth case, where it's marginally worse than something
which already sounds terrible.

When your least common denominator also happens to be the best of breed
across that whole range, that's a Good Thing right?  Something to thank
your lucky engineering stars for, not something to prevaricate about.

> including IPR FUD and legacy baggage.

FUD has no place here whatsoever, however popular it might be.
Legacy baggage is a "will consider" item in the group charter, not a
"will be stupidly constrained by to the detriment of the project".

> Consenting adults are free to offer and answer whatever codecs they like.

Yes.  Yes, they are.  And nobody has said or is saying they can't do so.

It's also not the question here.  The question is what is the minimum
guarantee that any rtcweb user will have when talking to any other
rtcweb user, without first needing to sign consent forms and download
optional extras (possibly for a reasonably non-discriminatory fee,
and even possibly trojaned).

If the answer to that is "something terrible", then it's like suggesting
that "Consenting adults are free to put wheels on their car".

Of course they are, but it will be pretty useless for its intended purpose
without them - and nobody in their right mind would make something like
that deliberately.

 hth,
 Ron