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

Harald Alvestrand <harald@alvestrand.no> Mon, 23 March 2015 12:42 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 57FD81A8901 for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FbKFQv1Ghp8h for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:42:54 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5521A8913 for <video-codec@ietf.org>; Mon, 23 Mar 2015 05:42:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 06B4F7C432E for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:42:53 +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 TE2fSMSlndvH for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:42:52 +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 5E7747C4304 for <video-codec@ietf.org>; Mon, 23 Mar 2015 13:41:10 +0100 (CET)
Message-ID: <551009A9.1010108@alvestrand.no>
Date: Mon, 23 Mar 2015 13:40:09 +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/qmm-zhSBjYYCR7C-U0BpBmOA3oM>
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:42:57 -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?