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

"Mo Zanaty (mzanaty)" <> Mon, 23 March 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B90101A8BC0 for <>; Mon, 23 Mar 2015 07:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O2Ydk0y3ihAK for <>; Mon, 23 Mar 2015 07:55:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 542FE1A8BAF for <>; Mon, 23 Mar 2015 07:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1376; q=dns/txt; s=iport; t=1427122546; x=1428332146; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vZXsL/7930ED6m+2AeMvsWHJ2XVBBQJPk5IroAC/Bq8=; b=Xp1DYfMOGkgvb4C9+3nTk/3mKab190y2yrBKcwOb1SwTVuiSxGflitom 1WdNiJIeU76mgFcxPSIxEQNpsAN57Mn4CKAHQxMy2Jwn+Ky5OW2gNfGcU xjThMYlSPaE+S243zMGyV+pg46TDabGs2A+TIY1VJdZ0I9myOQOQi16Gj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,452,1422921600"; d="scan'208";a="134587742"
Received: from ([]) by with ESMTP; 23 Mar 2015 14:55:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t2NEtjcT016784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 14:55:45 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 09:55:45 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Harald Alvestrand <>, "" <>
Thread-Topic: [video-codec] Performances, measurement of same (Re: The Can Has Landed)
Thread-Index: AQHQZXlwNdqDcNEL0E6Z9vBFpmqNQw==
Date: Mon, 23 Mar 2015 14:55:44 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [video-codec] Performances, measurement of same (Re: The Can Has Landed)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Video codec BoF discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2015 14:55:47 -0000

Complexity (or more broadly, resource requirements, which encompass
aspects beyond compute cycles like memory and memory bandwidth) should be
a fundamental part of the evaluation methodology. But there are many
pitfalls to avoid here.

Intrinsic algorithmic complexity is difficult to discern with any
precision, since any metric necessarily depends on the level of
implementation optimization (from simple loop unrolling to vector
intrinsics or full assembly).

Optimization can hamper experimentation, so it is usually not a good idea
in the research stage.

Configuration points are also important to consider. Having configuration
points that are impractical for real-world use is still valuable for
steering the research. This should not be the primary evaluation criteria,
which should attempt to focus on real-world use. But such configuration
points should be allowed and analyzed.


On 3/23/15, 8:40 AM, Harald Alvestrand <> wrote:
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?