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

Harald Alvestrand <harald@alvestrand.no> Mon, 23 March 2015 14:10 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 4BA611A8ACF for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 07:10:04 -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 KteOpDdsUMZc for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 07:10:02 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id CB5A91A8ABC for <video-codec@ietf.org>; Mon, 23 Mar 2015 07:10:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1A2837C4337; Mon, 23 Mar 2015 15:10:01 +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 eqwA_deCtmTV; Mon, 23 Mar 2015 15:09:59 +0100 (CET)
Received: from [IPv6:2001:67c:370:176:a856:ac35:952d:b940] (unknown [IPv6:2001:67c:370:176:a856:ac35:952d:b940]) by mork.alvestrand.no (Postfix) with ESMTPSA id 085397C4330; Mon, 23 Mar 2015 15:09:58 +0100 (CET)
Message-ID: <55101EB4.8020809@alvestrand.no>
Date: Mon, 23 Mar 2015 15:09:56 +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: Mohammed Raad <mohammedsraad@raadtech.com>
References: <CACrD=+_D+psUeWevMuwp0bnxqdcJpo3Zo3Og4E6kkGH1uuzxdA@mail.gmail.com> <CAMzhQmNymkEMgbw-gUGhKEgCYh1yXo8MRkP-8FNfQm8tVNhzbA@mail.gmail.com> <550B6CCC.70706@mozilla.com> <551009A9.1010108@alvestrand.no> <CA+E6M0nh5AAqE4v0DM46tFXRGy5sMh+1Lphu+J5RC_PcRudTaw@mail.gmail.com>
In-Reply-To: <CA+E6M0nh5AAqE4v0DM46tFXRGy5sMh+1Lphu+J5RC_PcRudTaw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/vb6w3402l1ZnE4j9Wgl8-mlbeuE>
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: Re: [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 14:10:04 -0000

On 03/23/2015 01:52 PM, Mohammed Raad wrote:
> Well, the second part (how one should judge the potential
> optimization) typically has been avoided in video standardization and
> so far there seems to be little willingness to work on the development
> of a metric or a set of metrics that can be used to determine how
> "optimizable" a codec or tool is. It would actually be good if people
> at the IETF can develop such a metric.

I was thinking more of whether experience with the encoding speed of the
test implementations should be allowed as an argument or not.

Sometimes one can use dataflow analysis and similar tools to show that
certain techniques prevent optimization beyond a certain level (or not)
- but most of the time, I think "this runs at speed x / quality y" is a
more compelling argument than "I think this could be optimized to speed
x / quality y".

>
> Also, keep in mind that the incremental development of a codec means
> that prior decisions limit what can be done with tools proposed later
> in the process.

Yes. Especially when the decision is "we can't use this tool for
nontechnical reasons", it means that we can't accept anything that is a
refinement of this tool either.