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

Kaiduan Xie <> Wed, 13 November 2013 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BDC111E810A for <>; Wed, 13 Nov 2013 13:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1pDTK4+4Mg2E for <>; Wed, 13 Nov 2013 13:57:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::232]) by (Postfix) with ESMTP id EF41E21E80E3 for <>; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by with SMTP id u57so570402wes.23 for <>; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2AF5F5BptXfcgUqHSElxF81ZCSGqD8FY/2pSXHS5MQ8=; b=tr/BrIMO6SVt4w3iz276Eal4cwqrxU6SLiPaxNAUbh/rwJi70pFmsUXHk/tv84D6at TznuBI6E1L7XcIOlQoWjWG3iobLSIhChH8f0LowhxNxbjIh3gOZfcYr/o1sIvFzp3x82 4wV9cAtAgvQtukRrOZwxDpTtVJ+oOxZfiZajAoKdUyPS+gllS9dtomgaa4L14RBvkz1k utGmVKM/K9l+KDybHh+WvCVAc3o6ybzPAJ/Dl8Td7jvKjHB2uwhNT/bDHZr6y8QY/4Ps oM2TYZLslxFyvFDNLQIS8WnxC4G6EgnmGhUSkshe9DGHRkSdq8e417Zlm2YhgqMq2fNE BL4A==
MIME-Version: 1.0
X-Received: by with SMTP id ld5mr2044525wjc.67.1384379834236; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
Received: by with HTTP; Wed, 13 Nov 2013 13:57:14 -0800 (PST)
In-Reply-To: <>
References: <> <20131113165526.GA13468@verdi> <>
Date: Wed, 13 Nov 2013 16:57:14 -0500
Message-ID: <>
From: Kaiduan Xie <>
To: cowwoc <>
Content-Type: multipart/alternative; boundary=047d7bb70c5841050304eb160ca9
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: Wed, 13 Nov 2013 21:57:17 -0000

"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you
still have to pay a lot of money.


On Wed, Nov 13, 2013 at 3:54 PM, cowwoc <> wrote:

> Hi John,
> First, thanks for summarize the positions brought up in the meeting.
> A few weeks ago I advocated making both H.264 and VP8 MTI with the
> reasoning that if an implementer gets sued they can simply drop the codec,
> notify the community, and have that codec removed en-mass from the
> specification. A few months later we would replace it with another MTI
> codec. According to what you wrote above, Cisco is under the impression
> that once a codec is MTI they cannot drop it even if they get sued.
> Practically speaking, is that really true? I mean, if the specification
> requires everyone to implement both VP8 and H.264 and one implementer
> temporarily drops one of the codecs, shouldn't things keep on working until
> the lawsuit is over (codec returns) or the community replaces the codec
> with another?
> Thanks,
> Gili
> On 13/11/2013 11:55 AM, John Leslie wrote:
>> Mike Linksvayer <> wrote:
>>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>>> of both, either, or neither would be second best.
>>     I'm _very_ glad you care which is "second best!"
>>     I went into last week's session quite prepared to accept either, both
>> or neither. I came out unwilling to support _either_ as MTI.
>>     This is mostly because I came to understand the "cisco" postition.
>>     (Please excuse me for assigning names to the two main positions, but
>> it will make the discussion _much_ simpler.)
>>     The "cisco" position is:
>> - look at all the H.264 hardware out there: we must make use of it;
>> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>>     The "linux" position is:
>> - look at all the VP8 software out there: we must make use of it;
>> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>>     And, alas, they're both right.
>>     What I didn't understand before the presentations was why Cisco
>> believes they'll get sued over VP8, but not H.264.
>>     Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
>>     But this consortium won't lift a finger if Nokia sues Cisco over
>> VP8. Cisco is a _very_ attractive target over VP8.
>>     Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
>> MTI. They probably won't implement it.
>>     Conversely, of course, "linux" management would _very_much_ prefer
>> that H.264 not be MTI. They probably won't implement it.
>>     Understanding this, I now strongly recommend against making either
>> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
>> to choosing between them.)
>>     This issue has dragged on long enough already. We need to start
>> reading the riot act to the folks who claim we "need" either of these
>> as MTI in order to have "satisfied" users.
>>     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...)
>> --
>> John Leslie <>
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list