Re: [rtcweb] Video codec selection - way forward

cowwoc <cowwoc@bbs.darktech.org> Thu, 14 November 2013 05:22 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 480ED21E81B0 for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 21:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.118
X-Spam-Level:
X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=-0.519, 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 mgtT7ino3Qqo for <rtcweb@ietfa.amsl.com>; Wed, 13 Nov 2013 21:22:50 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0972C21E81BC for <rtcweb@ietf.org>; Wed, 13 Nov 2013 21:22:41 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id ar20so2056474iec.5 for <rtcweb@ietf.org>; Wed, 13 Nov 2013 21:22:41 -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=Pf3WxOGvTpD8AsyqryR82RGZhdiVllHHC/iLOrmJwZM=; b=TyC5modlXOzdjcKkgf3OmdhQ1EdykGDbK1Gnoa1bdb2OWYDvdLjiovJqTIULyKS6a5 71H2mz4/cm7NybstbnX45kqRO4jQ+eD/xXfQ2IQog7ENkUbKEz+c3R70nNmjjW/cKLRJ RpfSeb+JPefe5CiTd4y2pvXXSQ4LUZ8+afaF4TDC+/jn2H1unbNGyRO1jSgVjVM2akP6 JXYA98a/Tw8r2OyoX8WZAyi2XcIE06kcI4K5fnJk7W1Ik+4sVbVW6bmhhDt85zvW42V3 KfQU1lz5CIzUu870sYrxD79DxJOLmcTyXv1Pg8uJBEV0Zl+fiQTG7ElHr/zgj/xRGbhc PAhQ==
X-Gm-Message-State: ALoCoQmeuhfHtFCbhjFSLHyOVDalX2aGHcg6UdT/FATQEpqsUtLJgEEgIPRRTc9Y1coZS0x2+Me7
X-Received: by 10.50.23.103 with SMTP id l7mr346936igf.3.1384406561675; Wed, 13 Nov 2013 21:22:41 -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 yt10sm34627638igb.9.2013.11.13.21.22.40 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 21:22:41 -0800 (PST)
Message-ID: <52845E10.4040205@bbs.darktech.org>
Date: Thu, 14 Nov 2013 00:22:24 -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: rtcweb@ietf.org
References: <5283DFDC.4010906@ericsson.com> <CAD6AjGQwhmhmpJh7=ORYc=FRQMnOO=1vCNMCmXaYFXmC71rKMQ@mail.gmail.com>
In-Reply-To: <CAD6AjGQwhmhmpJh7=ORYc=FRQMnOO=1vCNMCmXaYFXmC71rKMQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Video codec selection - way forward
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, 14 Nov 2013 05:22:56 -0000

On 13/11/2013 11:11 PM, cb.list6 wrote:
>
> Why no SHOULD implement vp8 and h248? SHOULD means you will do it 
> unless you have a real good reason.
>

SHOULD doesn't carry any accountability. Anyone will tell you they have 
a "real good reason" to avoid implementing one codec or another. We've 
heard plenty of excuses on this list of why one party or another 
believes it is legally risky to implement VP8 or H.264, respectively. So 
in that sense, it is meaningless.

> MUST is too hard for this WG.  Many implementations have a really good 
> reason to not do vp8 OR h248.
>
> Saying that all webrtc MUST do one or the other or both is disingenuous.
>
> SHOULD for both is as good as we are going to get with this 
> complicated IPR environment.  Using MUST is simply not going to work 
> and we have 10,000 on this mailer to back that up.
>

What you say is true, but if we accept this (and go with SHOULD) we are 
essentially ending up with "no MTI" which leads to the dark side 
(transcoding or dropped calls).

Rock --> WebRTC <-- Hard place :)

Gili