Re: [rtcweb] Proposed Video Selection Process

John Leslie <john@jlc.net> Fri, 22 November 2013 14:28 UTC

Return-Path: <john@jlc.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27F1AE0DB for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 06:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level:
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxIZhTfMf2cT for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 06:28:34 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B775E1ADFAA for <rtcweb@ietf.org>; Fri, 22 Nov 2013 06:28:34 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0900AC94C0; Fri, 22 Nov 2013 09:28:26 -0500 (EST)
Date: Fri, 22 Nov 2013 09:28:26 -0500
From: John Leslie <john@jlc.net>
To: Stefan Slivinski <sslivinski@lifesize.com>
Message-ID: <20131122142825.GB59496@verdi>
References: <7949EED078736C4881C92F656DC6F6C130EA8AD7ED@ausmsex00.austin.kmvtechnologies.com> <E62E1CAF-546D-4A0E-9339-D03D6C0BC1AE@apple.com> <528EBAB0.2010906@librevideo.org> <D125BF97-73BE-4591-8C70-30C03974CC78@apple.com> <528EBD4C.8070504@librevideo.org> <CAOJ7v-2zCZk4cMh1MbpXGHCELJMJppLVEX9CwPG3VNtDfDv4qw@mail.gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6618@ausmsex00.austin.kmvtechnologies.com>
User-Agent: Mutt/1.4.1i
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 14:28:39 -0000

Stefan Slivinski <sslivinski@lifesize.com> wrote:
> 
> So if you think of a really simple motion estimate engine where you
> search every possible location in the reference frame to find the
> best match using SAD as a block matching algorithm...guess what?
> There's a patent for that. If you then decide that if there isn'?t
> a really good match (high SAD), and you decide to do an intra search
> instead...guess what? There's a patent for that.

   Yes, we know -- software patents are big-time damage...

> I'm not trying to scare everyone but to argue that H.261 is somehow
> going to protect you from patent infringement is completely without
> merit.

   There's an important point here, which many folks _do_ seem to be
missing: you _can_ run afoul of perfectly "valid" patents implementing
20-year-old technology. It is not the job of the IETF to even warn you
about this; and it's _definitely_ not our job to say how you should
deal with it.

> My point here is we should be focusing on choosing the best technology

   No.

   We're absolutely not trying to find the "best technology". We all
agree that H.265 is better than H.264 and VP9 is better than VP8,
but we're not focusing on either of them. Likewise, we all agree
that H.263, while worse than either H.264 or VP8, is better than
H.261.

   We're trying to find a "good enough" technology to be Mandatory
To Implement. We've been trying for a long time; and we may end up
failing.

   H.261 holds real promise there -- you can find an _implementation_
that's more than 20 years old and copy it bit-for-bit, and have a
rock-solid "prior art" defense. (We're not saying that's what you
should do; but it's an option available to you.)

> and come up with a solution for dealing with patent trolls at some
> other level because it's going to be a wide spread concern, not just
> a video problem.

   That's not a problem for _us_ to solve -- nor is it entirely
rational to believe we will ever see it solved. I certainly agree
the problem is quite widespread; but different companies will choose
different paths to manage the risks. (As they should!)

--
John Leslie <john@jlc.net>