Re: [rtcweb] Making both VP8 and H264 MTI

cowwoc <cowwoc@bbs.darktech.org> Wed, 06 November 2013 10:10 UTC

Return-Path: <cowwoc@bbs.darktech.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 BF0A711E8126 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 02:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.394
X-Spam-Level:
X-Spam-Status: No, score=-4.394 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 qeygxDpk5cJG for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 02:10:47 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id D479511E8122 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 02:10:46 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id aq17so16967263iec.38 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 02:10:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AO3H6sXQMkcGBixjp8/+9wFx92zn9KDPsMGnmCesEQc=; b=MvQubPJGG47tgKdO71Dl+Qml+PDcjOqo56ThYqM36l506xsS3nNd6zIqiIbIfXukIP hnX370dLE2spBeHcO7/tWMb7MM/0y7nO8YEKbk3cnnWcUd5/rZbHZ5IhTLc2xt7uB3XE kT6Qkim7/LBWEKEOqPxGu/oCk4/2X0C3gfcqFdzXYPTgcBlm4brfuE5tZkTf2iBSDpVL 6wWUFQ51LFaHZYm9uvdDtvXcQA1X034m55+AtYhfoVkHybiQtLfdPwFC25ZEbfyOtUYS F61jZ9N6CmAPe+2tE/SwZV1YLRiboZIBq7m1obJrYAWvE9m68UAf1rvryVgMDgEOpqHn yaoQ==
X-Gm-Message-State: ALoCoQl1Vr/Ddsia8diVTvo9GROqeup70i6MAbu8Dyvnxdd9u1456AvKn8PePUt3pb1t7nn3X9l4
X-Received: by 10.50.77.83 with SMTP id q19mr1753834igw.21.1383732645978; Wed, 06 Nov 2013 02:10:45 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id cl4sm26505778igc.1.2013.11.06.02.10.44 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 02:10:45 -0800 (PST)
Message-ID: <527A15A3.2090006@bbs.darktech.org>
Date: Wed, 06 Nov 2013 05:10:43 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: miconda@gmail.com, rtcweb@ietf.org
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <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>
In-Reply-To: <527A0C4D.7020707@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 06 Nov 2013 10:10:52 -0000

On 06/11/2013 4:30 AM, Daniel-Constantin Mierla wrote:
> As it stands today, there are well known IPR issues with h264. Cisco's 
> move doesn't lift them.
>
> So why to choose it if falls under the rules to remove it?
>

     No one says it has to be H.264 and VP8. It could be H.261 and VP8.

> With both on board, I still expect the majority of the apps will 
> implement only the most convenient for them, eventually expecting the 
> other to have both. Then responsibility is getting divided, like "it's 
> not _only_ my fault", blaming the other end point as well. 

     That is a reasonable concern, and one that we need to address. 
Implementations that violate these rules will make it harder for us to 
replace older MTI codecs without breaking backwards compatibility.

Gili