Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <sslivinski@lifesize.com> Fri, 22 November 2013 16:52 UTC

Return-Path: <sslivinski@lifesize.com>
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 67A1F1AE3A5 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 08:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 KNy49N_uXotH for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 08:52:35 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 4BF381AE39B for <rtcweb@ietf.org>; Fri, 22 Nov 2013 08:52:35 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo+Lxi1BECxttIFYaLJeQtlmi7vz6U2H@postini.com; Fri, 22 Nov 2013 08:52:28 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 10:47:35 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: John Leslie <john@jlc.net>
Date: Fri, 22 Nov 2013 10:47:33 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7njx5J16lJ9RueT6OPd4nzhYEJ4QADjCaQ
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E66A6@ausmsex00.austin.kmvtechnologies.com>
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> <20131122142825.GB59496@verdi>
In-Reply-To: <20131122142825.GB59496@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 16:52:37 -0000

The best technology is not simply which codec has the greatest compression efficiency, it is a function of complexity, performance, cost, error resiliency and many more.  

Today there exists no hardware acceleration for H.265 which means you will be hard pressed to do 720p30 encode on a high end laptop, something that even a low end, 3 year old intel can do without breaking a sweat.  On portable platforms like tablets and smartphones doing the encoder is software is going to make it impossible to do larger resolutions and it's going to kill the battery.  All of these have to be factors in deciding what is the best technology.

-----Original Message-----
From: John Leslie [mailto:john@jlc.net] 
Sent: Friday, November 22, 2013 6:28 AM
To: Stefan Slivinski
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed Video Selection Process

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>;