Re: [payload] Request for consideration: draft-westin-payload-vp8-01

Roni Even <Even.roni@huawei.com> Thu, 03 March 2011 14:34 UTC

Return-Path: <Even.roni@huawei.com>
X-Original-To: payload@core3.amsl.com
Delivered-To: payload@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE793A67F1 for <payload@core3.amsl.com>; Thu, 3 Mar 2011 06:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.495
X-Spam-Level:
X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lr6mkA797fA for <payload@core3.amsl.com>; Thu, 3 Mar 2011 06:34:26 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 85BAA3A67E7 for <payload@ietf.org>; Thu, 3 Mar 2011 06:34:26 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH0069LKIUDW@szxga04-in.huawei.com> for payload@ietf.org; Thu, 03 Mar 2011 22:35:18 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH00IM0KIUJP@szxga04-in.huawei.com> for payload@ietf.org; Thu, 03 Mar 2011 22:35:18 +0800 (CST)
Received: from windows8d787f9 (bzq-79-183-2-17.red.bezeqint.net [79.183.2.17]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHH00NILKIJ1Y@szxml12-in.huawei.com>; Thu, 03 Mar 2011 22:35:18 +0800 (CST)
Date: Thu, 03 Mar 2011 16:35:11 +0200
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <4D6E47BD.3000201@alvestrand.no>
To: 'Harald Alvestrand' <harald@alvestrand.no>, payload@ietf.org
Message-id: <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-us
Content-transfer-encoding: 7bit
Thread-index: AcvY3sr7WAdEnG1zRhailh2Tx9slJAAzJ7mQ
References: <4D6E47BD.3000201@alvestrand.no>
Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 03 Mar 2011 14:34:30 -0000

Hi Harald,
In general there is no problem to accept a payload specification as a WG
document as long as there is just one proposal. In this case I do not think
there will be a second proposal since this is unusual for non standard
codecs.

So we can ask for a milestone.

As for progressing the work I did a very quick look and have a couple of
comments

1. The media subtype registration in section 6 is not following the
registration template (see in rtp-howto or in one of the payload RFC e.g.
RFC5391  section 5.1. You can also look at a video codec like the updated
H.264 payload http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12
which is in the RFC editor queue at the moment.)

2. The draft does not have a required congestion control section see
http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06 for payload
specification structure.

3. I noticed the division of the data to prediction mode parameters and
motion vectors partition and DCT/WHT coefficients partitions. Which enables
better resilience to loss according to the draft. In IP network the typical
loss is packet loss and not part of a packet so maybe in the congestion
control section you can provide some guideline about a recommendation of how
to build packets that can be removed.

4. In the example in section 6.4 I think that you should nave avpf and not
avp as the profile since you recommend using the feedback mechanism


Going forward  you can update the individual draft regardless of when it
becomes a WG item

Regards
Roni Even



> -----Original Message-----
> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
> Behalf Of Harald Alvestrand
> Sent: Wednesday, March 02, 2011 3:36 PM
> To: payload@ietf.org
> Subject: [payload] Request for consideration: draft-westin-payload-vp8-
> 01
> 
> Hello,
> 
> I'm not sure what the formal procedure should be, so I'm just sending
> email...
> I think that draft-westin-payload-vp8-01, describing an RTP
> encapsulation for VP8, is ready for IETF review and possible approval.
> 
> What steps do we need to take in order to get it on the proper agendas?
> 
>                   Harald Alvestrand
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload