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

Tim Panton <> Thu, 14 November 2013 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4A9911E817B for <>; Thu, 14 Nov 2013 00:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0D0aDLFvFgjP for <>; Thu, 14 Nov 2013 00:50:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D681611E8172 for <>; Thu, 14 Nov 2013 00:50:00 -0800 (PST)
Received: (qmail 57307 invoked from network); 14 Nov 2013 08:49:52 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 1200
Received: from unknown (HELO ( by with SMTP; 14 Nov 2013 08:49:52 -0000
Received: from (localhost []) by (Postfix) with ESMTP id F288A18A0411; Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTPSA id 6503918A0379; Thu, 14 Nov 2013 08:49:51 +0000 (GMT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_77DAE0E4-47E1-445F-BA27-9AFF21C19133"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Tim Panton <>
In-Reply-To: <20131113165526.GA13468@verdi>
Date: Thu, 14 Nov 2013 08:49:10 +0000
Message-Id: <>
References: <> <20131113165526.GA13468@verdi>
X-Mailer: Apple Mail (2.1816)
Cc: Neil Stratford <>
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 08:50:07 -0000

On 13 Nov 2013, at 16:55, John Leslie <> wrote:

>  Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>   And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>   I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
>   (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)

I'm coming around to this POV. With the possible slight variant that we should clarify
that this applies to _browsers_ not rtcweb compatible endpoints.

Ideally we'd see browsers implementing both VP8 and H264 - but single purpose 
endpoints (doorbells, prison video phones, baby alarms, smart-fashion mirrors, video mixers etc) using whichever
codec suits their hardware/legal/usecase needs best, and exchanging rtcweb media with
a browser at the far end. 

Non browser endpoints need to be confident they can talk to any browser and browsers need to
be able to talk to anything.

I think that's what is behind the option #4 in Gonzalo's proposal. 
>  4. Browsers MUST support both H.264 and VP8

- What this highlights is that we've created a media protocol that will be used by things that aren't browsers,
we need to address that requirement, without just seeing it as legacy support.


Tip of the Hat to @nstratford for helping clarify my thinking on this.