IETF Logo Mail Archive

[payload] Review of draft-ietf-payload-vp8-08

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 26 February 2013 05:45 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1840521F8D05 for <payload@ietfa.amsl.com>; Mon, 25 Feb 2013 21:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.583
X-Spam-Level:
X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 32cudDy5aVBg for <payload@ietfa.amsl.com>; Mon, 25 Feb 2013 21:45:40 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 05D3B21F8937 for <payload@ietf.org>; Mon, 25 Feb 2013 21:45:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2143; q=dns/txt; s=iport; t=1361857540; x=1363067140; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3dKgosz8faqHFhScPIWUn64/erT1QapqqeHwhcr7wIo=; b=Qw3xACeeLyYRywO7jHb5ku8G5QQHrswXUbwl/WtKWp2EFFqqyGaNjwdc wYEXaTo7P7NuAGB7XDobymMT6hFqQ4lp0HitNLocsO8ydm5I9Oe5I07yh wKcNYpMwZfnAQqeXF/OEkgqFpcbPtsPHy/wxuXRmeWJNS2av+KtjQt/AS 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJlKLFGtJV2c/2dsb2JhbABFwWSBAxZzgiEBBDpRASoUQicEGxOHeJ5lkRWQAo1EgRWDF2EDpySDB4FqPQ
X-IronPort-AV: E=Sophos;i="4.84,737,1355097600"; d="scan'208";a="181182480"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2013 05:45:39 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q5jdjf004716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <payload@ietf.org>; Tue, 26 Feb 2013 05:45:39 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 23:45:38 -0600
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "<payload@ietf.org>" <payload@ietf.org>
Thread-Topic: Review of draft-ietf-payload-vp8-08
Thread-Index: AQHOE+SBCBGG65gUD0CDCg9/8nULHw==
Date: Tue, 26 Feb 2013 05:45:37 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB113403D6E@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.71.53]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2967122885AB6E41B7AEA811840F9652@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 26 Feb 2013 01:00:19 -0800
Subject: [payload] Review of draft-ietf-payload-vp8-08
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2013 05:45:45 -0000

My major issues is I think it is not appropriate to define a temperable scalable codec in the same draft as the payload. I'm fine with the payloads for it but I think the temporal scalability stuff should be moved to a separate draft outside of payload - it's very confusing having the two mixed together. 

Need to be able to negotiate upper bound on resolution and frame rates - every time I have brought this up in the past the authors have strongly objected but I don't understand how hardware codecs work without this. The hardware codecs need to have the 4 image buffers and they will have a limit to the size of theses. My preferred way of dealing with resolution would be just to mandate use of rfc6236 when using VP8. 

I don't see a need for 7 bit pictureID, it just adds to complexity that will not be tested

The temporal stuff does not seem to be specified very well. To be more specific, I think creating a layered codec from a non layered codec would better be done in a spec other than the payload description. Among other things that space is littered with IPR issues that should not be confused with the base payload

The SDP does not allow one to specify the color space's supported but is seems that VP8 does so seems like something is needed in SDP. 

I'd like to see negotiation of the loop filter type used for a variety of reasons 

I'd like to see negotiation of the reconstrcuction filter type(s) used - amount other things new ones can be added to VP8 and we need a way to support that. 

I'd like to see what the limits are of google hardware implementation (or anyone else's if they exist) and make sure that all theses limits can be expressed in SDP. 

I'd like to see a way of describing upper bound on macro block rate instead of the combined max-fs / max-fr solution. I don't see how to make hardware decoders work without this. 

It would be good to see more advice on how many partitions to use and why. 

I'm confused on the Y bit. 

Unclear if receiver is supposed to send positive ACK RPSI

v2.23.0 | Report a Bug | By Email