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

cowwoc <> Thu, 14 November 2013 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DEB721E8087 for <>; Wed, 13 Nov 2013 23:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.146
X-Spam-Status: No, score=-4.146 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wX1MTym5pBFE for <>; Wed, 13 Nov 2013 23:01:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1C91221E80FA for <>; Wed, 13 Nov 2013 23:01:07 -0800 (PST)
Received: by with SMTP id u16so2217564iet.10 for <>; Wed, 13 Nov 2013 23:01:07 -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 :cc:subject:references:in-reply-to:content-type; bh=wN0Z5AummLtgBx8/TgdkT5c346JtdoEo3ZePMln+N1Q=; b=Tv//9oEEnR0rYqwh2fQz9h2K+zSLBsCuPxanD3FiHU64cpEUhnPJxvLq6s/Oh0uX42 0U0Lo+HZKsNAJ+ua5BGnxdsZTa5zMMVuRAZ956VmO4OCSGUA+5CjuT3lCD+abr/jx74h KusOBKdWBu1omm4eoZWkLxh91aL0SLuvVtynod7sc4YM4iYE7yLY9+G8LRNqLjkvukz2 qoNcOCFYMXnIC0YAHfSyWwvXDzVsDYcUBMjw1UMV5AXm78+MX4IiUNnJYA7rA9Q6B+CD yrr76mI59pEZKgcZE7c+bCsyKL+wd5K6Jj3mc+zwIQVp4j8/2LPrybfMUf7wWu7g5P47 azcg==
X-Gm-Message-State: ALoCoQks6JzXstGn9IO3J1+rkmgFGjMK6X0qlaKcESUbY0OkPfAxcE1EgIpH3P5C38f9/DpEiSYU
X-Received: by with SMTP id g8mr543057igc.30.1384412467503; Wed, 13 Nov 2013 23:01:07 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id p5sm2666706igj.10.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 23:01:06 -0800 (PST)
Message-ID: <>
Date: Thu, 14 Nov 2013 02:00:49 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Justin Uberti <>
References: <> <20131113165526.GA13468@verdi> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090608040902020604020304"
Cc: "" <>
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 07:01:13 -0000

On 14/11/2013 1:07 AM, Justin Uberti wrote:
> On Wed, Nov 13, 2013 at 9:22 PM, cowwoc < 
> <>> wrote:
>     On 13/11/2013 8:43 PM, Justin Uberti wrote:
>         Regarding H.261: Consider the following clip, encoded at 256
>         kbps using H.261.
>         Do you think this quality (QCIF, grayscale, PSNR of 38) is
>         acceptable for your users?
>     That is hardly a scientific comparison.
>     And again, it is misleading to imply that I am advocating the
>     mass-use of H.261. I am only advocating the use of this codec in
>     the 5-10% of cases where the clients fail to agree on a common
>     upgrade path (to VP8 or H.264). In those cases, I'd happily accept
>     H.261 instead of dropping the call. You can still transcode, if
>     you so wish.
> It is a single example, but I think it illustrates the limits on what 
> you can achieve with a 25-year-old (really!) coding technology. The 
> page at claims that the 
> compression ratio for the above file is 25:1, with PSNR of 38. Modern 
> codecs achieve compression ratios of at least 150:1 for similar PSNR 
> with a similar talking head scene, i.e. H.261 requires at least 6x the 
> bits for the same quality.
> Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 
> is a realistic option, I think you need to show data that indicates it 
> can deliver decent quality at typical internet bitrates.

Okay, that's reasonable, though my point remains: how do we want to 
handle the 5-10% of cases where the clients can't agree on a common 
codec? For some businesses, it might very well be preferable to fallback 
to a lower-resolution H.261 feed than to drop the call or use 
transcoding. I don't believe we should make this decision on behalf of 
the client.

Is it fair to assume that a H.261 feed using the same bandwidth as VP8 
would stream roughly 6x less pixels? So say 720p would drop down to 
funky resolution of 404x303? This is definitely not great, but it's 
certainly useable depending on your use-case. Anyway, my argument is 
that this decision is best left up to the developer. There plenty of 
cases (gaming comes to mind) where using H.261 would be "good enough" 
and preferable to dropping the call or transcoding.