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

Mohammed Raad <mohammedsraad@raadtech.com> Mon, 23 March 2015 12:52 UTC

Return-Path: <mohammedsraad@raadtech.com>
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 19A901A892A for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 GazxGZxcHrtD for <video-codec@ietfa.amsl.com>; Mon, 23 Mar 2015 05:52:32 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC01F1A891A for <video-codec@ietf.org>; Mon, 23 Mar 2015 05:52:31 -0700 (PDT)
Received: by wgra20 with SMTP id a20so145098440wgr.3 for <video-codec@ietf.org>; Mon, 23 Mar 2015 05:52:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O2MjCLLgv/sGkJ9QCVrPM3J/vnX6ERXdI38o3zkutUk=; b=hzOYg53V7v90GgbJayPIMH0jHNKFvz/Wrr0QTAFs/qvgMaEOpZJ6K9WSnsDmvnbv0g WPpnLZBwCgc7+3mnwoT/0PIMfpNIQQLxnUUs8dzRdyo3+8uQwRdU02KZjBVofM7gJ1AN Bt2KLux6DpiDY9mPYpuHDPC6rpX1ECB21Mgqu5GmkG5UphG0ePuBKQ93llZOq2UCad1o AzRTbIWW+Os7P8CmflvmHKc10SEYKGrF5ZwDn9V725K6Y4wNpOfgF737ZInMF+JthY2W aGSlyc/xKNRZUgAXWqihbfDhcigwInvg++AZ3SK0z5d5d1cqv74ToFUqgxUAeljj+Ou3 A1SQ==
X-Gm-Message-State: ALoCoQlvEWh+9VCYLdb6daIXKyZru/KKVVx2Vi7vqpjU37VlM3aqIflvkeXuG7dOtzf2oZ0d77Vd
MIME-Version: 1.0
X-Received: by 10.194.61.12 with SMTP id l12mr184135017wjr.139.1427115150320; Mon, 23 Mar 2015 05:52:30 -0700 (PDT)
Received: by 10.194.14.129 with HTTP; Mon, 23 Mar 2015 05:52:30 -0700 (PDT)
In-Reply-To: <551009A9.1010108@alvestrand.no>
References: <CACrD=+_D+psUeWevMuwp0bnxqdcJpo3Zo3Og4E6kkGH1uuzxdA@mail.gmail.com> <CAMzhQmNymkEMgbw-gUGhKEgCYh1yXo8MRkP-8FNfQm8tVNhzbA@mail.gmail.com> <550B6CCC.70706@mozilla.com> <551009A9.1010108@alvestrand.no>
Date: Mon, 23 Mar 2015 14:52:30 +0200
Message-ID: <CA+E6M0nh5AAqE4v0DM46tFXRGy5sMh+1Lphu+J5RC_PcRudTaw@mail.gmail.com>
From: Mohammed Raad <mohammedsraad@raadtech.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="047d7b86df3896bddd0511f42308"
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/hI6h2loHMPlDxo3EyL0JBuAQcrw>
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 12:52:34 -0000

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.

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.

Mohammed

On Mon, Mar 23, 2015 at 2:40 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> 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?
>
>
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
>



-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: mohammedsraad@raadtech.com