Subject: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

From: Thomas Edwards <[email-masked]>
Date: Wed, 3 May 2017 00:48:54 +0000

IETF Payload WG WGLC (#2) for draft-ietf-payload-rtp-ancillary-08
4 April to 19 April 2017

Below are the comments and my responses to those comments.

Commenter: Kjetil Oftedal <[email-masked]> Sat, 01 April 2017 09:46 UTC

there might still be need for clarification here on the definition of field.
With 3G-level B DL(dual link)/HD DL the SDI transport format is basically a
interlaced format. But the video format is likely to be 50-60Hz progressive.
(Two concurrent interlaced fields is merged to one progressive frame)
Since this draft is uses link/SDI raster level line numbers, it should
be specified that it is the link level video format that defines whether or not this
is interlaced transport.

Reply:
appending the “F” (field) description with:

“Note that some multi-link SDI interfaces may use multiple interlaced signals to transmit progressive images, in which case ‘field’ would refer to the link field.”

Commenter: Roni Even <[email-masked]> Wed, 05 April 2017 08:07 UTC
I have a  comment about section 5.  The procedure is not relevant for RTSP or SAP since it is not for declarative SDP only for SIP offer/answer when there is an answerer

Reply:

Change 5.1 to:

5.1  Offer/Answer Model

   Receivers might wish to receive ANC data streams with specific DID_SDID
   parameters.  Thus when offering ANC data streams using the Session
   Description Protocol (SDP) in an Offer/Answer model [RFC3264], the
   offeror MAY provide a list of ANC streams available with specific
   DID_SDID parameters in the fmtp line.  The answerer MAY
   respond with all or a subset of the streams offered along with fmtp
   lines with all or a subset of the DID_SDID parameters offered.  Or
   the answerer MAY reject the offer.  There are no restrictions on
   updating DID_SDID parameters in a subsequent offer.

And add:

5.2.  Declarative SDP Considerations

   For declarative use of SDP, nothing specific is defined for this
   payload format.  The configuration given by the SDP MUST be used when
   sending and/or receiving media in the session.

Commenter: 
John Fletcher <[email-masked]> Thu, 20 April 2017 10:22 UTC
1) In section 2.1, definition of "C" bit, HD signals are mentioned but not UHD.  I think the definition really depends on whether the SDI interface uses separate data channels for luma and color-diff, so perhaps the specification could be re-worded along those lines.  At the very least, say "HD and UHD signals".

Reply:
Change to “For HD signals, this flag, when set to "1", indicates that the ANC data corresponds to the color-difference channel (C).”

2) Specifications about RTP timestamp clock rate appear in section 3.1 as part of the media format parameters but I think these should be in section 2 as part of the timestamp definition.  Section 3.1 should just say that the Rate parameter is required.

Reply:
This test was added to section 3.1 resolving a comment on draft-ietf-payload-rtp-ancillary-03 from Jonathan Lennox <[email-masked]> on 23 June 2016.  It is not unknown to put requirements on timestamp rates in the Media Type Definition when it is an issue that revolves around SDP description (such as association with other RTP streams).  As the document has already passed SECDIR/OPSDIR/GENART reviews, I think it is not wise to make this change in document structure.

3) Section 1, Introduction, uses normative word "should" in "It should be noted that".  I suggest changing to "Note that".

Reply:
Change to “Note that the ancillary data flag…”
[in general, I am not opposed to minor editorial changes to be precise about normative language]

4) In section 3.1, the normative word "may" is used in "implementers may care" and "may not care".  It's not appropriate to give implementers permission or to forbid them from caring.  I suggest changing to "might".

Reply:
Change to “Some implementations might care about the
   location of the ANC data packets in the SDI raster, but other
   implementations might not care.”

5) In section 3.1, "those that must interoperate with", I suggest deleting "must".

Reply:
Change to “Devices that stream real-time
   professional video, especially those that interoperate with
   legacy serial digital interfaces (SDI).”

6) In section 4, "the ancillary data stream may potentially contain", suggest changing to "might" to indicate possibility rather than permission.

Reply: 
Change to “If a DID_SDID parameter is not
   specified, then the ancillary data stream might potentially contain
   ancillary data packets of any type.”

7) In section 4.1, the normative word "may" is used in "implementers may wish to".  It's not appropriate to give implementers permission to wish.  I suggest deleting "to wish".

