Subject: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

From: Thomas Edwards <[email-masked]>
Date: Fri, 12 May 2017 00:26:23 +0000

I have recently uploaded the I-D draft-ietf-payload-rtp-ancillary-09

Key items:

1)       ANC data packets now identify which stream of a multi-stream interface they come from

2)       VPID Code added as optional Media Type parameter to identify type of interface

3)       Additional clarification of Field and Y/C data channel bits

4)       Removal of RTSP/SAP from Offer/Answer

5)       Removal of any normative words not intended to be normative

These changes should be backwards-compatible with -08 implementations.

Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

Comment source: Kjetil Oftedal <[email-masked]> Sat, 01 April 2017 09:46 UTC
[note on interlace use in multi-stream progressive interfaces]
297a298,302
>            Note that some multi-stream SDI interfaces may use multiple
>            interlaced signal streams to transmit progressive images, in
>            which case the "F" bits would refer to the field of the
>            interlaced stream used for transport of the ANC data packet.

Comment source: Roni Even <[email-masked]> Wed, 05 April 2017 08:07 UTC
[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]

669a710,725
> 5.  Offer/Answer Model and Declarative Considerations
>
> 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.
...
677c733
< 5.  Offer/Answer Model and Declarative Considerations
---
> 5.2.  Declarative SDP Considerations
679,689c735,737
<    Receivers may with 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] or in a
<    declarative manner (e.g., SDP in the Real-Time Streaming Protocol
<    (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
<    [RFC2974]), the offerer 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.
---
>    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.

Comment source: John Fletcher <[email-masked]> Wed, 03 May 2017 14:57 UTC
[specify stream number]
130,131c130,131
<    of a link number, stream number, or image number of multi-link,
<    multi-stream, or multi-image SDI interfaces.
---
>    of the Video Payload ID (VPID) code of the source interface of ANC
>    data packets.

186c186
<        |C|   Line_Number       |   Horizontal_Offset   |    reserved   |
---
>        |C|   Line_Number       |   Horizontal_Offset   |S|  StreamNum  |
194c194
<        |C|   Line_Number       |   Horizontal_Offset   |    reserved   |
---
>        |C|   Line_Number       |   Horizontal_Offset   |S|  StreamNum  |

362,366c368,399
<    reserved: 8 bits
<            One octet is reserved between Horizontal_Offset and DID
<            fields, and contains "0" bits.  These reserved bits ensure
<            that the ANC data packet begins on a 32-bit word-aligned
<            boundary for ease of implementation.
---
>    S (Data Stream Flag): 1 bit
>            This field indicates whether the data stream number of a
>            multi-stream data mapping used to transport the ANC data
>            packet is specified.  If the S bit is '0', then the StreamNum
>            field provides no guidance regarding the source data stream
>            number of the ANC data packet.  If the S bit is '1', then the
>            StreamNum field carries information regarding the source data
>            stream number of the ANC data packet.
>
>    StreamNum: 7 bits
>            If the S (Data Stream Flag) bit is '1', then the StreamNum
>            field MUST carry identification of the source data stream
>            number of the ANC data packet.  If the data stream is
>            numbered, then the StreamNum field SHALL carry the number of
>            the source data stream minus one.  If the source multi-stream
>            interface does not have numbered data streams, 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.
...
>            Note that in multi-link SDI connections, the physical
>            link that a particular stream utilizes is typically specified
>            by the interface standard.

522,530c547,568
...
<       LinkNumber:
<          This integer parameter specifies that ANC data in the stream is
<          associated with a specific link number, stream number, or image
<          number of multi-link, multi-stream, or multi-image SDI
<          interfaces.
---
...
>       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
>          [ST352].  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.

594c633
<    o  The optional parameters LinkNumber and DID_SDID, when present, are
---
>    o  The optional parameters VPID_Code and DID_SDID, when present, are

625c656
<    If the optional parameter LinkNumber is present, it SHALL be present
---
>    If the optional parameter VPID_Code is present, it SHALL be present

633c664
<         a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};LinkNumber=3
---
>         a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};VPID_Code=132

640c679,680
<    The LinkNumber is 3.
---
>    The VPID_Code is 132 (referring to SMPTE ST 292-1, 720-line video
>    payloads on a 1.5 Gbps serial digital interface).

