Re: Daughter of CODEC (was Re: Alternative decision process in RTCWeb)

Phillip Hallam-Baker <hallam@gmail.com> Mon, 02 December 2013 18:32 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E21AD937 for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 10:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FxevAv2mvO5m for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 10:32:45 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 981F41AD8ED for <ietf@ietf.org>; Mon, 2 Dec 2013 10:32:44 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so9612465wgh.34 for <ietf@ietf.org>; Mon, 02 Dec 2013 10:32:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QwpwsXvEuQ63e2CmbaIjwSJfCcXN14f+ckX2Hu4YBSw=; b=yVjjwUliR/SbtV8oPzLeOHE51mmJO3soKNKTfh/pe37t7d1vkKTpf3RN5COCeUd62J 0/jsHP1lbP7t1HF3KUY7IdJdu5BG/Gr7h+BpN91Oo3nuAfTg1m0QPPBgGb2A3O92X24L yhcSTjAIV14uf3CrqHr2IuhHV5+xsftCtjdoEDuELiGHP1Lj/6EQi1rjPwtO8ZVXFMRh G+hy2d1d3I8nlt4y56dJjQyBmCZ6u0+ZPv5dlmywRxYiNnu2NdkMakXhZ/8DmleGC5xM t4oIE5cZ/kKolEE96q6RvxLab9/4E4/AAf7h2IPjNP0cuZxamysAnybAtoCoY3za6CNa WGRg==
MIME-Version: 1.0
X-Received: by 10.180.210.232 with SMTP id mx8mr19672122wic.34.1386009161598; Mon, 02 Dec 2013 10:32:41 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 10:32:41 -0800 (PST)
In-Reply-To: <CABmDk8kxED6bvrGoHCcsXCEhpa3-qQL_ZQO8xmUBV1Kt96ELjA@mail.gmail.com>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <CAKFn1SHMBG=Rwq8SNJkPz6EUD9O9P+0gTD569_5eXc7ndBpYRQ@mail.gmail.com> <529A0A4A.1040107@gmail.com> <CA+9kkMB44JYj-hkp_O72f2yg-OtBuyqN=NC3aW2PBvh7ZO-kBw@mail.gmail.com> <529BC7B1.8070205@gmail.com> <CA+9kkMBJ7mktXepDckaOTBcP3wZ4e-MM7cmu_=RFJymKNr5xuA@mail.gmail.com> <12721589-7B67-49C9-99E5-CBE96BE45F11@standardstrack.com> <CABmDk8kxED6bvrGoHCcsXCEhpa3-qQL_ZQO8xmUBV1Kt96ELjA@mail.gmail.com>
Date: Mon, 02 Dec 2013 13:32:41 -0500
Message-ID: <CAMm+LwgYEtBRRuEs-squNyM6qqE2mi1pDd5ZQXh-okg5UGnV3A@mail.gmail.com>
Subject: Re: Daughter of CODEC (was Re: Alternative decision process in RTCWeb)
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Mary Barnes <mary.h.barnes@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c3337abb900704ec91670f"
Cc: IETF <ietf@ietf.org>, Eric Burger <eburger@standardstrack.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 18:32:47 -0000

On Mon, Dec 2, 2013 at 12:15 PM, Mary Barnes <mary.h.barnes@gmail.com>wrote:

> We had a videocodec bof  @IETF-85 and the WG just never got chartered:
> http://trac.tools.ietf.org/bof/trac/wiki/BofIETF85.   Perhaps the ADs can
> fill in the gap as to why that didn't happen as I'm not sure whether a ball
> was dropped or there was a reason not to charter.
>
> Regards,
> Mary.
>

How long is such a group likely to take and would it be developing a new
CODEC or selecting from existing unencumbered choices?

Is there an expectation that such a group would produce a CODEC better than
MPEG2 or report substantially earlier than the expiry of the last patents
in the MPEG2 pool (expected to be ~2017)?

Half the MPEG2 patents have expired already and it is possible that a
subset of the MPEG2 CODEC could be defined that avoided IPR encumbrances.
But it is hard to see such a CODEC gaining significant ground in the next 4
years.

MPEG2 is not as efficient as H.264 and it does not support all the same
modes. But it is almost certainly good enough for MTI.


The best approach to this problem looks to me to be to do what we did with
the Diffie Hellman and RSA patents and wait for them to expire. We did
start pushing DH and El Gamal based schemes between 1997 and 2000 when
those were out of patent but RSA was still covered. Doing the same with
H.264 makes sense.

The long tail patents on H.264 is very long, there is at least one in the
pool that does not expire till 2027


-- 
Website: http://hallambaker.com/