idnits 2.17.1 draft-ietf-payload-rtp-ancillary-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2016) is 2802 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BT1120' -- Possible downref: Non-RFC (?) normative reference: ref. 'BT1700' -- Possible downref: Non-RFC (?) normative reference: ref. 'ST291' -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 A/V Transport Payloads Working Group T. Edwards 3 Internet-Draft FOX 4 Intended status: Standards Track July 27, 2016 5 Expires: January 28, 2017 7 RTP Payload for SMPTE ST 291 Ancillary Data 8 draft-ietf-payload-rtp-ancillary-04 10 Abstract 12 This memo describes an RTP Payload format for SMPTE Ancillary data, 13 as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used 14 along with professional video formats to carry a range of ancillary 15 data types, including time code, Closed Captioning, and the Active 16 Format Description (AFD). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 28, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 3 55 2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5 56 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 57 3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 58 3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 9 59 3.2.1. Grouping ANC data RTP Streams with Associated Video 60 Streams . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.3. Offer/Answer Model and Declarative Considerations . . . . 11 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 6.2. Informative References . . . . . . . . . . . . . . . . . 13 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Introduction 71 This memo describes an RTP Payload format for the Society of Motion 72 Picture and Television Engineers (SMPTE) Ancillary data (ANC), as 73 defined by SMPTE ST 291-1 [ST291]. ANC can carry a range of data 74 types, including time code, Closed Captioning, and the Active Format 75 Description (AFD). 77 ANC is generally associated with the carriage of metadata within the 78 bit stream of a Serial Digital Interface (SDI) such as SMPTE ST 259 79 [ST259], the standard definition (SD) Serial Digital Interface (with 80 ANC data inserted as per SMPTE ST 125 [ST125]), or SMPTE ST 292-1 81 [ST292], the 1.5 Gb/s Serial Digital Interface for high definition 82 (HD) television applications. 84 ANC data packet payload definitions for a specific application are 85 specified by a SMPTE Standard, Recommended Practice, Registered 86 Disclosure Document, or by a document generated by another 87 organization, a company, or an individual (an Entity). When a 88 payload format is registered with SMPTE, an application document 89 describing the payload format is required, and the registered 90 ancillary data packet is identified by a registered data 91 identification word. 93 This memo describes an RTP payload that supports ANC data packets 94 regardless of whether they originate from an SD or HD interface, or 95 if the ANC data packet is from the vertical ancillary space (VANC) or 96 the horizontal ancillary space (HANC), or if the ANC packet is 97 located in the luma (Y) or color-difference (C) channel. Sufficient 98 information is provided to enable the ANC data packets at the output 99 of the decoder to be restored to their original locations in the 100 serial digital video signal raster (if that is desired). 102 It should be noted that the ancillary data flag (ADF) word is not 103 specifically carried in this RTP payload. The ADF may be specified 104 in a document defining an interconnecting digital video interface, 105 otherwise a default ADF is specified by SMPTE ST 291-1 [ST291]. 107 This ANC payload can be used by itself, or used along with a range of 108 RTP video formats. In particular, it has been designed so that it 109 could be used along with RFC 4175 [RFC4175] "RTP Payload Format for 110 Uncompressed Video" or RFC 5371 [RFC5371] "RTP Payload Format for 111 JPEG 2000 Video Streams." 113 The data model in this document for the ANC data RTP payload is based 114 on the data model of SMPTE ST 2038 [ST2038], which standardizes the 115 carriage of ANC data packets in an MPEG-2 Transport Stream. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. RTP Payload Format for SMPTE ST 291 Ancillary Data 125 The format of an RTP packet containing SMPTE ST 291 Ancillary Data is 126 shown below: 128 0 1 2 3 129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |V=2|P|X| CC |M| PT | sequence number | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | timestamp | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | synchronization source (SSRC) identifier | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Extended Sequence Number | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | ANC_Count |C| Line_Number | Horizontal_Offset | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | DID | SDID | Data_Count | R | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | User_Data_Words... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Checksum_Word | word_align | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | (next ANC data packet)... 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: SMPTE Ancillary Data RTP Packet Format 152 RTP packet header fields SHALL be interpreted as per RFC 3550 153 [RFC3550], with the following specifics: 155 Timestamp: 32 bits 156 The timestamp field is interpreted in a similar fashion to 157 RFC 4175 [RFC4175]: 159 For progressive scan video, the timestamp SHALL denote the 160 sampling instant of the frame to which the ancillary data in 161 the RTP packet belongs. RTP packets MUST NOT include ANC 162 data from multiple frames, and all RTP packets with ANC data 163 belonging to the same frame MUST have the same timestamp. 165 For interlaced video, the timestamp SHALL denote the sampling 166 instant of the field to which the ancillary data in the RTP 167 packet belongs. RTP packets MUST NOT include ANC data from 168 multiple fields, and all RTP packets belonging to the same 169 field MUST have the same timestamp. 171 If the sampling instant does not correspond to an integer 172 value of the clock, the value SHALL be truncated to the next 173 lowest integer, with no ambiguity. Section 3.1 describes 174 recommended timestamp clock rates. 176 Marker bit (M): 1 bit 177 The marker bit set to "1" SHALL indicate the last ANC RTP 178 packet for a frame (for progressive scan video) or the last 179 ANC RTP packet for a field (for interlaced video). 181 2.1. Payload Header Definitions 183 The ANC RTP payload header fields are defined as: 185 Extended Sequence Number: 16 bits 186 The high order bits of the extended 32-bit sequence number, 187 in network byte order. This is the same as the Extended 188 Sequence Number field in RFC 4175 [RFC4175]. 190 Length: 16 bits 191 Number of octets of the ANC RTP payload, beginning with the 192 "C" bit of the first ANC packet data. 194 ANC_Count: 8 bits 195 This field is the count of the total number of ANC data 196 packets carried in the RTP payload. A single ANC RTP packet 197 payload SHALL NOT carry more than 255 ANC data packets. 198 If more than 255 ANC data packets need to be carried in a 199 field or frame, additional RTP packets carrying ANC data may 200 be sent with the same RTP timestamp but with different 201 sequence numbers. ANC_Count of 0 SHALL indicate that there 202 are no ANC data packets in the payload (for example, for an 203 RTP packet with the marker bit set indicating the last ANC 204 RTP packet in a field/frame, even if that RTP packet carries 205 no actual ANC data packets.) 207 For each ANC data packet in the payload, the following ANC data 208 packet header fields MUST be present: 210 C: 1 bit 211 For HD signals, this flag, when set to "1", indicates that 212 the ANC data corresponds to the color-difference channel (C). 213 When set to "0", this flag indicates that the ANC data 214 corresponds to the luma (Y) channel. For SD signals, this 215 flag SHALL be set to "0". 217 Line_Number: 11 bits 218 This field contains the line number (as defined in ITU-R 219 BT.1700 [BT1700] for SD video or ITU-R BT.1120 [BT1120] for 220 HD video) that corresponds to the location of the ANC data 221 packet in an SDI raster. A value of 0x7FF (all bits in the 222 field are '1') SHALL indicate that the ANC data is carried 223 without a specific line location within the field or frame. 225 Note that the lines that are available to convey ANC data are 226 as defined in the applicable sample structure specification 227 (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656 228 [BT656]) and may be further restricted per SMPTE RP 168 229 [RP168]. 231 Horizontal_Offset: 12 bits 232 This field defines the location of the ANC data packet in an 233 SDI raster relative to the start of active video (SAV). A 234 value of 0 means that the Ancillary Data Flag (ADF) of the 235 ANC data packet begins immediately following SAV. For HD, 236 this SHALL be in units of luma sample numbers as specified by 237 the defining document of the particular image (e.g., SMPTE 238 274M [ST274] for 1920 x 1080 active images, or SMPTE ST 296 239 [ST296] for 1280 x 720 progressive active images). For SD, 240 this SHALL be in units of (27MHz) multiplexed word numbers, 241 as specified in SMPTE ST 125 [ST125]. A value of 0xFFF (all 242 bits in the field are '1') SHALL indicate that the ANC data 243 is carried without any specific location within the line. 245 Note that HANC space in the digital blanking area will 246 generally have higher luma sample numbers than any samples in 247 the active digital line. 249 An ANC data packet with the header fields Line_Number of 0x7FF and 250 Horizontal_Offset of 0xFFF SHALL be considered to be carried without 251 any specific location within the field or frame, and in such a case 252 the "C" field SHALL be ignored. 254 For each ANC data packet in the payload, immediately after the ANC 255 data packet header fields, the following data fields MUST be present, 256 with the fields DID, SDID, Data_Count, User_Data_Words, and 257 Checksum_Word representing the 10-bit words carried in the ANC data 258 packet, as per SMPTE ST 291-1 [ST291]: 260 DID: 10 bits 261 Data Identification Word 263 SDID: 10 bits 264 Secondary Data Identification Word. Used only for a "Type 2" 265 ANC data packet. Note that in a "Type 1" ANC data packet, 266 this word will actually carry the Data Block Number (DBN). 268 Data_Count: 10 bits 269 The lower 8 bits of Data_Count, corresponding to bits b7 270 (MSB) through b0 (LSB) of the 10-bit Data_Count word, contain 271 the actual count of 10-bit words in User_Data_Words. Bit b8 272 is the even parity for bits b7 through b0, and bit b9 is the 273 inverse (logical NOT) of bit b8. 275 R: 2 reserved bits 276 R is a field of two reserved bits that MUST be set to zero. 278 User_Data_Words: integer number of 10 bit words 279 User_Data_Words (UDW) are used to convey information of a 280 type as identified by the DID word or the DID and SDID words. 281 The number of 10-bit words in the UDW is defined by the 282 Data_Count field. 284 Checksum_Word: 10 bits 285 The Checksum_Word can be used to determine the validity of 286 the ANC data packet from the DID word through the UDW. It 287 consists of 10 bits, where bits b8 (MSB) through b0 (LSB) 288 define the checksum value and bit b9 is the inverse (logical 289 NOT) of bit b8. The checksum value is equal to the nine 290 least significant bits of the sum of the nine least 291 significant bits of the DID word, the SDID word, the 292 Data_Count word, and all User_Data_Words in the ANC data 293 packet. The checksum is initialized to zero before 294 calculation, and any end carry resulting from the checksum 295 calculation is ignored. 297 word_align: bits as needed to complete 32-bit word 298 Word align contains enough "0" bits as needed to complete the 299 last 32-bit word of ANC packet's data in the RTP payload. If 300 an ANC data packet in the RTP payload ends aligned with a 301 word boundary, there is no need to add any word alignment 302 bits. Word align should be used even for the last ANC data 303 packet in an RTP packet. 305 When reconstructing an SDI signal based on this payload, it is 306 important to place ANC data packets into the locations indicated by 307 the ANC payload header fields Line_Number and Horizontal_Offset, and 308 also to follow the requirements of SMPTE ST 291-1 [ST291] Section 7 309 "Ancillary Data Space Formatting (Component or Composite Interface)", 310 which include rules on the placement of initial ANC data into allowed 311 spaces as well as the contiguity of ANC data packet sequences within 312 those spaces in order to assure that the resulting ANC data packets 313 in the SDI signal are valid. 315 Senders of this payload SHOULD transmit available ANC data packets as 316 soon as practical to reduce end-to-end latency, especially if 317 receivers will be embedding the received ANC data packet into an SDI 318 signal emission. One millisecond is a reasonable upper bound for the 319 amount of time between when an ANC data packet becomes available to a 320 sender and the emission of an RTP payload containing that ANC data 321 packet. 323 ANC data packets with headers that specify specific location within a 324 field or frame SHOULD be sent in raster scan order, both in terms of 325 packing position within an RTP packet and in terms of transmission 326 time of RTP packets. 328 3. Payload Format Parameters 330 This RTP payload format is identified using the video/smpte291 media 331 type, which is registered in accordance with RFC 4855 [RFC4855], and 332 using the template of RFC 6838 [RFC6838]. 334 Note that the Media Type Definition is in the "video" tree due to the 335 expected use of SMPTE ST 291 Ancillary Data along with video formats. 337 3.1. Media Type Definition 339 Type name: video 341 Subtype name: smpte291 343 Required parameters: 345 Rate: RTP timestamp clock rate. When an ANC RTP stream is to be 346 associated with an RTP video stream, the RTP timestamp rates 347 SHOULD be the same to ensure that ANC data packets can be 348 associated with the appropriate frame or field. Otherwise, a 90 349 kHz rate SHOULD be used. 351 Optional parameters: 353 DID_SDID: Data identification and Secondary data identification 354 words. 356 The presence of the DID_SDID parameters signals that all ancillary 357 data packets of this stream are of a particular type or types, 358 i.e., labeled with a particular DIDs and SDIDs. DID and SDID 359 values of SMPTE Registered ANC packet types can be found on the 360 SMPTE Registry for Data Identification Word Assignments at: 362 http://www.smpte-ra.org/smpte-ancillary-data-smpte-st-291 364 "Type 1" ANC packets (which do not have SDIDs defined) SHALL be 365 labeled with SDID=0x00. 367 DID and SDID values can be registered with SMPTE as per SMPTE ST 368 291-1 [ST291]. 370 Encoding considerations: This media type is framed and binary; see 371 Section 4.8 of RFC 6838 [RFC6838]. 373 Security considerations: See Section 5 of [this RFC] 375 Interoperability considerations: Data items in smpte291 can be very 376 diverse. Receivers might only be capable of interpreting a subset of 377 the possible data items. Some implementations may care about the 378 location of the ANC data packets in the SDI raster, but other 379 implementations may not care. 381 Published specification: [this RFC] 383 Applications that use this media type: Devices that stream real-time 384 professional video, especially those that must interoperate with 385 legacy serial digital interfaces (SDI). 387 Additional Information: none 389 Person & email address to contact for further information: T. 390 Edwards , IETF Payload Working Group 391 393 Intended usage: COMMON 395 Restrictions on usage: This media type depends on RTP framing, and 396 hence is only defined for transfer via RTP RFC 3550 [RFC3550]. 397 Transport within other framing protocols is not defined at this time. 399 Author: T. Edwards 401 Change controller: IETF Audio/Video Transport Payloads working group 402 delegated from the IESG. 404 3.2. Mapping to SDP 406 The mapping of the above defined payload format media type and its 407 parameters SHALL be done according to Section 3 of RFC 4855 408 [RFC4855]. 410 o The type name ("video") goes in SDP "m=" as the media name. 412 o The subtype name ("smpte291") goes in SDP "a=rtpmap" as the 413 encoding name. 415 o The optional DID_SDID parameters go in the SDP "a=fmtp" attribute 416 as a semicolon-separated list of parameter=value pairs. 418 DID and SDID values SHALL be specified in hexadecimal with a "0x" 419 prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the 420 fmtp line shall be: 422 TwoHex = "0x" 1*2(HEXDIG) 423 DidSdid = "DID_SDID={" TwoHex "," TwoHex "}" 424 FormatSpecificParameters = DidSdid *(";" DidSdid) 426 For example, EIA 608 Closed Caption data would be signalled with the 427 parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not 428 specified, then the ancillary data stream may potentially contain 429 ancillary data packets of any type. 431 Multiple DID_SDID parameters may be specified (separated by 432 semicolons) to signal the presence of multiple types of ANC data in 433 the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example, 434 signals the presence of EIA 608 Closed Captions as well as AFD/Bar 435 Data. 437 A sample SDP mapping for ancillary data is as follows: 439 m=video 30000 RTP/AVP 112 440 a=rtpmap:112 smpte291/90000 441 a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05} 443 In this example, a dynamic payload type 112 is used for ancillary 444 data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" 445 line after the subtype. The RTP sampling clock is 90 kHz. In the 446 "a=fmtp:" line, DID 0x61 and SDID 0x02 are specified (registered to 447 EIA 608 Closed Caption Data by SMPTE), and also DID 0x41 and SDID 448 0x05 (registered to AFD/Bar Data). 450 3.2.1. Grouping ANC data RTP Streams with Associated Video Streams 452 The ANC RTP payload format will often be used in groupings with 453 associated video essence streams. Any legal SDP grouping mechanism 454 could be used. Implementers may wish to use the Lip Synchronization 455 (LS) grouping defined in RFC 5888 [RFC5888], which requires that "m" 456 lines that are grouped together using LS semantics MUST synchronize 457 the playout of the corresponding media streams. 459 A sample SDP mapping for grouping ANC data with RFC 4175 video using 460 LS semantics is as follows: 462 v=0 463 o=Al 123456 11 IN IP4 host.example.com 464 s=Professional Networked Media Test 465 i=A test of synchronized video and ANC data 466 t=0 0 467 a=group:LS V1 M1 468 m=video 50000 RTP/AVP 96 469 c=IN IP4 239.1.1.1/32 470 a=rtpmap:96 raw/90000 471 a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10 472 a=mid:V1 473 m=video 50010 RTP/AVP 97 474 c=IN IP4 239.1.1.2/32 475 a=rtpmap:97 smpte291/90000 476 a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05} 477 a=mid:M1 479 3.3. Offer/Answer Model and Declarative Considerations 481 Receivers may with to receive ANC data streams with specific DID_SDID 482 parameters. Thus when offering ANC data streams using the Session 483 Description Protocol (SDP) in an Offer/Answer model [RFC3264] or in a 484 declarative manner (e.g., SDP in the Real-Time Streaming Protocol 485 (RTSP) [RFC2326] or the Session Announcement Protocol (SAP) 486 [RFC2974]), the offerer may provide a list of ANC streams available 487 with specific DID_SDID parameters in the fmtp line. The answerer may 488 respond with a all or a subset of the streams offered along with fmtp 489 lines with all or a subset of the DID_SDID parameters offered. Or 490 the answerer may reject the offer. 492 4. IANA Considerations 494 One media type (video/smpte291) has been defined and needs 495 registration in the media types registry. See Section 3.1 497 5. Security Considerations 499 RTP packets using the payload format defined in this specification 500 are subject to the security considerations discussed in the RTP 501 specification [RFC3550] and any applicable RTP profile, e.g., AVP 502 [RFC3551]. 504 To avoid potential buffer overflow attacks, receivers should take 505 care to validate that the ANC data packets in the RTP payload are of 506 the appropriate length (using the Data_Count field) for the ANC data 507 type specified by DID & SDID. Also the Checksum_Word should be 508 checked against the ANC data packet to ensure that its data has not 509 been damaged in transit. 511 Some receivers will simply move the ANC data packet bits from the RTP 512 payload into a serial digital interface (SDI). It may still be a 513 good idea for these "re-embedders" to perform the above mentioned 514 validity tests to avoid downstream SDI systems from becoming confused 515 by bad ANC data packets, which could be used for a denial of service 516 attack. 518 "Re-embedders" into SDI should also double check that the Line_Number 519 and Horizontal_Offset leads to the ANC data packet being inserted 520 into a legal area to carry ancillary data in the SDI video bit stream 521 of the output video format. 523 6. References 525 6.1. Normative References 527 [BT1120] ITU-R, "BT.1120-8, Digital Interfaces for HDTV Studio 528 Signals", January 2012. 530 [BT1700] ITU-R, "BT.1700, Characteristics of Composite Video 531 Signals for Conventional Analogue Television Systems", 532 February 2005. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 540 Jacobson, "RTP: A Transport Protocol for Real-Time 541 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 542 July 2003, . 544 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 545 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 546 . 548 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 549 Specifications: ABNF", STD 68, RFC 5234, 550 DOI 10.17487/RFC5234, January 2008, 551 . 553 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 554 Specifications and Registration Procedures", BCP 13, 555 RFC 6838, DOI 10.17487/RFC6838, January 2013, 556 . 558 [ST291] SMPTE, "ST 291-1:2011, Ancillary Data Packet and Space 559 Formatting", 2011. 561 6.2. Informative References 563 [BT656] ITU-R, "BT.656-5, Interfaces for Digital Component Video 564 Signals in 525-Line and 625-Line Television Systems 565 Operating at the 4:2:2 Level of Recommendation ITU-R 566 BT.601", December 2007. 568 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 569 Streaming Protocol (RTSP)", RFC 2326, 570 DOI 10.17487/RFC2326, April 1998, 571 . 573 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 574 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 575 October 2000, . 577 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 578 with Session Description Protocol (SDP)", RFC 3264, 579 DOI 10.17487/RFC3264, June 2002, 580 . 582 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 583 Video Conferences with Minimal Control", STD 65, RFC 3551, 584 DOI 10.17487/RFC3551, July 2003, 585 . 587 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 588 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 589 September 2005, . 591 [RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload 592 Format for JPEG 2000 Video Streams", RFC 5371, 593 DOI 10.17487/RFC5371, October 2008, 594 . 596 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 597 Protocol (SDP) Grouping Framework", RFC 5888, 598 DOI 10.17487/RFC5888, June 2010, 599 . 601 [RP168] SMPTE, "RP 168:2009, Definition of Vertical Interval 602 Switching Point for Synchronous Video Switching", 2009. 604 [ST125] SMPTE, "ST 125:2013, SDTV Component Video Signal Coding 605 4:4:4 and 4:2:2 for 13.5 MHz and 18 MHz Systems", 2013. 607 [ST2038] SMPTE, "ST 2038:2008, Carriage of Ancillary Data Packets 608 in an MPEG-2 Transport Stream", 2008. 610 [ST259] SMPTE, "ST 259:2008, SDTV Digital Signal/Data - Serial 611 Digital Interface", 2008. 613 [ST274] SMPTE, "ST 274:2008, 1920 x 1080 Image Sample Structure, 614 Digital Representation and Digital Timing Reference 615 Sequences for Multiple Picture Rates", 2008. 617 [ST292] SMPTE, "ST 292-1:2012, 1.5 Gb/s Signal/Data Serial 618 Interface", 2012. 620 [ST296] SMPTE, "ST 296:2012, 1280 x 720 Progressive Image 4:2:2 621 and 4:4:4 Sample Structure - Analog and Digital 622 Representation and Analog Interface", 2012. 624 Author's Address 626 Thomas G. Edwards 627 FOX 628 10201 W. Pico Blvd. 629 Los Angeles, CA 90035 630 USA 632 Phone: +1 310 369 6696 633 Email: thomas.edwards@fox.com