826a872,874
>    [ST352]    SMPTE, "ST 352:2013, Payload Identification Codes for
>               Serial Digital Interfaces", 2013.
Comment source: John Fletcher <[email-masked]> Thu, 20 April 2017 10:22 UTC
[clarity on C bit for interfaces without specific Y/C channels]
307,315c312,320
<            For HD signals, this flag, when set to "1", indicates that
<            the ANC data corresponds to the color-difference channel (C).
<            When set to "0", this flag indicates that the ANC data
<            corresponds to the luma (Y) 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 channel, the C flag SHALL
<            reflect that requirement, otherwise the C flag SHALL be set
<            to "0".
---
>            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 either that the ANC data
>            corresponds to the luma (Y) data channel, that the ANC data
>            source is from an SD signal, or that the ANC data source has
>            no specific luma or color-difference data channels.  However,
>            if the ANC data type definition specifically requires the use
>            of the C or Y data channel, the C flag SHALL reflect that
>            requirement.
[clearing up normative language]
90,91c92,93
<    corresponds to vertical and horizontal blanking periods required by
<    cathode ray tube type displays.  ANC can carry a range of data types,
---
>    corresponds to vertical and horizontal blanking periods of cathode
>    ray tube type displays.  ANC can carry a range of data types,

106,107d107
<    payload format is registered with SMPTE, an application document
<    describing the payload format is required, and the registered
117,118c117,118
<    ancillary data packet is identified by a registered data
<    identification word.
---
>    payload format is registered with SMPTE, it is identified by a
>    registered data identification word.

133,135c133,135
<    It should be noted that the ancillary data flag (ADF) word is not
<    specifically carried in this RTP payload.  The ADF may be specified
<    in a document defining an interconnecting digital video interface,
---
>    Note that the ancillary data flag (ADF) word is not specifically
>    carried in this RTP payload.  The ADF might be specified in a
>    document defining an interconnecting digital video interface,

325,326c330,331
<            indicates that the ANC data may be placed into any legal area
<            of VANC, specifically.
---
>            indicates that the ANC data is intended to be placed into any
>            legal area of VANC, specifically.

328,332d332
<            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 may be further restricted per SMPTE RP 168
<            [RP168].
340a341,346
>            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].

355,356c361,362
<            indicates that the ANC data may be placed into any legal area
<            of HANC, specifically.
---
>            indicates that the ANC data is intended to be placed into any
>            legal area of HANC, specifically.

522,530c547,568
<          The absence of the DID_SDID parameter signals that in order to
<          determine the DID and SDID of ANC packets in the payload, the
<          DID and SDID fields of each ANC packet must be inspected.
...
---
>          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 the ANC data
>          packet fields.
...

539c577
<    the possible data items.  Some implementations may care about the
---
>    the possible data items.  Some implementations might care about the

541c579
<    implementations may not care.
---
>    implementations might not care.

546,547c584,585
<    professional video, especially those that must interoperate with
<    legacy serial digital interfaces (SDI).
---
>    professional video, especially those that interoperate with legacy
>    serial digital interfaces (SDI).

607c646
<    specified, then the ancillary data stream may potentially contain
---
>    specified, then the ancillary data stream might potentially contain

645,648c685,688
<    may wish to use the Lip Synchronization (LS) grouping defined in RFC
<    5888 [RFC5888], which requires that "m" lines that are grouped
<    together using LS semantics MUST synchronize the playout of the
<    corresponding media streams.
---
>    can use the Lip Synchronization (LS) grouping defined in RFC 5888
>    [RFC5888], which states that media streams whose corresponding "m"
>    lines are grouped together using LS semantics are to be played back
>    in a synchronized manner.

715,721c763,769
<    To avoid potential buffer overflow attacks, receivers should take
<    care to validate that the ANC data packets in the RTP payload are of
<    the appropriate length (using the Data_Count field) for the ANC data
<    type specified by DID & SDID.  Also the Checksum_Word should be
<    checked against the ANC data packet to ensure that its data has not
<    been damaged in transit, but the Checksum_Word is unlikely to provide
<    a payload integrity check in case of a directed attack.
---
>    To avoid potential buffer overflow attacks, receivers SHOULD validate
>    that the ANC data packets in the RTP payload are of the appropriate
>    length (using the Data_Count field) for the ANC data type specified
>    by DID & SDID.  Also the Checksum_Word should be checked against the
>    ANC data packet to ensure that its data has not been damaged in
>    transit, but the Checksum_Word is unlikely to provide a payload
>    integrity check in case of a directed attack.

724,732c772
<    payload into a serial digital interface (SDI).  It may still be a
...
---
>    payload into a serial digital interface (SDI).  It might still be a

--
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: Mon, 15 May 2017 16:02:16 +0000

