[payload] Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
Thomas Edwards <Thomas.Edwards@fox.com> Fri, 12 May 2017 00:31 UTC
Return-Path: <Thomas.Edwards@fox.com>
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 00EA712EC8D for <payload@ietfa.amsl.com>; Thu, 11 May 2017 17:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com
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 m5GjFiXSqMOB for <payload@ietfa.amsl.com>; Thu, 11 May 2017 17:31:34 -0700 (PDT)
Received: from mx0a-00195501.pphosted.com (mx0a-00195501.pphosted.com [67.231.149.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335AB127333 for <payload@ietf.org>; Thu, 11 May 2017 17:26:29 -0700 (PDT)
Received: from pps.filterd (m0082295.ppops.net [127.0.0.1]) by mx0a-00195501.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v4C0Lv4q017946 for <payload@ietf.org>; Thu, 11 May 2017 17:26:27 -0700
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0082.outbound.protection.outlook.com [207.46.163.82]) by mx0a-00195501.pphosted.com with ESMTP id 2ad1nfr6n7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <payload@ietf.org>; Thu, 11 May 2017 17:26:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ixajro8H4/vVbiGpjHhUftt91wAsyv2yOnwcmBQ0Obc=; b=ptVT3Zs4veheIlAYBaXc0dqXPmbZrkMglD57+O2VigZMg0DmAB+XOYkzWJ05lswPLXzrfH4pemO7aZ3bB6G2N7UDeTMVJ+0OWpn++hLY42KyrYIuVuHPR4CFgTa0pjcl9dFwcgyjMSn81qqHkCLuA/M66iZkkrLVExJgTQWyiGI=
Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 00:26:24 +0000
Received: from CO1PR05MB457.namprd05.prod.outlook.com ([fe80::d838:d8c1:35d7:53f9]) by CO1PR05MB457.namprd05.prod.outlook.com ([fe80::d838:d8c1:35d7:53f9%27]) with mapi id 15.01.1084.015; Fri, 12 May 2017 00:26:23 +0000
From: Thomas Edwards <Thomas.Edwards@fox.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Significant Differences Between draft-ietf-payload-rtp-ancillary-08 and -09
Thread-Index: AQHSyrZiGvSczZmxek+HC40CeN/Tnw==
Date: Fri, 12 May 2017 00:26:23 +0000
Message-ID: <142B2248-5244-4179-8AFD-A5BF7CCD91ED@fox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fox.com;
x-originating-ip: [216.205.246.234]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 7:TUrwtReEnqpOk5trU3rPL6pVR3A9B+ecPI28DtcL01hmD7WOO8kx3lgE9eGOu44bffMy3/eceFMPZdLhUQWm+IkRTx729Z/4FzyMJFAIXu6rrJuxS6ssU4mTl7LOEa57CX1zKljpIm2QpCaiOF6PGXjEgffjAzTPE6/JJvG+w+pXCZwBYNL418KH+vv+5r9giirBjmaDNsmoOupOqOcQJ6wfjlRt11YzYCuSFY2agxt3S1s1k86MIn0xQx26aPR+eG/QpUzztidsZ8MxXScZG1vrNQMo2+YwBV6mg8lnsvEudpOoC6cNORY6cobU8p7DPuGmQ1c5pQ4UCnclltmklQ==
x-ms-office365-filtering-correlation-id: 92b1bf05-5775-4f6d-d3ce-08d498cd8549
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: <CO1PR05MB4604A91E2F8A5620C7F593094E20@CO1PR05MB460.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(50582790962513)(127952516941037)(21748063052155)(177823376758907);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703036)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CO1PR05MB460;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39860400002)(39850400002)(39450400003)(39840400002)(288314003)(3846002)(102836003)(6116002)(36756003)(2906002)(2351001)(50986999)(54356999)(189998001)(3660700001)(3280700002)(6916009)(53936002)(5250100002)(99286003)(33656002)(5640700003)(7736002)(2501003)(5660300001)(8676002)(110136004)(81166006)(66066001)(1730700003)(82746002)(38730400002)(6512007)(8936002)(6306002)(83716003)(6436002)(6486002)(54896002)(53946003)(478600001)(6506006)(86362001)(25786009)(2900100001)(72206003)(230783001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB457.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_142B2248524441798AFDA5BF7CCD91EDfoxcom_"
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 00:26:23.5878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-11_20:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705120005
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Ek_44guZPRC19B_eCe6BFLa5PiU>
Subject: [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: Fri, 12 May 2017 00:31:40 -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 <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
- [payload] Significant Differences Between draft-i… Thomas Edwards
- Re: [payload] Significant Differences Between dra… John Fletcher
- Re: [payload] Significant Differences Between dra… Thomas Edwards
- Re: [payload] Significant Differences Between dra… John Fletcher
- Re: [payload] Significant Differences Between dra… Thomas Edwards
- Re: [payload] Significant Differences Between dra… Thomas Edwards
- Re: [payload] Significant Differences Between dra… Thomas Edwards
- Re: [payload] Significant Differences Between dra… John Fletcher
- Re: [payload] Significant Differences Between dra… John Fletcher