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

Gili <> Thu, 14 November 2013 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7014411E80FA for <>; Thu, 14 Nov 2013 11:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ts5dFOJt2b0 for <>; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9F6E511E810D for <>; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
Received: by with SMTP id tp5so3488365ieb.0 for <>; Thu, 14 Nov 2013 11:52:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=/jnttbTzBoWThiEcO1MpywZ4Xge35MnHsx+Uc3n8NO8=; b=Eqh6W47P4p10wpBbVXDJ4oMJrf7AWwXMHjcseJCSVg7ismCQwlA2+0BJCq6Mn1faE1 BUvF5OawMOBqLEHWOvbMwVVqvinASIgk3KEClgfeYrfGMA5qbENALHVO2BW0ZUOTDobG oJMUM946XRCqJaR58ytRv5Ebkf5zGq+DK6HzJvkOBXYAXIwcX6ZvjnpDb9TycfbD9Nvq A8UzuFu/bX62/tVlXl+tquvzHAe3Ql4vKQ0T0nMNF28YDQAjRIKR2U6XoNUQnJ8rOSlv SWCrpHC23n6BDFqTsSkZ8iHX+Lk8hJ3uVgnDkwaBZ1dhZS8W///koN0ziV2V9mqg9+X+ GC3w==
X-Gm-Message-State: ALoCoQnb4HgskCjXQojGOWFYLKRqPhxu4MjT7ZtlquO5HfPlaIwOzmkEURBdTiBw8xf4kn6zCxL+
X-Received: by with SMTP id a1mr2484368igv.58.1384458740900; Thu, 14 Nov 2013 11:52:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w7sm6294627igp.1.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:52:20 -0800 (PST)
Message-ID: <>
Date: Thu, 14 Nov 2013 14:52:11 -0500
From: Gili <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <20131113165526.GA13468@verdi> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2013 19:52:27 -0000


On 14/11/2013 2:41 PM, Jonathan Rosenberg wrote:
> An important drawback of H.261 as MTI is interop with existing 
> installed base. Very old conferencing systems and products may still 
> have it since its easier to keep the code than delete it, but new 
> platforms in the last few years will not have H.261.

If older platforms had working implementations, it could always be added 
back in. Meaning, there should be plenty of mature implementation out in 
the wild.

> I also disagree with the assertion that H.261 video is better than 
> audio only. Video quality matters and I believe the higher quality 
> we've been able to achieve in recent years due to the combo of better 
> tech (ala H.264) along with faster networks is a material factor in 
> the acceptance of video by end users. I think folks writing the apps 
> should decide whether lousy video is good enough, and for business 
> usage the answer is no.

I don't think that's for the specification to say. Let the developer 
decide which is better. I provided plenty of examples where a 
lower-resolution H.261 feed is preferable to audio-only (e.g. video 
games). The specification should give developers the option to choose.

Furthermore, I'll repeat again, we're not choosing between H.264 and 
H.261. We're choosing between H.261 and no video, for only the 5-10% of 
calls where there is no agreement on a higher-end codec (VP8 or H.264).

> Finally, don't overestimate the typical upstream bandwidth that is 
> available to users across the Internet. Many of us here on this list 
> probably have nice speedy high speed connections (I have fiber with 
> 85/35 service) and that is not the norm for the rest of the world.

Again, this is up to the developers to choose. I don't necessarily need 
a high-resolution video for gaming.