Thanks for the updates.  Here are some comments:

Section 2 says "Use of the term "network byte order" in the payload format shall be as defined in RFC 791" but there is no definition of "network byte order" in RFC 791.
I suggest saying "The data transmission order SHALL be as defined in  RFC 791 Appenix B" and removing all references to "network byte order".

Section 2.1, "Line_Number" gives specifications for SD and HD but not for UHD.  We need to say whether it is line number in UHD image or line number in the sub-image of the interface mapping.

Section 2.1 "Horizontal_Offset" gives specifications for SD and HD but not for UHD.  Presumably the offset is in the sub-image of the interface mapping but we need to make that clear.

Section 2.1 "StreamNum" doesn't give enough information about numbering of the data streams.  For example, in dual-link 3G there are 4 data streams split across two links, see ST 425-3 Figure 2.

Section 2.1 "When reconstructing an SDI signal based on this payload, it is important to place ANC data packets into the locations indicated by ..."  also needs to mention the SDI format (VPID_Code) and data stream number (StreamNum).

There are still some non-capitalised normative words:
"Multiple DID_SDID parameters may be specified"
"Required parameters"
"the required rate parameter" (I would omit "required" here.)
"Word align should" (2 instances)
"the Checksum_Word should be checked"
"Re-embedders into SDI should also double check"
"recommended timestamp clock rates"
"Optional parameters"

And some normative words in non-normative context:
"Note that some multi-stream SDI interfaces may use ..." change to "might use"
"For example, 132 shall refer to ..." change to "For example, 132 refers to ..."

Regards,
John

________________________________
From: payload [[email-masked]] on behalf of Thomas Edwards [[email-masked]]
Sent: 12 May 2017 01:26
To: [email-masked]
Subject: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

Key items:

669a710,725
...
677c733
679,689c735,737

186c186
194c194

362,366c368,399
<    reserved: 8 bits
...

522,530c547,568
...
<       LinkNumber:
...

594c633

625c656

633c664

640c679,680
<    The LinkNumber is 3.
---

826a872,874

106,107d107

133,135c133,135

325,326c330,331

328,332d332

355,356c361,362

522,530c547,568
...

539c577

541c579

546,547c584,585

607c646

645,648c685,688

715,721c763,769

724,732c772

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

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: Mon, 15 May 2017 17:56:15 +0000

I don’t see the problem – In ST 425-3 there are four data streams numbered 1-4, and Figures 1 & 2 show that data streams 1 & 2 go on 3G SDI link #1, and streams 3 & 4 go on 3G SDI link #2.

If you are concerned about the fact that the 3G SDI link itself (ST 424) also has two data streams each, that also should not matter because the ST 425-3 data streams also clearly define which of those ST 424 data streams are used (i.e. ST 425-3 data stream #3 is carried on 3G-SDI Link #2, ST 424 data stream #1).   I think it should be clear that if the VPID Code refers to “1080-line Video Payloads for Level A Mapping on a Dual-link 3 Gb/s (nominal) Serial Interface” that the stream number we are describing is from that standard, and not the stream number from ST 424.  That said, I blame SMPTE for not providing an appropriate adjective (such as “image stream number” or “link stream number”), but I think that it is perilous for IETF to invent one for them.

BTW I understand why link numbers are carried in the VPID – the goal of the VPID is to describe the video format and to help you plug the coaxial cables into the proper connector.  Once the coaxes are plugged in properly, the stream numbers follow naturally based on timing, so a VPID ANC packet does not need to be in every data stream, just on at least one per link.

If I am missing something and you have alternative suggested language, please provide it.

-Thomas

From: John Fletcher <[email-masked]>
Date: Monday, May 15, 2017 at 9:02 AM
To: Thomas Edwards <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

---

From: John Fletcher <[email-masked]>
Date: Tue, 16 May 2017 09:16:07 +0000

My concern is that there are two sets of data stream numbering in ST 425-3 Figure 2.  In each link they are numbered 1 & 2.  So the language needs to make it clear that we are numbering 1 - 4.

How about adding the following text:

Numbering of data streams is across the interface as a whole.  For example in the SMPTE ST 425-3 dual-link 3 Gb/s interface, the data streams are numbered 1 - 4 with data streams 1 and 2 on link 1 and data streams 3 and 4 on link 2.

John
________________________________
From: payload [[email-masked]] on behalf of Thomas Edwards [[email-masked]]
Sent: 15 May 2017 18:56
To: [email-masked]
Subject: Re: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

-Thomas

http://www.bbc.co.uk

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