Re: [payload] WGLC for VP8 Payload

Jonathan Lennox <jonathan@vidyo.com> Tue, 11 December 2012 16:49 UTC

Return-Path: <jonathan@vidyo.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 A71FE21F84DB for <payload@ietfa.amsl.com>; Tue, 11 Dec 2012 08:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6]
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 62Xeasu361MJ for <payload@ietfa.amsl.com>; Tue, 11 Dec 2012 08:49:09 -0800 (PST)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id C179721F8896 for <payload@ietf.org>; Tue, 11 Dec 2012 08:49:08 -0800 (PST)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 31B118C086C for <payload@ietf.org>; Tue, 11 Dec 2012 11:49:08 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id D27558C08F6 for <payload@ietf.org>; Tue, 11 Dec 2012 11:49:07 -0500 (EST)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 11 Dec 2012 11:48:46 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "payload@ietf.org" <payload@ietf.org>
Date: Tue, 11 Dec 2012 11:49:05 -0500
Thread-Topic: [payload] WGLC for VP8 Payload
Thread-Index: Ac3Xv2+HBA+98tshSFm0IcC5LoseQw==
Message-ID: <1F6FCD47-5EA4-40EC-9682-E290C6F1A25B@vidyo.com>
References: <C15918F2FCDA0243A7C919DA7C4BE9940CD0770D@xmb-rcd-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940CD0770D@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [payload] WGLC for VP8 Payload
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, 11 Dec 2012 16:49:09 -0000

Hi -- I have two comments on this draft.  Sorry for being late.

First of all, an editorial matter: Section 6 says the format has no parameters, but section 6.1 lists two optional parameters (max-fr and max-fs).


Secondly, more substantively, I note that the payload format's rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish to splice together VP8 streams, since both values are required to always increment consecutively in a bitstream (if they're being used).

By contrast, the equivalent fields of the H.264 SVC payload format (in the PACSI) just say that IDRPICID must be different in consecutive IDR frames, without requiring that the value increment by 1; and TL0PICIDX resets to 0 on every IDR frame, rather than carrying on continuously.  (H.264's IDR frames are analogous for these purposes to VP8's essential keyframes).

This means that an H.264 SVC splicer -- as long as it doesn't get unlucky, such that the two streams it's splicing happen to have identical IDRPICID values at the splice point -- can just transition from one bitstream to another at any IDR frame.

By contrast, following a splice, a VP8 splicer must re-write both these fields for the rest of the lifetime of the stream, since they each have only one valid possible value following the splice.

The VP8 payload format's decision is a reasonable design choice -- as compared to the H.264 SVC rules, it removes some ambiguity between splice points and packet loss, giving decoders somewhat greater visibility as to what's going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be orthogonal options because they increment independently.  However, I wanted to make sure this had been considered explicitly by the working group, and we had consensus that it was the right decision.

(Note well disclaimer: Vidyo has an IPR declaration against the VP8 payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)


On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:

> I have not seen any comments on the list. Please review the draft and post
> your comments on the list.
> 
> Thanks.
> -acbegen
> 
> -----Original Message-----
> From: "Ali C. Begen" <abegen@cisco.com>
> Date: Monday, November 19, 2012 3:15 PM
> To: "payload@ietf.org" <payload@ietf.org>
> Subject: [payload] WGLC for VP8 Payload
> 
>> Hi everyone,
>> 
>> We had a WGLC for this draft earlier this year and there have been a few
>> updates to the document. I am starting a 2nd WGLC. Please review and
>> comment on the list by December 10th.
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=1
>> 
> https://www.ietf.org/mailman/listinfo/payload
> 

--
Jonathan Lennox
jonathan@vidyo.com