[video-codec] Performances, measurement of same (Re: The Can Has Landed)

Harald Alvestrand <harald@alvestrand.no> Mon, 23 March 2015 12:49 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519841A89AC for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eij8-TGNs4Vr for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:49:27 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 599801A8928 for <video-codec@ietf.org>; Mon, 23 Mar 2015 05:49:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 409757C432E for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:49:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-8Nb4XhwZi0 for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:49:25 +0100 (CET)
Received: from [IPv6:2001:67c:370:136:a856:ac35:952d:b940] (unknown [IPv6:2001:67c:370:136:a856:ac35:952d:b940]) by mork.alvestrand.no (Postfix) with ESMTPSA id D07A37C4304 for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:49:22 +0100 (CET)
Message-ID: <55100BD0.8030301@alvestrand.no>
Date: Mon, 23 Mar 2015 13:49:20 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CACrD=+_D+psUeWevMuwp0bnxqdcJpo3Zo3Og4E6kkGH1uuzxdA@mail.gmail.com> <CAMzhQmNymkEMgbw-gUGhKEgCYh1yXo8MRkP-8FNfQm8tVNhzbA@mail.gmail.com> <550B6CCC.70706@mozilla.com>
In-Reply-To: <550B6CCC.70706@mozilla.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/YnRmRBLVbvnGSKfDY-iN-6Yzu7k>
Subject: [video-codec] Performances, measurement of same (Re: The Can Has Landed)
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 12:49:29 -0000

On 03/20/2015 01:41 AM, Thomas Daede wrote:
> On 03/19/2015 05:17 PM, Keith Winstein wrote:
>> But what are the merits of an IETF working group performing this kind of
>> high-risk, high-reward research, versus doing something much more boring
>> like "writing a specification for VP9 to enable interoperable
>> implementations, and then iterating on that technology"?
> If VP9 could be shown to meet our requirements for performance and
> licensing, I would be supportive of that path. However, I don't believe
> that it currently does.
>
> In the testing draft, while I specified methods of testing codecs, I did
> not specify an absolute performance goal. We will need to set one. Opus
> achieved state-of-the-art performance, which was highly beneficial to
> its adoption. VP9 does not achieve this yet.

Just as a matter of curiosity, which state of the art performance is it
that you think VP9 hasn't achieved yet?

I also wonder a bit about how we should treat evaluation of performance
- a traditional video codec development technique has been to develop a
codec that takes hours-per-second to encode a video, and then seek to
optimize it by a factor of a hundred before shipping it. But sometimes,
there's just limits to how much one can achieve.

How should we treat that aspect in evaluation?