Reply:
To avoid any normativity, change to “To associate an ANC RTP stream with other media streams, implementers
   can use the Lip Synchronization…”

8) In section 5, again we have "may with", I think meant to be "may wish".  I suggest changing to "might wish" in this case.  Other uses of "may" in this section seem fine but should be capitalised.

Reply:
Incorporated into reply to comment from Roni Even <[email-masked]> Wed, 05 April 2017 08:07 UTC

9) In section 7, "It may still be a good idea", suggest changing "may" to "might".

Reply:
Change to “It might still be a good idea for these…”

10) In section 7, "receivers should take care to", I suggest deleting "take care to".

Reply:
Change to “To avoid potential buffer overflow attacks, receivers SHOULD validate that the ANC data packets in the RTP payload are of
   the appropriate length”

11) Some uses of "required" in the memo are not specifying normative requirements, suggest re-wording or changing to "needed".

Reply:
Change to “Ancillary space roughly corresponds to vertical and horizontal blanking periods of cathode ray tube type displays.”

Change to: “When a payload format is registered with SMPTE, it is identified by a registered data identification word.”

12) Several occurrences of "may", "must", "should", "required" and "optional" are not capitalised.

Reply:

Change to “A value of 0x7FE indicates that the ANC data is intended to be placed into any legal area of VANC, specifically.”

Change to “Note that the lines that are available to convey ANC data are as defined in the applicable sample structure specification
           (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656
           [BT656]) and possibly further restricted per SMPTE RP 168
           [RP168].”

Change to “A value of 0xFFE indicates that the ANC data is intended to be placed into any legal area of HANC, specifically.”

Change to “The absence of the DID_SDID parameter signals that  determination of the DID and SDID of ANC packets in the payload can only
be achieved through direct inspection of ANC data packet fields.” 

Capitalize other occurrences where clearly normative.

-- 
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: John Fletcher <[email-masked]>
Date: Wed, 3 May 2017 14:55:08 +0000

Regarding the C bit, I don't see any change.
I suggest: "If the data corresponds to the color-difference data channel of the SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of the SDI interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0"."

And a further comment...
The LinkNumber parameter cannot be used if there is data from more than one link in the RTP stream.  And a single number is inadequate for interfaces that mave multiple links and multiple data streams per link.  If it is a requirement to  reproduce link/data stream when going SDI->RTP->SDI then link number and data stream number need to be in the payload header for each ANC packet.

John

________________________________________
From: payload [[email-masked]] on behalf of Thomas Edwards [[email-masked]]
Sent: 03 May 2017 01:48
To: [email-masked]
Subject: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

Reply:

Reply:

Change 5.1 to:

5.1  Offer/Answer Model

And add:

Commenter:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

Reply:

_______________________________________________
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: Thomas Edwards <[email-masked]>
Date: Wed, 3 May 2017 21:49:11 +0000

Sorry, for some reason the C bit change did not get noted.

The original text from SMPTE ST 2038-2008 is:

“c_not_y_channel_flag: For HD, this flag, when set to ‘1’, indicates the ANC data corresponds to the color difference channel. When set to ‘0, this flag indicates the ANC data corresponds to the luminance channel. For SD, this flag shall be set to ‘0’.”

I think it is best to keep the description close to this proven data model, so I suggest that we simply change the first sentence of the C bit ANC data packet header field to read:

“For HD or UHD signals, this flag, when set to "1", indicates that the ANC data corresponds to the color-difference channel (C).”

Regarding the link number, I see your argument that it really should be carried in the ANC data packet header fields.  We have a few reserved bits now after Horizontal_Offset, so I guess we can use them.

To try to do this correctly, I think we should reference the SMPTE ST 352 use of bits b7 to b5 of byte 4 of the default payload identifier as a channel assignment field for channels 1-8.

This would result in a new ANC data packet payload header field:

“Channel Assignment: 4 bits

This field can indicate the channel number of a multi-channel link used to transport the ANC data packet.
If the first bit of this field is ‘0’, then this field provides no guidance regarding the channel placement of the ANC data packet.
If the first bit of this field is ‘1’, then the following bits MUST carry the channel identification information of section 5.5.1 of SMPTE ST 352 contained in byte 4 of the payload identifier.
The second bit of the channel assignment field carries bit b7 of byte 4 of the payload identifier, the third bit carries bit b6, and the fourth bit carries bit b5.”

