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

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 5 Apr 2017 00:40:05 +1000

Any other comments on this draft? So far, we heard from Jean-Marie and
Victor supporting the draft. If you have any 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 <[email-masked]>
wrote:

> WG,
>
> We are starting WGLC for the following draft. Please review the draft and
> send your comments to the list by March 13th. 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
>

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 5 Apr 2017 00:26:59 +0000

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.”

SMPTE ST 2042-1 does define the structure of Auxiliary Data and Padding.  While this payload definition does not need to normatively say anything about receiver behavior regarding these fields, I feel that Auxiliary Data and Padding should be able to be carried in this payload.

“These four packet-types can be distinguished by the fact that they
   use different codes in the "PC" field,”

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.

I am concerned about the bit limitation on slice_prefix_bytes and slice_size_scalar.  While in practice 16 bits might be enough, it looks like ST 2042-1 has no limit, and instead a length/value combo might be more appropriate.

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.

-Thomas

--
Thomas Edwards
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

From: "Ali C. Begen" <[email-masked]>
Date: Tuesday, April 4, 2017 at 7:40 AM
To: "[email-masked]" <[email-masked]>
Cc: Thomas Edwards <[email-masked]>
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. If you have any 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 <[email-masked]<mailto:[email-masked]>> wrote:
WG,

We are starting WGLC for the following draft. Please review the draft and send your comments to the list by March 13th. 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Dvc2hq_&d=DwMFaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=nODGKNtr0Ro-UX0laVDU6Xf_tCrbxuTrZ74oSLwzCeg&s=rMSMDntd8k0qHAsmU3Bqlfg8WUoQrW-0nT5O_jIwFbs&e=>

-acbegen

---

From: James Barrett <[email-masked]>
Date: Wed, 5 Apr 2017 09:42:16 +0000

> 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.

> 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: [email-masked]

> On 5 Apr 2017, at 01:26, Thomas Edwards <[email-masked]> wrote:
>
> 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
>
> On Fri, Feb 24, 2017 at 9:02 AM, Ali C. Begen <[email-masked]> 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.
>>
> _______________________________________________
> payload mailing list
> [email-masked]
> 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.
-----------------------------

---

From: John Fletcher <[email-masked]>
Date: Wed, 5 Apr 2017 10:47:54 +0000

Here are some comments:

A revised version of the VC-2 specification SMPTE ST 2042-1 has reached Draft Publication status and is likely to be published in the next 2 or 3 months.  Given that section 4.3 of the memo discusses items that are changed in the new version of VC-2, I suggest that the memo is updated to reflect the new version.  I am not sure of the timescale for progression to RFC but I would suggest delaying this if necessary until the SMPTE document is published.

In section 4.1, the description of the Timestamp field says it “corresponds to the sampling instant of the coded picture”.  This will not be the case if source of the RTP stream is replayed video.  It also may not be the case if the input to the RTP encoder is slightly delayed with respect to image capture (highly likely) and/or the interface does not provide the capture time.  I suggest re-wording this section.

Also in section 4.1, description of Timestamp, I suggest adding: “If the required timestamp does not correspond to an integer value of the clock, e.g. when the frame or field rate is 60000/1001, the value SHALL be truncated to the next lowest integer.”

Section 5, Congestion control, says it SHALL be in accordance with RFC3550 but all that RFC3550 says is that congestion control SHOULD be defined in each RTP profile.  The section also makes reference to an Internet Draft and I believe this is not allowed.  Congestion control is not really a matter for Payload Format Specifications and I suggest this section is deleted.

In section 6.1 under “security considerations”, I suggest changing the text to “Please see section 8 of this memo".

In Normative References, RFC3551 is listed but it is not a normative reference, it is only referred to as an example.

In Normative References, as noted earlier, reference to I-D.ietf-avtcore-rtp-circuit-breakers is inappropriate and will not be needed if the Congestion Control section is removed.

Regards,
John Fletcher

