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

Harald Alvestrand <harald@alvestrand.no> Mon, 07 March 2011 09:56 UTC

Return-Path: <harald@alvestrand.no>
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 7777B3A68EC for <payload@core3.amsl.com>; Mon, 7 Mar 2011 01:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 yaaqGc8JseMu for <payload@core3.amsl.com>; Mon, 7 Mar 2011 01:56:11 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 3378F3A6934 for <payload@ietf.org>; Mon, 7 Mar 2011 01:56:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14C7139E17B; Mon, 7 Mar 2011 10:56:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0C6-cHP7QHG; Mon, 7 Mar 2011 10:56:48 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 757A739E084; Mon, 7 Mar 2011 10:56:48 +0100 (CET)
Message-ID: <4D74AC02.4090208@alvestrand.no>
Date: Mon, 07 Mar 2011 10:57:22 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Roni Even <Even.roni@huawei.com>
References: <4D6E47BD.3000201@alvestrand.no> <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com>
In-Reply-To: <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hlundin@google.com, pwestin@google.com, payload@ietf.org
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: Mon, 07 Mar 2011 09:56:12 -0000

On 03/03/11 15:35, Roni Even wrote:
> 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.)
I'll get that updated. Most of the fields are boilerplate.
> 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.
Checking: Is this currently draft-ietf-payload-rtp-howto-00?
Patrik did a pass at updating after being pointed at the document as 
part of Magnus' review, that's the diff between the -00 and the -01 version.
> 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.
Area of active research. I'll get it considered; the comment was part of 
a consideration of using variable-protection FEC mechanisms, which was 
subsequently removed (we'll get back to that at a later stage).
> 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
It's only an example, but I agree.
>
> Going forward  you can update the individual draft regardless of when it
> becomes a WG item
Thanks!
> 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
>