< draft-ietf-payload-rtp-ancillary-09.txt   draft-ietf-payload-rtp-ancillary-10.txt >
A/V Transport Payloads Working Group T. Edwards A/V Transport Payloads Working Group T. Edwards
Internet-Draft FOX Internet-Draft FOX
Intended status: Standards Track May 11, 2017 Intended status: Standards Track June 15, 2017
Expires: November 12, 2017 Expires: December 17, 2017
RTP Payload for SMPTE ST 291 Ancillary Data RTP Payload for SMPTE ST 291 Ancillary Data
draft-ietf-payload-rtp-ancillary-09 draft-ietf-payload-rtp-ancillary-10
Abstract Abstract
This memo describes a real-time transport protocol (RTP) payload This memo describes a real-time transport protocol (RTP) payload
format for the Society of Motion Picture and Television Engineers format for the Society of Motion Picture and Television Engineers
(SMPTE) Ancillary data, as defined by SMPTE ST 291-1. SMPTE (SMPTE) Ancillary data, as defined by SMPTE ST 291-1. SMPTE
Ancillary data is generally used along with professional video Ancillary data is generally used along with professional video
formats to carry a range of ancillary data types, including time formats to carry a range of ancillary data types, including time
code, Closed Captioning, and the Active Format Description (AFD). code, Closed Captioning, and the Active Format Description (AFD).
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2017. This Internet-Draft will expire on December 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 3 2. RTP Payload Format for SMPTE ST 291 Ancillary Data . . . . . 3
2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5 2.1. Payload Header Definitions . . . . . . . . . . . . . . . 5
3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 9 3. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10
3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 10 3.1. Media Type Definition . . . . . . . . . . . . . . . . . . 10
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 12
4.1. Grouping ANC Streams with other Media Streams . . . . . . 13 4.1. Grouping ANC Streams with other Media Streams . . . . . . 13
5. Offer/Answer Model and Declarative Considerations . . . . . . 13 5. Offer/Answer Model and Declarative Considerations . . . . . . 14
5.1. Offer/Answer Model . . . . . . . . . . . . . . . . . . . 13 5.1. Offer/Answer Model . . . . . . . . . . . . . . . . . . . 14
5.2. Declarative SDP Considerations . . . . . . . . . . . . . 14 5.2. Declarative SDP Considerations . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This memo describes a real-time transport protocol (RTP) payload This memo describes a real-time transport protocol (RTP) payload
format for the Society of Motion Picture and Television Engineers format for the Society of Motion Picture and Television Engineers
(SMPTE) Ancillary data (ANC), as defined by SMPTE ST 291-1 [ST291]. (SMPTE) Ancillary data (ANC), as defined by SMPTE ST 291-1 [ST291].
ANC data is transmitted in the ancillary space of serial digital ANC data is transmitted in the ancillary space of serial digital
video interfaces, the space outside of the active video region of video interfaces, the space outside of the active video region of
images intended for users to view. Ancillary space roughly images intended for users to view. Ancillary space roughly
skipping to change at page 4, line 41 skipping to change at page 4, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum_Word |word_align | | Checksum_Word |word_align |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SMPTE Ancillary Data RTP Packet Format Figure 1: SMPTE Ancillary Data RTP Packet Format
In this example, two ANC data packets are present. The first has In this example, two ANC data packets are present. The first has
four 10-bit User Data Words, and the second has five 10-bit User Data four 10-bit User Data Words, and the second has five 10-bit User Data
Words. Words.
Use of the term "network byte order" in the payload format shall be The term "network byte order" in the payload format SHALL refer to
as defined in RFC 791 [RFC0791]. the Data Transmission Order as defined in Appendix B of RFC 791
[RFC0791].
RTP packet header fields SHALL be interpreted as per RFC 3550 RTP packet header fields SHALL be interpreted as per RFC 3550
[RFC3550], with the following specifics: [RFC3550], with the following specifics:
Timestamp: 32 bits Timestamp: 32 bits
The timestamp field is interpreted in a similar fashion to The timestamp field is interpreted in a similar fashion to
RFC 4175 [RFC4175]: RFC 4175 [RFC4175]:
For progressive scan video, the timestamp denotes the For progressive scan video, the timestamp denotes the
sampling instant of the frame to which the ancillary data in sampling instant of the frame to which the ancillary data in
skipping to change at page 5, line 17 skipping to change at page 5, line 20
For interlaced video, the timestamp denotes the sampling For interlaced video, the timestamp denotes the sampling
instant of the field to which the ancillary data in the RTP instant of the field to which the ancillary data in the RTP
packet belongs. RTP packets MUST NOT include ANC data from packet belongs. RTP packets MUST NOT include ANC data from
multiple fields, and all RTP packets belonging to the same multiple fields, and all RTP packets belonging to the same
field MUST have the same timestamp. field MUST have the same timestamp.
If the sampling instant does not correspond to an integer If the sampling instant does not correspond to an integer
value of the clock, the value SHALL be truncated to the next value of the clock, the value SHALL be truncated to the next
lowest integer, with no ambiguity. Section 3.1 describes lowest integer, with no ambiguity. Section 3.1 describes
recommended timestamp clock rates. timestamp clock rates.
Marker bit (M): 1 bit Marker bit (M): 1 bit
The marker bit set to "1" indicates the last ANC RTP packet The marker bit set to "1" indicates the last ANC RTP packet
for a frame (for progressive scan video) or the last ANC RTP for a frame (for progressive scan video) or the last ANC RTP
packet for a field (for interlaced video). packet for a field (for interlaced video).
2.1. Payload Header Definitions 2.1. Payload Header Definitions
The ANC RTP payload header fields are defined as: The ANC RTP payload header fields are defined as:
skipping to change at page 6, line 17 skipping to change at page 6, line 19
F: 2 bits F: 2 bits
These two bits relate to signaling the field specified by the These two bits relate to signaling the field specified by the
RTP timestamp in an interlaced SDI raster. A value of 0b00 RTP timestamp in an interlaced SDI raster. A value of 0b00
indicates that either the video format is progressive or that indicates that either the video format is progressive or that
no field is specified. A value of 0b10 indicates that the no field is specified. A value of 0b10 indicates that the
timestamp refers to the first field of an interlaced video timestamp refers to the first field of an interlaced video
signal. A value of 0b11 indicates that the timestamp refers signal. A value of 0b11 indicates that the timestamp refers
to the second field of an interlaced video signal. The value to the second field of an interlaced video signal. The value
0b01 is not valid. 0b01 is not valid.
Note that some multi-stream SDI interfaces may use multiple Note that some multi-stream SDI interfaces might use multiple
interlaced signal streams to transmit progressive images, in interlaced signal streams to transmit progressive images, in
which case the "F" bits would refer to the field of the which case the "F" bits would refer to the field of the
interlaced stream used for transport of the ANC data packet. interlaced stream used for transport of the ANC data packet.
reserved: 22 bits reserved: 22 bits
The 22 reserved bits of value "0" follow the F field to The 22 reserved bits of value "0" follow the F field to
ensure that the first ANC data packet header field in the ensure that the first ANC data packet header field in the
payload begins 32-bit word-aligned to ease implementation. payload begins 32-bit word-aligned to ease implementation.
For each ANC data packet in the payload, the following ANC data For each ANC data packet in the payload, the following ANC data
packet header fields MUST be present: packet header fields MUST be present:
C: 1 bit C: 1 bit
This flag, when set to "1", indicates that the ANC data This flag, when set to "1", indicates that the ANC data
corresponds to the color-difference data channel (C). When corresponds to the color-difference data channel (C). When
set to "0", this flag indicates either that the ANC data set to "0", this flag indicates either that the ANC data
corresponds to the luma (Y) data channel, 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 source is from an SD signal, or that the ANC data source has
no specific luma or color-difference data channels. However, no specific luma or color-difference data channels. For ANC
if the ANC data type definition specifically requires the use data from a multi-stream interface source, the C flag SHALL
of the C or Y data channel, the C flag SHALL reflect that refer to the channel of the stream used to transport the ANC
packet. For situations where there is no SDI source, if the
ANC data type definition specifically requires the use of the
C or Y data channel, the C flag SHALL reflect that
requirement. requirement.
Line_Number: 11 bits Line_Number: 11 bits
This field contains the line number (as defined in ITU-R This field contains the line number (as defined in ITU-R
BT.1700 [BT1700] for SD video or ITU-R BT.1120 [BT1120] for BT.1700 [BT1700] for SD video or ITU-R BT.1120 [BT1120] for
HD video) that corresponds to the location of the ANC data HD video) that corresponds to the location of the ANC data
packet in an SDI raster as an unsigned integer in network packet in an SDI raster as an unsigned integer in network
byte order. A value of 0x7FF (all bits in the field are '1') byte order. A value of 0x7FF (all bits in the field are '1')
indicates that the ANC data is carried without a specific indicates that the ANC data is carried without a specific
line location within the field or frame. A value of 0x7FE line location within the field or frame. A value of 0x7FE
indicates that the ANC data is intended to be placed into any indicates that the ANC data is intended to be placed into any
legal area of VANC, specifically. legal area of VANC, specifically.
Note that the lines that are available to convey ANC data are Note that the lines that are available to convey ANC data are
as defined in the applicable sample structure specification as defined in the applicable sample structure specification
(e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656 (e.g., SMPTE 274M [ST274], SMPTE ST 296 [ST296], ITU-R BT.656
[BT656]) and possibly further restricted per SMPTE RP 168 [BT656]) and possibly further restricted per SMPTE RP 168
[RP168]. [RP168].
In multi-stream interfaces, this field refers to the line
number that an ANC packet is carried on within a particular
data stream in the interface.
Horizontal_Offset: 12 bits Horizontal_Offset: 12 bits
This field defines the location of the ANC data packet in an This field defines the location of the ANC data packet in an
SDI raster relative to the start of active video (SAV) as an SDI raster relative to the start of active video (SAV) as an
unsigned integer in network byte order. A value of 0 means unsigned integer in network byte order. A value of 0 means
that the Ancillary Data Flag (ADF) of the ANC data packet that the Ancillary Data Flag (ADF) of the ANC data packet
begins immediately following SAV. For HD, this is in units begins immediately following SAV. For HD, this is in units
of luma sample numbers as specified by the defining document of luma sample numbers as specified by the defining document
of the particular image (e.g., SMPTE 274M [ST274] for 1920 x of the particular image (e.g., SMPTE 274M [ST274] for 1920 x
1080 active images, or SMPTE ST 296 [ST296] for 1280 x 720 1080 active images, or SMPTE ST 296 [ST296] for 1280 x 720
progressive active images). For SD, this is in units of progressive active images). For SD, this is in units of
(27MHz) multiplexed word numbers, as specified in SMPTE ST (27MHz) multiplexed word numbers, as specified in SMPTE ST
125 [ST125]. A value of 0xFFF (all bits in the field are 125 [ST125]. A value of 0xFFF (all bits in the field are
'1') indicates that the ANC data is carried without any '1') indicates that the ANC data is carried without any
specific location within the line. A value of 0xFFE specific location within the line. A value of 0xFFE
indicates that the ANC data is intended to be placed into any indicates that the ANC data is intended to be placed into any
legal area of HANC, specifically. legal area of HANC, specifically.
In multi-stream interfaces, this field refers to the
horizontal location where an ANC packet is placed on a line
carried within a particular data stream in the interface.
Note that HANC space in the digital blanking area will Note that HANC space in the digital blanking area will
generally have higher luma sample numbers than any samples in generally have higher luma sample numbers than any samples in
the active digital line. the active digital line.
S (Data Stream Flag): 1 bit S (Data Stream Flag): 1 bit
This field indicates whether the data stream number of a This field indicates whether the data stream number of a
multi-stream data mapping used to transport the ANC data multi-stream data mapping used to transport the ANC data
packet is specified. If the S bit is '0', then the StreamNum packet is specified. If the S bit is '0', then the StreamNum
field provides no guidance regarding the source data stream field provides no guidance regarding the source data stream
number of the ANC data packet. If the S bit is '1', then the number of the ANC data packet. If the S bit is '1', then the
skipping to change at page 8, line 7 skipping to change at page 8, line 20
the source data stream minus one. If the source multi-stream the source data stream minus one. If the source multi-stream
interface does not have numbered data streams, the following interface does not have numbered data streams, the following
numbers SHALL be used in this field: '0' for link A data numbers SHALL be used in this field: '0' for link A data
stream, '1' for link B data stream. For stereoscopic multi- stream, '1' for link B data stream. For stereoscopic multi-
stream interface formats that do not have numbered streams, stream interface formats that do not have numbered streams,
the following numbers SHALL be used in this field: '0' for the following numbers SHALL be used in this field: '0' for
left eye stream, '1' for right eye stream. left eye stream, '1' for right eye stream.
Note that in multi-link SDI connections, the physical link Note that in multi-link SDI connections, the physical link
that a particular stream utilizes is typically specified by that a particular stream utilizes is typically specified by
the interface standard. the interface standard. Also note that 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.
An ANC data packet with the header fields Line_Number of 0x7FF and An ANC data packet with the header fields Line_Number of 0x7FF and
Horizontal_Offset of 0xFFF SHALL be considered to be carried without Horizontal_Offset of 0xFFF SHALL be considered to be carried without
any specific location within the field or frame. any specific location within the field or frame.
For each ANC data packet in the payload, immediately after the ANC For each ANC data packet in the payload, immediately after the ANC
data packet header fields, the following data fields MUST be present, data packet header fields, the following data fields MUST be present,
with the fields DID, SDID, Data_Count, User_Data_Words, and with the fields DID, SDID, Data_Count, User_Data_Words, and
Checksum_Word representing the 10-bit words carried in the ANC data Checksum_Word representing the 10-bit words carried in the ANC data
packet, as per SMPTE ST 291-1 [ST291]: packet, as per SMPTE ST 291-1 [ST291]:
skipping to change at page 9, line 14 skipping to change at page 9, line 31
calculation, and any end carry resulting from the checksum calculation, and any end carry resulting from the checksum
calculation is ignored. calculation is ignored.
At the end of each ANC data packet in the payload: At the end of each ANC data packet in the payload:
word_align: bits as needed to complete 32-bit word word_align: bits as needed to complete 32-bit word
Word align contains enough "0" bits as needed to complete the Word align contains enough "0" bits as needed to complete the
last 32-bit word of ANC packet's data in the RTP payload. If last 32-bit word of ANC packet's data in the RTP payload. If
an ANC data packet in the RTP payload ends aligned with a an ANC data packet in the RTP payload ends aligned with a
word boundary, there is no need to add any word alignment word boundary, there is no need to add any word alignment
bits. Word align should be used even for the last ANC data bits. Word align SHALL be used even for the last ANC data
packet in an RTP packet. Word align should not be used if packet in an RTP packet. Word align SHALL NOT be used if
there are zero ANC data packets being carried in the RTP there are zero ANC data packets being carried in the RTP
packet. packet.
When reconstructing an SDI signal based on this payload, it is When reconstructing an SDI signal based on this payload, it is
important to place ANC data packets into the locations indicated by important to place ANC data packets into the locations indicated by
the ANC payload header fields C, Line_Number and Horizontal_Offset, the ANC payload header fields C, Line_Number and Horizontal_Offset,
and also to follow the requirements of SMPTE ST 291-1 [ST291] and also to follow the requirements of SMPTE ST 291-1 [ST291]
Section 7 "Ancillary Data Space Formatting (Component or Composite Section 7 "Ancillary Data Space Formatting (Component or Composite
Interface)", which include rules on the placement of initial ANC data Interface)", which include rules on the placement of initial ANC data
into allowed spaces as well as the contiguity of ANC data packet into allowed spaces as well as the contiguity of ANC data packet
sequences within those spaces in order to assure that the resulting sequences within those spaces in order to assure that the resulting
ANC data packets in the SDI signal are valid. ANC data packets in the SDI signal are valid. The optional Media
Type parameter VPID_Code can inform receivers of the type of
originating SDI interface. For multi-stream originating interfaces,
the StreamNum field can provide information regarding which stream an
ANC data packet can be placed in to match the ANC data location in
the originating SDI interface.
Senders of this payload SHOULD transmit available ANC data packets as Senders of this payload SHOULD transmit available ANC data packets as
soon as practical to reduce end-to-end latency, especially if soon as practical to reduce end-to-end latency, especially if
receivers will be embedding the received ANC data packet into an SDI receivers will be embedding the received ANC data packet into an SDI
signal emission. One millisecond is a reasonable upper bound for the signal emission. One millisecond is a reasonable upper bound for the
amount of time between when an ANC data packet becomes available to a amount of time between when an ANC data packet becomes available to a
sender and the emission of an RTP payload containing that ANC data sender and the emission of an RTP payload containing that ANC data
packet. packet.
ANC data packets with headers that specify specific location within a ANC data packets with headers that specify specific location within a
skipping to change at page 11, line 5 skipping to change at page 11, line 29
determination of the DID and SDID of ANC packets in the payload determination of the DID and SDID of ANC packets in the payload
can only be achieved through direct inspection of the ANC data can only be achieved through direct inspection of the ANC data
packet fields. packet fields.
VPID_Code: VPID_Code:
This integer parameter specifies the Video Payload ID (VPID) This integer parameter specifies the Video Payload ID (VPID)
Code of the source interface of ANC data packets using the Code of the source interface of ANC data packets using the
value from byte 1 of the VPID as defined in SMPTE ST 352 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 [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 being the most significant bit, and bit 0 of VPID byte 1 being
the least significant bit. For example, 132 shall refer to the least significant bit. For example, 132 refers to SMPTE ST
SMPTE ST 292-1, 720-line video payloads on a 1.5 Gbps (nominal) 292-1, 720-line video payloads on a 1.5 Gbps (nominal) serial
serial digital interface. digital interface.
Encoding considerations: This media type is framed and binary; see Encoding considerations: This media type is framed and binary; see
Section 4.8 of RFC 6838 [RFC6838]. Section 4.8 of RFC 6838 [RFC6838].
Security considerations: See Section 7 of [this RFC] Security considerations: See Section 7 of [this RFC]
Interoperability considerations: Data items in smpte291 can be very Interoperability considerations: Data items in smpte291 can be very
diverse. Receivers might only be capable of interpreting a subset of diverse. Receivers might only be capable of interpreting a subset of
the possible data items. Some implementations might care about the the possible data items. Some implementations might care about the
location of the ANC data packets in the SDI raster, but other location of the ANC data packets in the SDI raster, but other
skipping to change at page 12, line 14 skipping to change at page 12, line 34
4. SDP Considerations 4. SDP Considerations
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC 4855 parameters SHALL be done according to Section 3 of RFC 4855
[RFC4855]. [RFC4855].
o The type name ("video") goes in SDP "m=" as the media name. o The type name ("video") goes in SDP "m=" as the media name.
o The subtype name ("smpte291") goes in SDP "a=rtpmap" as the o The subtype name ("smpte291") goes in SDP "a=rtpmap" as the
encoding name, followed by a slash ("/") and the required rate encoding name, followed by a slash ("/") and the rate parameter.
parameter.
o The optional parameters VPID_Code and DID_SDID, when present, are o The optional parameters VPID_Code and DID_SDID, when present, are
included in the "a=fmtp" attribute line of SDP as a semicolon- included in the "a=fmtp" attribute line of SDP as a semicolon-
separated list of parameter=value pairs. separated list of parameter=value pairs.
DID and SDID values SHALL be specified in hexadecimal with a "0x" DID and SDID values SHALL be specified in hexadecimal with a "0x"
prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the
DID_SDID optional parameter SHALL be: DID_SDID optional parameter SHALL be:
TwoHex = "0x" 1*2(HEXDIG) TwoHex = "0x" 1*2(HEXDIG)
DidSdid = "DID_SDID={" TwoHex "," TwoHex "}" DidSdid = "DID_SDID={" TwoHex "," TwoHex "}"
For example, EIA 608 Closed Caption data would be signalled with the For example, EIA 608 Closed Caption data would be signalled with the
parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not
specified, then the ancillary data stream might potentially contain specified, then the ancillary data stream might potentially contain
ancillary data packets of any type. ancillary data packets of any type.
Multiple DID_SDID parameters may be specified (separated by Multiple DID_SDID parameters can be specified (separated by
semicolons) to signal the presence of multiple types of ANC data in semicolons) to signal the presence of multiple types of ANC data in
the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example, the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example,
signals the presence of EIA 608 Closed Captions as well as AFD/Bar signals the presence of EIA 608 Closed Captions as well as AFD/Bar
Data. Multiple DID_SDID parameters do not imply any particular Data. Multiple DID_SDID parameters do not imply any particular
ordering of the different types of ANC packets in the stream. ordering of the different types of ANC packets in the stream.
If the optional parameter VPID_Code is present, it SHALL be present If the optional parameter VPID_Code is present, it SHALL be present
only once in the semicolon-separated list, taking a single integer only once in the semicolon-separated list, taking a single integer
value. value.
skipping to change at page 14, line 38 skipping to change at page 15, line 21
application. They can find guidance on available security mechanisms application. They can find guidance on available security mechanisms
and important considerations in Options for Securing RTP Sessions and important considerations in Options for Securing RTP Sessions
[RFC7201]. Applications SHOULD use one or more appropriate strong [RFC7201]. Applications SHOULD use one or more appropriate strong
security mechanisms. The rest of this security consideration section security mechanisms. The rest of this security consideration section
discusses the security impacting properties of the payload format discusses the security impacting properties of the payload format
itself. itself.
To avoid potential buffer overflow attacks, receivers SHOULD validate To avoid potential buffer overflow attacks, receivers SHOULD validate
that the ANC data packets in the RTP payload are of the appropriate 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 length (using the Data_Count field) for the ANC data type specified
by DID & SDID. Also the Checksum_Word should be checked against the 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 ANC data packet to ensure that its data has not been damaged in
transit, but the Checksum_Word is unlikely to provide a payload transit, but the Checksum_Word is unlikely to provide a payload
integrity check in case of a directed attack. integrity check in case of a directed attack.
Some receivers will simply move the ANC data packet bits from the RTP Some receivers will simply move the ANC data packet bits from the RTP
payload into a serial digital interface (SDI). It might still be a payload into a serial digital interface (SDI). It might still be a
good idea for these "re-embedders" to perform the above mentioned good idea for these "re-embedders" to perform the above mentioned
validity tests to avoid downstream SDI systems from becoming confused validity tests to avoid downstream SDI systems from becoming confused
by bad ANC data packets, which could be used for a denial of service by bad ANC data packets, which could be used for a denial of service
attack. attack.
"Re-embedders" into SDI should also double check that the Line_Number "Re-embedders" into SDI SHOULD also double check that the Line_Number
and Horizontal_Offset leads to the ANC data packet being inserted and Horizontal_Offset leads to the ANC data packet being inserted
into a legal area to carry ancillary data in the SDI video bit stream into a legal area to carry ancillary data in the SDI video bit stream
of the output video format. of the output video format.
8. References 8. References
8.1. Normative References 8.1. Normative References
[BT1120] ITU-R, "BT.1120-8, Digital Interfaces for HDTV Studio [BT1120] ITU-R, "BT.1120-8, Digital Interfaces for HDTV Studio
Signals", January 2012. Signals", January 2012.
skipping to change at page 16, line 42 skipping to change at page 17, line 28
[ST352] SMPTE, "ST 352:2013, Payload Identification Codes for [ST352] SMPTE, "ST 352:2013, Payload Identification Codes for
Serial Digital Interfaces", 2013. Serial Digital Interfaces", 2013.
8.2. Informative References 8.2. Informative References
[BT656] ITU-R, "BT.656-5, Interfaces for Digital Component Video [BT656] ITU-R, "BT.656-5, Interfaces for Digital Component Video
Signals in 525-Line and 625-Line Television Systems Signals in 525-Line and 625-Line Television Systems
Operating at the 4:2:2 Level of Recommendation ITU-R Operating at the 4:2:2 Level of Recommendation ITU-R
BT.601", December 2007. BT.601", December 2007.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
September 2005, <http://www.rfc-editor.org/info/rfc4175>. September 2005, <http://www.rfc-editor.org/info/rfc4175>.
[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload [RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload
Format for JPEG 2000 Video Streams", RFC 5371, Format for JPEG 2000 Video Streams", RFC 5371,
DOI 10.17487/RFC5371, October 2008, DOI 10.17487/RFC5371, October 2008,
<http://www.rfc-editor.org/info/rfc5371>. <http://www.rfc-editor.org/info/rfc5371>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
 End of changes. 21 change blocks. 
36 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/