[video-codec] Resource scaling Was: Comments on draft-maxwell-videocodec-requirements-00

Gregory Maxwell <gmaxwell@juniper.net> Wed, 05 December 2012 00:20 UTC

Return-Path: <gmaxwell@juniper.net>
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 0792521F8BCC for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 16:20:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
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 uAvzlDaiAFfp for <video-codec@ietfa.amsl.com>; Tue, 4 Dec 2012 16:20:53 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 089B921F8B99 for <video-codec@ietf.org>; Tue, 4 Dec 2012 16:20:52 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUL6TZFKl5JnZo8jUX7DofCcmL0WZugXB@postini.com; Tue, 04 Dec 2012 16:20:53 PST
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Dec 2012 16:11:33 -0800
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 4 Dec 2012 16:11:33 -0800
Received: from db3outboundpool.messaging.microsoft.com (213.199.154.141) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Dec 2012 16:14:03 -0800
Received: from mail120-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 00:11:31 +0000
Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id 2746F2403B7 for <video-codec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Wed, 5 Dec 2012 00:11:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -4
X-BigFish: PS-4(zz98dIzz1de0h1202h1d1ah1d2ahzz17326ah5eeeKz2dh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h)
Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1354666289950811_20536; Wed, 5 Dec 2012 00:11:29 +0000 (UTC)
Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.241]) by mail120-db3.bigfish.com (Postfix) with ESMTP id E5172120065; Wed, 5 Dec 2012 00:11:29 +0000 (UTC)
Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 00:11:29 +0000
Received: from CH1PRD0511MB432.namprd05.prod.outlook.com ([169.254.4.119]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0245.002; Wed, 5 Dec 2012 00:11:04 +0000
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Kevin Gross <kevin.gross@avanw.com>, John Koleszar <jkoleszar@gmail.com>
Thread-Topic: Resource scaling Was: Comments on draft-maxwell-videocodec-requirements-00
Thread-Index: AQHN0np+1SI2FgGK5UiofxkRREJdHA==
Date: Wed, 05 Dec 2012 00:11:03 +0000
Message-ID: <9B8EA46C78239244B5F7A07E163D3DFE05F96B8C@CH1PRD0511MB432.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [96.241.176.56]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%AVANW.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "video-codec@ietf.org" <video-codec@ietf.org>
Subject: [video-codec] Resource scaling Was: 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: Wed, 05 Dec 2012 00:20:54 -0000

Kevin Gross [kevin.gross@avanw.com] wrote:
> 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.

For high quality material resolutions and frame rates are growing— we're still a ways from being able to saturate human perception. But I can buy that networks are growing faster.  But I don't know that demands of video itself are the best comparison point there: We also want to do other things with that network bandwidth like service more concurrent users, or run other protocols, or extend it out to more remote regions. Some people want to broadcast every one of their meals (though I don't know why) and attach remote cameras to their dogs. So it's quite conceivable that demand for compression performance is going up even absent _any_ increase in video resolution.

So when talking about compression efficiency I think it's more useful to talk about how computation and coding science scales and compare that to how networks and storage scales.  We have a set of resources that can be applied and traded off to optimize how we handle video. Which of these things are more costly on average across all usage? 

During the BOF I made a remark along the lines that the available bandwidth at the edge of the network appears to be subject to a slower scaling law than what we see for low cost transistor density (Moore's law), or magnetic storage density (Kryder's Law). 

I didn't think it a very controversial supposition, as it's hard for the converse to be true on a sustained basis (switches ultimately become constrained by memory bandwidth)— but it's not one that I made without seeing some data on it in the past, e.g.

http://download.broadband.gov/plan/fcc-omnibus-broadband-initiative-%28obi%29-technical-paper-broadband-performance.pdf Page 4.

"Since 1997, consumer-purchased broadband connection speeds have doubled roughly every four years, with advertised fixed broadband download speeds growing at a 20% annual rate"

What I thought I'd seen before, but can't seem to find now is information on the _distribution_ of available speeds— as I think the highest access speeds tend to grow faster than the lower ones, which is an interesting factor for services which need to accommodate many potential users.

There are a number of other— mostly market related— arguments that can be made about the importance of compression efficiency, but I thought it would be productive to break this one out and see if I'm completely confused on this point.