Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

> SMPTE ST 2042-1 does define the structure of Auxiliary Data and Padding.  While this payload definition Auxiliary Data and Padding should be able to be carried in this payload.

I will work up a revised version with a mechanism for carrying Auxiliary Data which can also be used for padding, but I suggest that we recommend that padding need not be sent.

> Suggest expand “PC so it becomes  ‘the “PC” (Parse Code) field’ as this is first use of “PC”.
>
> Might want to be clear that the “F” bit doesn’t apply to progressive pictures.

Makes sense.

> I am concerned about the bit limitation on slice_prefix_bytes and slice_size_scalar.  While in practice 16 appropriate.

I understand your concern, but it is highly unlikely that either of these values will ever even approach the 16-bit limit, and a size/value pair could make parsing in hardware more complex.

> It scares me a bit that this draft is defining new parse codes, as opposed to using a fragmentation flag (or fragment number) in the payload header.  It may be confusing to implementers.

If it helps these parse codes match ones being added to the next iteration of the VC-2 specification currently being considered by SMPTE to allow fragmentation of pictures within a VC-2 stream.

--
James P. Weaver (né Barrett)
Research Engineer
BBC R&D North Lab,
Floor 5 Dock House, MediaCity,
M50 2LH
Tel: +44(0)30 3040-9521
e-mail: james.barrett@bbc.co.uk

> On 5 Apr 2017, at 01:26, Thomas Edwards <Thomas.Edwards@fox.com> wrote:
>
> I will preface this with the fact that I am NOT a VC-2 expert.  But I am very glad to see this I-D making progress.  So here we go:
>
> Comments on draft-ietf-payload-rtp-vc2hq-01 from Thomas Edwards:
>  “At time of writing there is currently no definition for the use of
>    Auxiliary Data in VC-2, and Padding Data is required to be ignored by
>    all receivers.”
>
> “  Since there is no definition for the use of Auxiliary Data Units and
>    Padding Data Units are defined by the VC-2 spec to be ignored by all
>    decoders this specification only covers the transport of Sequence
>    Headers, High Quality Pictures, and (optionally) End of Sequence
>    headers.”
>
> “These four packet-types can be distinguished by the fact that they
>    use different codes in the "PC" field,”
>
>
>
>
>
> -Thomas
>
> --
> Thomas Edwards
> VP Engineering & Development
> FOX Networks Engineering and Operations
> thomas.edwards@fox.com
> Phone: +1.310.369.6696
> 10201 West Pico Blvd.
> Los Angeles, CA 90035
>
> From: "Ali C. Begen" <ali.begen@networked.media>
> Date: Tuesday, April 4, 2017 at 7:40 AM
> To: "payload@ietf.org" <payload@ietf.org>
> Cc: Thomas Edwards <Thomas.Edwards@fox.com>
> Subject: Re: WGLC for draft-ietf-payload-rtp-vc2hq-01
>
> Any other comments on this draft? So far, we heard from Jean-Marie and Victor supporting the draft. comments, please send them by next Wed (April 12th).
>
> @Thomas
>
> I believe you volunteered to review this draft? Could you submit it by next week?
>
> Thanks.
> -acbegen (co-chair)
>
> On Fri, Feb 24, 2017 at 9:02 AM, Ali C. Begen <ali.begen@networked.media> wrote:
>> WG,
>>
>> We are starting WGLC for the following draft. Please review the draft and send your comments to If you read the draft but you have no comments, say so as well.
>>
>> It is a short document, so should be a quick review.
>> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/
>>
>> -acbegen
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------