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

Kevin Gross <kevin.gross@avanw.com> Wed, 05 December 2012 11:40 UTC

Return-Path: <kevin.gross@avanw.com>
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 9276721F8908 for <video-codec@ietfa.amsl.com>; Wed, 5 Dec 2012 03:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.976
X-Spam-Level:
X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666]
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 IIFyJ-GgflBy for <video-codec@ietfa.amsl.com>; Wed, 5 Dec 2012 03:40:44 -0800 (PST)
Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 9B2B321F8716 for <video-codec@ietf.org>; Wed, 5 Dec 2012 03:40:43 -0800 (PST)
Received: (qmail 20153 invoked by uid 0); 5 Dec 2012 03:51:00 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 5 Dec 2012 03:51:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=2le3JLR2lXIksEw+tT+dXlsqb8ZVIi3RIsT8ID4Vr0c=; b=VnFlAk3M2MWqzLf+090AiW/U+7MqJ09H+Q+a1f5G9YDA6O+aAqrBQ4FTEIlt0tLeGoLB9vR+8ZDQ611wqmHZXyTp/Xo8wA81fJdYtuWzHLSSub2dGPIeM+/DEc2c5YQ7;
Received: from [209.85.210.172] (port=45054 helo=mail-ia0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1Tg60h-00030Q-TD for video-codec@ietf.org; Tue, 04 Dec 2012 20:51:00 -0700
Received: by mail-ia0-f172.google.com with SMTP id z13so3860520iaz.31 for <video-codec@ietf.org>; Tue, 04 Dec 2012 19:50:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.140.67 with SMTP id re3mr581767igb.16.1354679457917; Tue, 04 Dec 2012 19:50:57 -0800 (PST)
Received: by 10.50.151.135 with HTTP; Tue, 4 Dec 2012 19:50:57 -0800 (PST)
In-Reply-To: <50BE89FE.1080207@xiph.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> <50BE89FE.1080207@xiph.org>
Date: Tue, 04 Dec 2012 20:50:57 -0700
Message-ID: <CALw1_Q2NrLizB-pgKUVtZiPF4AC0QzAC6EQA2t5yNmSZxQUEPQ@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Content-Type: multipart/alternative; boundary="e89a8f838b95dfac4004d012e366"
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.172 authed with kevin.gross@avanw.com}
Cc: video-codec@ietf.org
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: Wed, 05 Dec 2012 11:40:47 -0000

Good stuff. Thanks for including the DiBona rebuttal - good points made
there, but, like you say, you have significant experience that indicates
the less optimized approach is not successful in the "market". We should
not ignore that.

We do need to decide how important VOD is. I'm not sure that wasn't ironic
understatement in your response. My understanding is that a significant
driver for this codec effort is RTCweb and there's not much VOD there.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Tue, Dec 4, 2012 at 4:40 PM, Timothy B. Terriberry <tterribe@xiph.org>wrote:

> 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<http://www.sandvine.com/news/pr_detail.asp?ID=312>
> [2] http://lists.whatwg.org/htdig.**cgi/whatwg-whatwg.org/2009-**
> June/020380.html<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020380.html>
> [3] http://people.xiph.org/~greg/**video/ytcompare/comparison.**html<http://people.xiph.org/~greg/video/ytcompare/comparison.html>
>
> ______________________________**_________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/**listinfo/video-codec<https://www.ietf.org/mailman/listinfo/video-codec>
>