Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00
Kevin Gross <kevin.gross@avanw.com> Wed, 14 November 2012 16:41 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 7E73421F85A2 for <video-codec@ietfa.amsl.com>; Wed, 14 Nov 2012 08:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.036
X-Spam-Level:
X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 FFor0EqYM73P for <video-codec@ietfa.amsl.com>; Wed, 14 Nov 2012 08:41:33 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (unknown [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 4E98221F8554 for <video-codec@ietf.org>; Wed, 14 Nov 2012 08:41:33 -0800 (PST)
Received: (qmail 20719 invoked by uid 0); 14 Nov 2012 16:41:12 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy12.bluehost.com with SMTP; 14 Nov 2012 16:41:12 -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=vvXxWzgRoZHR8LtuLEmIw8gdHC1gfHXOy0cqq3nDG34=; b=Fj0Bn5BZoSUDMS4BFkrM1KJcSvM7MXhIh3MBvYRWXYtYApore0pxFELGJnADkEdth68mLxwgNZLrzVbWuARDboZ5GHaqTgqwTMUi3vysJJ9fuOzuUBGJeyLQLbHjcO3D;
Received: from [74.125.83.44] (port=59839 helo=mail-ee0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <kevin.gross@avanw.com>) id 1TYg1X-0000EA-La for video-codec@ietf.org; Wed, 14 Nov 2012 09:41:11 -0700
Received: by mail-ee0-f44.google.com with SMTP id b47so449614eek.31 for <video-codec@ietf.org>; Wed, 14 Nov 2012 08:41:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.14.216.193 with SMTP id g41mr88917339eep.37.1352911270155; Wed, 14 Nov 2012 08:41:10 -0800 (PST)
Received: by 10.223.152.201 with HTTP; Wed, 14 Nov 2012 08:41:10 -0800 (PST)
In-Reply-To: <CAPzd0H5C-Dbyprar5KGfABJ=x64_KnCwjTJTnV=uwSMss+PAtg@mail.gmail.com>
References: <CALw1_Q1QKteQpcOGtDg7j-MRZqL93TH1KNF8+i1OdyLvCc4kPQ@mail.gmail.com> <CAPzd0H5C-Dbyprar5KGfABJ=x64_KnCwjTJTnV=uwSMss+PAtg@mail.gmail.com>
Date: Wed, 14 Nov 2012 09:41:10 -0700
Message-ID: <CALw1_Q2xoJ9MSmYNh3ibhqFaFS17+7LkfJsP3s0nz+KfiiSYAQ@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: John Koleszar <jkoleszar@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b622072ab969b04ce7733ba"
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.83.44 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, 14 Nov 2012 16:41:34 -0000
Comments below. On Tue, Nov 13, 2012 at 11:17 PM, John Koleszar <jkoleszar@gmail.com> wrote: > On Tue, Nov 13, 2012 at 5:37 PM, Kevin Gross <kevin.gross@avanw.com> > wrote: > [...] > > Section 4, third paragraph: > > > > Here's an opportunity to focus the project. Instead of trying to > accommodate > > lossy and lossless networks, why not concentrate on the lossy networks > the > > IETF is most familiar with? > > > > Lossless networks are the highest-performance networks and conserving > > bandwidth on these is not likely a priority. > > > > I read this to mean whether the layer 4 transport is lossless or not. > Consider a VOD stream served over HTTP/TCP vs a video conferencing > application over RTP/UDP. HTTP delivery should be a first class use > case. > OK, let's add this clarification to the draft. I still think best to target the lossy case. Clearly the the only way the lossless case will suffer for this is in increased bandwidth. You've not engaged the topic in your response but I hope I've made the case that bandwidth efficiency should not be the primary focus of this project. > > > Section 4, fourth paragraph, last sentence: > > > > There certainly are video interfaces (e.g. HDMI) that support incremental > > delivery of frames. What are the interfaces that do not support > subframes? > > > > They're generally not exposed in most software APIs. > > Some sort of sub-frame encode latency support is probably valuable. In > the case where say the encoder and camera are on the same chip, you > can pipeline the encode with the camera. Even if you only get a whole > frame at the encoder, it could be valuable to be able to ship the data > as soon as you can fill an RTP packet, rather than waiting until the > whole frame is encoded. There are also pipelining considerations where > you'd want to be able to start decoding a frame before the previous > frame is complete in some cases (not relevant to low latency, but > mentioned in the same vein of data dependencies) > My reason for making the comment is I'm advocating low-latency is an important requirement and it is compatible with other requirements of the project. Sub-frame encoding immediately saves you up to 30 ms. That's a gain that's hard to ignore. There are several commercial implementations (e.g. Cavium) that do this now. If the APIs need to be improved to support this, let's improve them. > > > Section 4, fifth paragraph, bullet 2: > > > > This is great for storage but, I'm not convinced this is helpful for > > networks. For network operations, lower average bitrates with higher > > unpredictability may be worse than higher average bitrates with greater > > predictability. > > > > If you want to keep this in, reference the teleconference applications in > > sections 3.2 and 3.3 and explain how this helps those applications. > > > > This is more of an issue for VOD applications rather than > teleconferencing. The rate variance you can accept is governed by how > much you can prebuffer. Taking advantage of this where possible can > get you substantial quality gains vs constant bitrate, for the same > average bitrate. > 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? > > [...] > > Section 5.2 first paragraph: > > > > Here's another opportunity to focus the project. The current text seems > to > > be saying that the the codec can be all things to everyone. At the BoF, > the > > primary IETF value of the effort was identified as open connectivity and > the > > biggest risk identified was IPR issues. > > > > I will suggest that we want to build a low-complexity codec. A simpler > codec > > should interoperate more easily and be better at achiving our > connectivity > > goal. The reduced complexity should present a smaller surface of exposure > > for IPR issues. > > > > I think that falling short of same feature sets and quality bars > posted by at least the two codecs mentioned in this section would be a > mistake, and we likely should be aiming substantially higher. > 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.
- [video-codec] Comments on draft-maxwell-videocode… Kevin Gross
- Re: [video-codec] Comments on draft-maxwell-video… John Koleszar
- Re: [video-codec] Comments on draft-maxwell-video… Kevin Gross
- Re: [video-codec] Comments on draft-maxwell-video… Timothy B. Terriberry
- Re: [video-codec] Comments on draft-maxwell-video… Ali C. Begen (abegen)
- Re: [video-codec] Comments on draft-maxwell-video… Timothy B. Terriberry
- Re: [video-codec] Comments on draft-maxwell-video… Timothy B. Terriberry
- Re: [video-codec] Comments on draft-maxwell-video… Ali C. Begen (abegen)
- Re: [video-codec] Comments on draft-maxwell-video… Timothy B. Terriberry
- Re: [video-codec] Comments on draft-maxwell-video… Sergio Garcia Murillo
- Re: [video-codec] Comments on draft-maxwell-video… Kevin Gross
- Re: [video-codec] Comments on draft-maxwell-video… Basil Mohamed Gohar
- Re: [video-codec] Comments on draft-maxwell-video… Ralph Giles
- [video-codec] Comments on draft-maxwell-videocode… Tom Sparks