Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

Michael Thornburgh <mthornbu@adobe.com> Wed, 13 November 2013 23:33 UTC

Return-Path: <mthornbu@adobe.com>
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 6D21F11E8128 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 15:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.672
X-Spam-Level:
X-Spam-Status: No, score=-5.672 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Z4japQNJKtAP for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 15:33:05 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 220F011E810B for <rtcweb@ietf.org>; Wed, 13 Nov 2013 15:33:02 -0800 (PST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUoQMLUMUN3y3ISNMjLEtUSUJoO3xm6go@postini.com; Wed, 13 Nov 2013 15:33:02 PST
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rADNTGt2026431; Wed, 13 Nov 2013 15:29:16 -0800 (PST)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rADNX06A020222; Wed, 13 Nov 2013 15:33:00 -0800 (PST)
Received: from nambx08.corp.adobe.com ([10.8.189.94]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 13 Nov 2013 15:33:00 -0800
From: Michael Thornburgh <mthornbu@adobe.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Date: Wed, 13 Nov 2013 15:32:58 -0800
Thread-Topic: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
Thread-Index: Ac7gwE88WKQvVpJCQMqENAsR5FljCgAB00OQ
Message-ID: <D9D602D39A98E34D9C43E965BEC7439834E61DE3@nambx08.corp.adobe.com>
References: <5282A340.7010405@gondwanaland.com> <20131113165526.GA13468@verdi> <5283E700.5090300@bbs.darktech.org> <CACKRbQf=x-wKUFemNhf4ZDwgZzqBFq=okUMw=BLCwaMmE7OJPw@mail.gmail.com> <5283FDF1.8030708@bbs.darktech.org>
In-Reply-To: <5283FDF1.8030708@bbs.darktech.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D9D602D39A98E34D9C43E965BEC7439834E61DE3nambx08corpadob_"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
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: Wed, 13 Nov 2013 23:33:13 -0000

> The real revolution is P2P: massive cost savings, ease of deployment and most importantly: cutting out the middle man. The status quo (H.264 over Flash) does not do this.

note: Flash has had P2P for real time communication since 2009.

-michael thornburgh

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc
Sent: Wednesday, November 13, 2013 2:32 PM
To: Kaiduan Xie
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"


I agree. I'm just pointing out that John's argument (quoted below) doesn't make any sense. Choosing "no MTI" doesn't make Cisco any more likely to implement VP8.

If we choose "No MTI" we will end up with transcoding, plain and simple. One crowd will only implement H.264. The other crowd will only implement VP8. All the useless middlemen will rejoice, having killed a technology that puts them out of business.

Providing "video chat without a plugin" is not revolutionary. Flash is already installed on 95% of the market. That's more people than WebRTC can reach today, so we're not "liberating" those people from anything.

The real revolution is P2P: massive cost savings, ease of deployment and most importantly: cutting out the middle man. The status quo (H.264 over Flash) does not do this.

P2P cannot work unless 95% of clients can agree on a common codec. I say again: start with H.261 and upgrade to VP8 or H.264. This way everyone can be happy:

 *   The VP8 crowd can use VP8
 *   The H264 crowd can use H264
 *   The enterprise crowd can transcode
 *   If all of the above fails, we can fallback on H.261.

Yes, this carries the burden of implementing H.261 but this is a solved-problem. There are plenty of free implementations and is a much easier problem to solve than getting the H.264 and VP8 crowd to agree to implement each other's codec.

Start with H.261 and replace it the moment you find something better. Forcing us to transcode or drop video calls is not a solution.

Gili
On 13/11/2013 4:57 PM, Kaiduan Xie wrote:
"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you still have to pay a lot of money.

/Kaiduan

On 13/11/2013 11:55 AM, John Leslie wrote:
    And I claim that both camps are actually more likely to implement
(or allow extensions for) the other side's codec if it is _not_ MTI,
simply because they can back out at the first sign of lawyers.