Re: [payload] WGLC for VP8 Payload

["Ali C. Begen (abegen)" <[e-mail]>]

Are you at least planning to put some text around the point Jonathan brought up?

From: Patrik Westin <[e-mail]<mailto:[e-mail]>>
Reply-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 14, 2012 4:53 PM
To: "Ali C. Begen" <[e-mail]<mailto:[e-mail]>>
Cc: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [payload] WGLC for VP8 Payload

Trying to send this again since my previous message did not reach the list.

Thanks for pointing out the inconsistency. We've submitted a new
draft that fixes that problem.

The second issue was intentional. We'll keep it this way.


On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks, the authors just rev'ed the draft to fix the first issue. I hope
they will address the second issue first in the list and then reflect the
agreement in the next revision. I will hold on to the doc write-up till
then.

-acbegen

-----Original Message-----
From: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>
Date: Thursday, December 13, 2012 11:29 AM
To: "Ali C. Begen" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Subject: RE: [payload] WGLC for VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've
>mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:[e-mail]<mailto:[e-mail]>]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; [e-mail]<mailto:[e-mail]>
>Cc: [e-mail]<mailto:[e-mail]>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As
>for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draft
>(assuming they agree with you) or do you actually not like this at all?
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>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" <[e-mail]<mailto:[e-mail]>>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>>> 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_tex
>>>> t=1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>[e-mail]<mailto:[e-mail]>
>>
>>
>>_______________________________________________
>>payload mailing list
>>[e-mail]<mailto:[e-mail]>
>>https://www.ietf.org/mailman/listinfo/payload
>

_______________________________________________
payload mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/payload