From: payload [mailto:[email-masked]] On Behalf Of Ali C. Begen
Sent: 04 April 2017 15:40
To: [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

@Thomas

Thanks.
-acbegen (co-chair)

-acbegen

----------------------------

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.

---------------------

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 5 Apr 2017 19:12:44 +0000

This discussion of the “true meaning” of RTP timestamps for all possible use cases has been going on for quite a while in SMPTE, and frankly is not quite over (will it ever be over?)

My suggestion for IETF process would be to not burden any particular RTP payload with this debate, but perhaps once SMPTE has come to some industry-wide consensus, that consensus can be passed to the IETF for revision of the base RTP document RFC 3550.

I feel that the key is that this payload document is to be clear that the RTP timestamp refers to the timing of the entire picture, not the timing of a subset of the picture or the timing of a particular individual RTP packet - and I believe the document is clear on this issue.  This will be true regardless of any further interpretation of the meaning of the RTP timestamp in a wide variety of use cases.

-Thomas

From: payload <[email-masked]> on behalf of John Fletcher <[email-masked]>
Date: Wednesday, April 5, 2017 at 3:47 AM
To: "Ali C. Begen" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 5 Apr 2017 19:35:17 +0000

Knowing that the “new parse codes” are in SMPTE ST 2042-1:2017 makes me feel better.

However, now I share John Fletcher’s concern that the I-D should reference and be built based on SMPTE ST 2042-1:2017.

It is true that as per “https://www.ietf.org/iesg/statement/normative-informative.html”:
Normative references in RFCs cannot be to "work in progress" documents such as Internet Drafts. Drafts with such references will not be published as RFCs until the references are also published.

But the good news is that SMPTE ST 2042-1:2017 is pretty much done.  At this point in the SMPTE process, without going into details, I do not think significant changes can occur, so it is a stable document.  I think the only thing that could really change at this point is if there is a problem found in the Normative References.

-Thomas

On 4/5/17, 2:42 AM, "James Barrett" <[email-masked]> wrote:

---

From: "Ali C. Begen" <[email-masked]>
Date: Thu, 6 Apr 2017 12:56:54 +1000

Hi John,

On Wed, Apr 5, 2017 at 8:47 PM, John Fletcher <[email-masked]>
wrote:

> Here are some comments:
>
>
>
> A revised version of the VC-2 specification SMPTE ST 2042-1 has reached
> Draft Publication status and is likely to be published in the next 2 or 3
> months.  Given that section 4.3 of the memo discusses items that are
> changed in the new version of VC-2, I suggest that the memo is updated to
> reflect the new version.  I am not sure of the timescale for progression to
> RFC but I would suggest delaying this if necessary until the SMPTE document
> is published.
>

Depending on the external parties always creates concerns and also some
issues. So, if the final spec due date is that close, I think we better
wait for it and then finish the RTP work. Does anybody object to this?

>  In section 4.1, the description of the Timestamp field says it
> “corresponds to the sampling instant of the coded picture”.  This will not
> be the case if source of the RTP stream is replayed video.  It also may not
> be the case if the input to the RTP encoder is slightly delayed with
> respect to image capture (highly likely) and/or the interface does not
> provide the capture time.  I suggest re-wording this section.
>

How the RTP timestamps is used, it is a bit different story. I see that
Thomas replied to this as well. The payload drafts are flexible in terms of
how they can use the timestamps. So, if there is any requirement from the
SMPTE folks on this, we should use that one in this draft. Is there?

>  Also in section 4.1, description of Timestamp, I suggest adding: “If the
> required timestamp does not correspond to an integer value of the clock,
> e.g. when the frame or field rate is 60000/1001, the value SHALL be
> truncated to the next lowest integer.”
>
>
>
> Section 5, Congestion control, says it SHALL be in accordance with RFC3550
> but all that RFC3550 says is that congestion control SHOULD be defined in
> each RTP profile.  The section also makes reference to an Internet Draft
> and I believe this is not allowed.  Congestion control is not really a
> matter for Payload Format Specifications and I suggest this section is
> deleted.
>

See https://tools.ietf.org/html/draft-ietf-payload-rtp-howto-14#section-7.3

Essentially this section has to exist, what goes in there depends on the
payload format and how it is used (or how it should not be used).

-acbegen

>
> In section 6.1 under “security considerations”, I suggest changing the
> text to “Please see section 8 of this memo".
>
>
>
> In Normative References, RFC3551 is listed but it is not a normative
> reference, it is only referred to as an example.
>
>
>
> In Normative References, as noted earlier, reference to
> I-D.ietf-avtcore-rtp-circuit-breakers is inappropriate and will not be
> needed if the Congestion Control section is removed.
>
>
>
>
>
> Regards,
>
> John Fletcher
>
>
>
> *From:* payload [mailto:[email-masked]] *On Behalf Of *Ali C.
> Begen
> *Sent:* 04 April 2017 15:40
> *To:* [email-masked]
> *Subject:* Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01
>
>
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.

---

From: John Fletcher <[email-masked]>
Date: Thu, 6 Apr 2017 10:55:15 +0000

Hi Ali,

Thanks for the guidance.  My responses inline below prefixed with [JF].

Regards,
John

From: Ali C. Begen [mailto:[email-masked]]
Sent: 06 April 2017 03:57
To: John Fletcher
Cc: [email-masked]
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

Hi John,

On Wed, Apr 5, 2017 at 8:47 PM, John Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
Here are some comments:

Depending on the external parties always creates concerns and also some issues. So, if the final spec due date is that close, I think we better wait for it and then finish the RTP work. Does anybody object to this?

How the RTP timestamps is used, it is a bit different story. I see that Thomas replied to this as well. The payload drafts are flexible in terms of how they can use the timestamps. So, if there is any requirement from the SMPTE folks on this, we should use that one in this draft. Is there?

[JF] There are some rather complex provisions in the draft SMPTE ST 2110-20 (which is based on RFC 4175) regarding timestamps but I agree with Thomas that it is best not to burden the payload format with this.  However, the language needs to be sufficiently flexible that requirements for replayed media etc. can be accommodated.  I suggest the following text:

Packets that contain transform parameters or coded slice data for the same coded picture MUST have the same timestamp.  A single RTP packet MUST NOT contain coded data for more than one coded picture, so there is no ambiguity here.
Timestamps for successive coded pictures MUST increment in accordance with the picture rate.
A 90kHz clock SHOULD be used.  If the required timestamp does not correspond to an integer value of the clock, e.g. when the picture rate is 60000/1001, the value SHALL be truncated to the next lowest integer.
A sequence header packet SHOULD have the same timestamp as the next picture which will follow it in the stream.  An End of Sequence packet SHOULD have the same timestamp as the previous picture which appeared in the stream.

Essentially this section has to exist, what goes in there depends on the payload format and how it is used (or how it should not be used).

[JF] OK, the “how to” document says “it is recommended that all RTP payload format documents discuss the possibilities that exist to regulate the bit-rate of the transmissions”.  I suggest that this section is limited to discussing the possibilities and does not make normative provisions.

-acbegen

Regards,
John Fletcher

From: payload [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ali C. Begen
Sent: 04 April 2017 15:40
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-vc2hq-01

@Thomas

Thanks.
-acbegen (co-chair)

-acbegen

http://www.bbc.co.uk

---------------------