Re: [rtcweb] Making both VP8 and H264 MTI

Ron <ron@debian.org> Thu, 07 November 2013 12:47 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 EB28121E819D for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 04:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level:
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_URI_MEDS=0.842]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y07TjSqPlxHl for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 04:47:17 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id DE72321E81A6 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 04:46:30 -0800 (PST)
Received: from ppp121-45-83-213.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.83.213]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Nov 2013 23:16:15 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 6E3A44F8F3 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 21:57:25 +1030 (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 YiapVzhqQaJg for <rtcweb@ietf.org>; Thu, 7 Nov 2013 21:57:24 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 0A9F34F902; Thu, 7 Nov 2013 21:57:24 +1030 (CST)
Date: Thu, 7 Nov 2013 21:57:24 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131107112723.GE3245@audi.shelbyville.oz>
References: <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <E44893DD4E290745BB608EB23FDDB7620A108AAB@008-AM1MPN1-041.mgdnok.nokia.com> <CAMwTW+g+iHWCkoUonjYFi6OrSNcSQZX2X4GtKG5Ae4Ubzv0LtA@mail.gmail.com> <A869F270-C9B9-48EE-9A71-75BA9F2684EC@apple.com> <527A06EF.2070007@bbs.darktech.org> <527A0C4D.7020707@gmail.com> <527A15A3.2090006@bbs.darktech.org> <CA+E6M0mrrj+hKgxkXyvsd+J1yLVV0WAtM_MsNP4qcFkd8F15hA@mail.gmail.com> <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9D0FB49D-EF67-4C21-A818-A611F9325EFF@apple.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Making both VP8 and H264 MTI
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: Thu, 07 Nov 2013 12:47:24 -0000

On Thu, Nov 07, 2013 at 03:04:06PM +0900, David Singer wrote:
> 
> On Nov 7, 2013, at 5:33 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:
> 
> > Hi,
> > 
> > There isn't much new in the arguments for and against VP8 vs H.264. Its
> > clear that there are concerns that are beyond how well each codec performs
> > and whether or not it is free. Although I recognize that the transcoding
> > option does not address the P2P use case, I do think that the goal of
> > interoperability can be better achieved through a two phase approach. The
> > first is enabling end-points to inter-operate through the availability of
> > transcoding from the service provider. The second is to make one of the
> > codecs the defacto MTI because of the its higher level of adoption. Yes, we
> > may never get to a single MTI if we follow this path but at least we will
> > have endpoints inter-operating. Besides, there are multiple other
> > difficulties in getting seamless P2P communications working all the time,
> > so I would suggest focusing on the service provider centered use case
> > first.
> 
> You know, you're right.  
> 
> We could suggest or even recommend both, and mandate you must implement at
> least one of the two. That would identify precisely two interoperability
> points in an otherwise much larger space, at least, and make it fairly simple
> for those that can and wish to, to offer transcoding, since the two ends are
> now defined.  It's not ideal, but it might be better than saying nothing at
> all.

I thought the performance and other problems with forcing _everyone_ through
a central relay server were well known?  I would have thought David at least
would be somewhat aware of them.  Adding that to a guaranteed interop failure
outcome might be a cunning plan, but I wouldn't call it a good one.

http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/

The whole point of a MTI codec is there will be no "otherwise larger space"
if we choose one that all implementors are free to use.

  Ron