Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00

"Timothy B. Terriberry" <tterribe@xiph.org> Tue, 04 December 2012 23:40 UTC

Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF5621F8BC4 for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXN9YYZMajvS for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 15:40:47 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D4DEF21F8AD3 for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:40:47 -0800 (PST)
Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D02B4F210B for <video-codec@ietf.org>; Tue, 4 Dec 2012 15:40:46 -0800 (PST)
Message-ID: <50BE89FE.1080207@xiph.org>
Date: Tue, 04 Dec 2012 15:40:46 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: video-codec@ietf.org
References: <CALw1_Q1QKteQpcOGtDg7j-MRZqL93TH1KNF8+i1OdyLvCc4kPQ@mail.gmail.com> <CAPzd0H5C-Dbyprar5KGfABJ=x64_KnCwjTJTnV=uwSMss+PAtg@mail.gmail.com> <CALw1_Q2xoJ9MSmYNh3ibhqFaFS17+7LkfJsP3s0nz+KfiiSYAQ@mail.gmail.com>
In-Reply-To: <CALw1_Q2xoJ9MSmYNh3ibhqFaFS17+7LkfJsP3s0nz+KfiiSYAQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 04 Dec 2012 23:40:51 -0000

Kevin Gross wrote:
> There are 8 applications listed in section 3. VOD is the only one that
> clearly benefits here. How much emphasis do we want to put on that
> application?

I've seen estimates that at peak hours this constitutes 50% of the 
Internet bandwidth usage of the United States [1]. That might be worth 
emphasizing.

> Why? The motivation for bandwidth efficiency is never convincingly
> substantiated in the draft. I'm aware that bandwidth efficiency is a
> very respected metric among codec developers. I'm questioning how
> important it actually is for applications and users given that available
> network bandwidth is increasing much faster than required media
> bandwidth and the efficiency increases we expect to be able
> to achieve with a new codec are comparatively modest.

The users seem to think it is pretty darn important. See, for example, 
Chris DiBona's claims that switching to Theora would break the internet 
[2] (rebutted [3], for the record, but the quality bar has moved beyond 
where it was in 2009, and will have moved farther before we're done).

I'll cite our experience with Opus as another example: it always had 
excellent latency and scalability, but people did not start to get 
really excited about it until the quality started to exceed that of the 
best high-latency codecs (this is not quite true: I gave a presentation 
on CELT, one of the predecessors of Opus, at LCA 2009, and after 
explaining that bitrate efficiency was explicitly a non-goal, had a 
number of excited people come up to me and ask, "How long until this 
compresses better than Vorbis?"). If you want people to use your codec, 
this matters.

We've tried twice now to get people to use codecs that were 
substantially less complex than their competitors but which did not 
resoundingly beat them in bitrate efficiency (to put it generously). It 
hasn't worked.

I'll also point out that HEVC's target was 50% less bitrate than H.264 
High Profile at > HD resolutions. I don't have numbers on how close they 
got off-hand, but I think most users would agree that that is not a 
modest number. If we don't at least match this performance, I'm not 
going to say we've failed, but we should _certainly_ be doing better 
than the RF options we already have.

[1] http://www.sandvine.com/news/pr_detail.asp?ID=312
[2] 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020380.html
[3] http://people.xiph.org/~greg/video/ytcompare/comparison.html