Re: [rtcweb] Proposed Video Selection Process

Basil Mohamed Gohar <> Thu, 21 November 2013 22:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D74661AE2D8 for <>; Thu, 21 Nov 2013 14:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KonRROSMDXnx for <>; Thu, 21 Nov 2013 14:12:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D75161AE2A8 for <>; Thu, 21 Nov 2013 14:12:40 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id B4A9565989C for <>; Thu, 21 Nov 2013 17:12:33 -0500 (EST)
Message-ID: <>
Date: Thu, 21 Nov 2013 17:12:31 -0500
From: Basil Mohamed Gohar <>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <20131121204147.GV3245@audi.shelbyville.oz> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposed Video Selection Process
X-Mailman-Version: 2.1.15
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, 21 Nov 2013 22:12:43 -0000

On 11/21/2013 04:59 PM, Eric Rescorla wrote:
> On Thu, Nov 21, 2013 at 1:54 PM, Basil Mohamed Gohar
> < <>> wrote:
>     On 11/21/2013 04:14 PM, Eric Rescorla wrote:
>     > Agreed.
>     >
>     > To take a not-so-random example, given that Firefox will soon
>     > support both H.264 and VP8, what additional implementations
>     > will it be able to talk to if it does H.261?
>     >
>     > -Ekr
>     (I apparently replied only to Ekr, and not the whole list originally)
>     None, but that's not the point.  Firefox is a special case for which VP8
>     is not considered a legal liability (by Mozilla) and they can be
>     satisfied, for the most part, by Cisco's proposal with OpenH264 as a
>     downloadable plugin/module.
>     So, this doesn't open up anything for Firefox that it is not already
>     planning to handle.
>     What it does open up is for, say, a small firm that cannot afford H.264
>     licensing, and cannot make use of Cisco's binary plugin for legal or
>     technical reasons, and can only implement VP8 and H.261, and, say, a
>     device whose manufacturers do not wish to implement VP8 for perceived
>     IPR risk but already license H.264.
>     Both cases above have an H.261 implementation that will allow mutual
>     video, even though they do not share a common high-end codec
>     implementation.
>     There are cases outside of browsers that are interested in rtcweb, after
>     all.
> Which of those cases are going to want to not talk to browsers?
> Which browsers want to do H.261?
> -Ekr

Of course, all of them want to talk to browsers.  But not all of them
will be guaranteed to implement BOTH VP8 or H.264 (nor are browsers, and
this is key).

So, I write myself a small little device that attaches to my camera that
implements RTCweb.  I cannot afford the license for H.264, and my
platform is not supported by OpenH264.  I do, however, write-up my own
basic VP8 implementation as well, because it is is royalty-free.  I also
implement H.261 for the same reason, it's royalty free.  I need things
to be royalty free because I plan to publish my designs under a CC
license and want others to also be able to make my device.

So, I can talk to browsers that support VP8 with VP8, and browsers that
do not support VP8, but because it's MTI, do support H.261, but with
degraded quality.  BUT I CAN STILL TALK (or SEE) them, as opposed to
being unable to if H.261 was not mandated.

This example, though perhaps somewhat contrived, is a case that would be
allowed if H.261 is permitted, and would be impossible if it were left
out, because there would be some rtcweb endpoints excluded from

Libre Video