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

John Fletcher <John.Fletcher@bbc.co.uk> Mon, 15 May 2017 16:06 UTC

Return-Path: <John.Fletcher@bbc.co.uk>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CD21294F0 for <payload@ietfa.amsl.com>; Mon, 15 May 2017 09:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4H028N36_HB for <payload@ietfa.amsl.com>; Mon, 15 May 2017 09:06:28 -0700 (PDT)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78BF1298BA for <payload@ietf.org>; Mon, 15 May 2017 09:02:24 -0700 (PDT)
Received: from BGB01XI1002.national.core.bbc.co.uk ([10.184.50.52]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v4FG2H5E017178; Mon, 15 May 2017 17:02:17 +0100 (BST)
Received: from BGB01XUD1011.national.core.bbc.co.uk ([10.161.14.9]) by BGB01XI1002.national.core.bbc.co.uk ([10.184.50.52]) with mapi id 14.03.0319.002; Mon, 15 May 2017 17:02:17 +0100
From: John Fletcher <John.Fletcher@bbc.co.uk>
To: Thomas Edwards <Thomas.Edwards@fox.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
Thread-Index: AQHSyrZiGvSczZmxek+HC40CeN/Tn6H1hE3o
Date: Mon, 15 May 2017 16:02:16 +0000
Message-ID: <B1D49063AD5FBD4688F3EEDEC68B2017C3833979@bgb01xud1011>
References: <142B2248-5244-4179-8AFD-A5BF7CCD91ED@fox.com>
In-Reply-To: <142B2248-5244-4179-8AFD-A5BF7CCD91ED@fox.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-23072.000
x-tm-as-result: No--14.861200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B1D49063AD5FBD4688F3EEDEC68B2017C3833979bgb01xud1011_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/d9vx3-ok_TuSaAdfi5VlAi2vSgg>
Subject: Re: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 16:06:32 -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 [payload-bounces@ietf.org] on behalf of Thomas Edwards [Thomas.Edwards@fox.com]
Sent: 12 May 2017 01:26
To: payload@ietf.org
Subject: [payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09

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 <oftedal@gmail.com> 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 <roni.even@huawei.com> 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 <John.Fletcher@bbc.co.uk> 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 <John.Fletcher@bbc.co.uk> 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
thomas.edwards@fox.com
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035



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

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.

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