With the addition of the Channel Assignment ANC data packet header field, I think it is appropriate to remove LinkNumber from the Media Type Definition.  In truth, looking through various multi-link SDI interfaces and their use of SMPTE ST 352, I’m not 100% sure the current definition of LinkNumber would always be clear & appropriate, but the bits in Byte 4 from SMPTE ST 352 will always be clear.

-Thomas

On 5/3/17, 7:55 AM, "John Fletcher" <[email-masked]> wrote:

    And a further comment...
    
    John

---

From: John Fletcher <[email-masked]>
Date: Thu, 4 May 2017 11:16:36 +0000

Regarding the C bit, I suggest deleting "for HD or UHD signals" because those those formats do not always map to an interface with luma and color-difference data channels.  I also think you should use the term "data channel" as in ST 292-1 section 4.2

The link number change looks good.  It would be nice to add the data stream number as well using the other 4 bits (current max is 8 data streams in 12G SDI).

To make sense of link number and data stream number, you really need to know the interface format (e.g. whether it is ST 372 dual-link 1.5G or ST 425-1 single-link 3G).  Could this be included in the payload format parameters?

John
________________________________________
From: payload [[email-masked]] on behalf of Thomas Edwards [[email-masked]]
Sent: 03 May 2017 22:49
To: [email-masked]
Subject: Re: [payload] Addressing comments on 2nd WGLC of draft-ietf-payload-rtp-ancillary-08

-Thomas

    And a further comment...

    John

---

From: Thomas Edwards <[email-masked]>
Date: Thu, 4 May 2017 22:38:43 +0000

>On 5/4/17, 4:16 AM, "John Fletcher" <[email-masked]> wrote:
> Regarding the C bit, I suggest deleting "for HD or UHD signals" because those those formats do not always map to an interface with luma and color-difference data channels.
> I also think you should use the term "data channel" as in ST 292-1 section 4.2

That would leave the description as:

“C: 1 bit
           This flag, when set to "1", indicates that
           the ANC data corresponds to the color-difference data channel (C).
           When set to "0", this flag indicates that the ANC data
           corresponds to the luma (Y) data channel.  For SD signals, this
           flag SHALL be set to "0".  For ANC data packets that do not
           originate from SDI sources, if the ANC data type definition
           requires the use of the C or Y data channel, the C flag SHALL
           reflect that requirement, otherwise the C flag SHALL be set
           to "0".”

Does that address your concerns?

>To make sense of link number and data stream number, you really need to know the interface format (e.g. whether it is ST 372 dual-link 1.5G or ST 425-1 single-link 3G).  Could this be >included in the payload format parameters?
  
Actually your comment on stream number and reading through all of the various dual and quad-link interfaces has lead me to believe that stream number is the key, not link number.  A stream number, for a given video format standard, should define the link number, thus there is no reason to signal both.  We need to handle up to 32 data streams for the extreme case of SMPTE ST 2082-12: 4320-line and 2160-line Source Image and Ancillary Data Mapping for Quad-link 12G-SDI.

So let’s forget the “Channel Assignment” field, and instead have a “Data Stream Number” field:

    “Data Stream Number: 6 bits
    
    This field can indicate the data stream number of a multi-stream data mapping used to transport the ANC data packet.
    If the first bit of this field is ‘0’, then this field provides no guidance regarding the data stream number of the ANC data packet.
    If the first bit of this field is ‘1’, then the following five bits MUST carry the data stream number minus one of the ANC data packet.

    For multi-stream interface formats that do not have numbered data streams, but instead have lettered data stream links 
    (such as SMPTE ST 372), the following numbers SHALL be used in this field: ‘0’ for link A data stream, ‘1’ for link B data stream.

    For stereoscopic multi-stream interface formats that do not have numbered streams, the following numbers SHALL be used in
    this field: ‘0’ for left eye stream, ‘1’ for right eye stream.”

And I think it is reasonable to have the Video Payload Identification Codes as an optional parameter in the Media Type Definition:

“VPID_Code:
	This integer parameter specifies the Video Payload ID (VPID) Code of the source interface of ANC data packets using the value
from byte 1 of the VPID as defined in SMPTE ST 352.  The integer SHALL be made with bit 7 of VPID byte 1 being the most significant bit,
and bit 0 of VPID byte 1 being the least significant bit.  For example, 132 shall refer to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gbps
(nominal) serial digital interface.”

-Thomas
  
    John

    

    

    

    
    -Thomas

    
        And a further comment...
    
        John

    _______________________________________________
    payload mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwIF-g&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=__cAFj6LOkUA89j9fGP9CGciM2-M4ExhUSqjK-175QM&s=pAmH8LqbSlkQikYxG71ieJyiPcxIFxBQWQ4kqGgKbKo&e=

---

From: John Fletcher <[email-masked]>
Date: Fri, 5 May 2017 17:38:40 +0000

Regarding the C bit, I think something like my originally suggested wording is better:

If the data corresponds to the color-difference data channel of an associated SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of an associated SDI interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0".

Reasons being (a) you should mention that luma/color-difference channels are things in an SDI interface; (b) your suggested wording says  that if it is set to "0" the ANC data  corresponds to the luma (Y) data channel, but that is not necessarily true, it might be because there are no luma/color-difference channels or because  there is no associated SDI interface.

Regarding link number, you probably need to explain that if there are 2 links with 4 data channels each, you number the data channels across all links so that link 2, data channel 1 is the 5th data channel etc.   You might also want to allow another bit so you could go up to 24 Gbit/s interfaces.

Including the payload ID byte 1 value is a good idea.

It would be good to run all this by an SDI expert.

John

Sent: 04 May 2017 23:38

“C: 1 bit

“VPID_Code:

-Thomas

    John

    -Thomas

        And a further comment...

        John

---

From: Thomas Edwards <[email-masked]>
Date: Fri, 5 May 2017 23:01:03 +0000

>On 5/5/17, 10:38 AM, "John Fletcher" <[email-masked]> wrote:

> If the data corresponds to the color-difference data channel of an associated SDI interface, the C flag shall be set to "1".  If the data corresponds to the luma data channel of an associated SDI 
>interface, or the interface does not have separate luma and color-difference data channels, or the data is not associated with an SDI interface, the C flag shall be set to "0".
    
> Reasons being (a) you should mention that luma/color-difference channels are things in an SDI interface; (b) your suggested wording says  that if it is set to "0" the ANC data  corresponds to the >luma (Y) data channel, but that is not necessarily true, it might be because there are no luma/color-difference channels or because  there is no associated SDI interface.
  
I think we’ve discussed this before (see: https://mailarchive.ietf.org/arch/msg/payload/cd-_KMT18N7x4qJx--3BgBYbWp0).  There are ANC data packet standards that require the use of particular data channels.  Even if the ANC data packet is not sourced from an SDI interface, it is best if it is marked in the proper data channel so that downstream devices re-embedding in SDI can do their job properly.  And even if there is no SDI period, I don’t think it hurts much to mark the ANC data packets in the data channel required by their defining standard. 
 
>Regarding link number, you probably need to explain that if there are 2 links with 4 data channels each, you number the data channels across all links so that link 2, data channel 1 is the 5th data > channel etc. 

The link a particular stream uses would be specified by the interface standard.  I can add that as a note.

>You might also want to allow another bit so you could go up to 24 Gbit/s interfaces.
  
I’m OK with throwing one more bit in to be extensible.  However, to be clear, there are no current SMPTE SDI standards or projects that I am aware of that need more than 32 streams.  I also hope that if SMPTE does standardize a 24 Gbps interface that they do it in a less arcane fashion than having 64 streams.
 
 -Thomas

---

From: John Fletcher <[email-masked]>
Date: Mon, 8 May 2017 10:35:17 +0000

On the C bit, I'm not disagreeing with signalling of the data channel where appropriate, just improving the wording.  In particular "if set to '0' the ANC data  corresponds to the luma (Y) data channel" is not correct because '0' would also correspond to case where there are no luma/color difference data channels or there is no association with SDI (and perhaps no requirement as to which data channel to use, even if there were an association with SDI).

On data stream number, the numbering will be different from the interface standards because they have link number and data stream number but we are combining them into a single data stream number.  I think some (normative) explanation is needed.

John
Sent: 06 May 2017 00:01

 -Thomas