As per Relevance of the word specific, we have this rfc below:
Network Working Group D.
Request for Comments: 2431 Claddagh
Category: Standards Track October 1998
RTP Payload Format for BT.656 Video
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document specifies the RTP payload format for encapsulating
Recommendation BT.656-3 video streams in the Real-Time
Protocol (RTP). Each RTP packet contains all or a portion of
scan line as defined by ITU Recommendation BT.601-5, and
fragmentation, decoding and positioning information
1.
This document describes a scheme to packetize uncompressed, studio
quality video streams as defined by BT.656 for transport using
[1]. A BT.656 video stream is defined by ITU-R
BT.656-3 [2], as a means of interconnecting digital
equipment operating on the 525-line or 625-line standards,
complying with the 4:2:2 encoding parameters as defined in ITU-
Recommendation BT.601-5 (formerly CCIR-601) [3], Part A
RTP is defined by the Internet Engineering Task Force (IETF)
provide end-to-end network transport functions suitable
applications transmitting real-time data over multicast or
network services. The complete specification of RTP for a
application requires the RTP protocol document [1], a
specification document [4], and a payload format specification.
document is intended to serve as the payload format specification
studio-quality video streams
Tynan Standards Track [Page 1]
RFC 2431 RTP Payload Format for BT.656 October 1998
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [5].
2.
For the purposes of this document, the following definitions apply
Y: An 8-bit or 10-bit coded "luminance" sample. Luminance in
context refers to the BT.601-5 [3] definition which is not the
as a true CIE luminance value. The value of "luminance"
specifically to video luma. However, in order to avoid confusion
the BT.656 and BT.601 standards, the video luma value is
in this document as luminance. Each value has 220
levels with the black level corresponding to level 16 and the
white level corresponding to 235.
Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as
BT.601-5). Each color-difference value has 225 quantization
in the centre part of the quantization scale with a color-
of zero having an encoded value of 128.
True Black: BT.601-5 defines a true black level as the quad-
sequence 0x80, 0x10, 0x80, 0x10, representing color-difference
of 128 (0x80) and a luminance value of 16 (0x10).
SAV, EAV: Video timing reference codes which appear at the start
end of a BT.656 scan line
3. Payload
ITU Recommendation BT.656-3 defines a schema for the
interconnection of television video signals in conjunction
BT.601-5 which defines the digital representation of the
analog signal. While BT.601-5 refers to images with or without
subsampling, the interconnection standard (BT.656-3)
requires 4:2:2 subsampling. This specification also requires 4:2:2
subsampling such that the luminance stream occupies twice
bandwidth of each of the two color-difference streams. For
4:3 aspect ratio images, this results in 720 luminance samples
scan line, and 360 samples of each of the two chrominance channels
The total number of samples per scan line in this case is 1440.
While this payload format specification can accomodate various
sizes and frame rates, only those in accordance with BT.601-5
currently supported
Tynan Standards Track [Page 2]
RFC 2431 RTP Payload Format for BT.656 October 1998
Due to the lack of any form of video compression within the
and sampling-rate compliance with BT.601-5, the resultant
stream can be considered "studio quality". However, such a
can require approximately 20 megabytes per second of
bandwidth. In order to maximize packet size within a given MTU,
to optimize scan line decoding, each video scan line is
within one or more RTP packets
To allow for scan line synchronization, each packet includes
flag bits (as defined in BT.656-3) and a unique scan line number
The SAV and EAV timing reference codes are removed. Furthermore,
line blanking samples are included, so no ancillary data can
included in the line blanking period. It is the responsibility
the receiver to generate the timing reference codes, and to
the correct number of line blanking samples
Similarly, there is no requirement that the frame blanking samples
provided. However, it is possible to include frame blanking
if such samples contain relevant information, such as a vertical
interlace time code (VITC), or teletext data. In the absence
frame blanking samples, the receiver MUST generate true black
as defined above, to complete the correct number of scan lines
field. If frame blanking samples are provided, they MUST be
without modification into the resultant BT.656-3 stream
Scan lines MUST be sent in sequential order. Error concealment
missing scan lines or fragments of scan lines is at the discretion
the receiver
Both 8-bit and 10-bit quantization types as defined by BT.601-5
supported. 10-bit samples are considered to have two extra bits
fixed-point precision such that a binary value of 10111110.11
represents a sample value of 190.75. Using 8-bit quantization,
would give a sample value of 190. An application receiving 8-
samples for a 10-bit device MUST consider the sample as
the most-significant 8 bits. The two least-significant bits
be set to zero. Similarly, an application sending 8-bit samples
a 10-bit device MUST drop the two least-significant bits. For a 10-
bit quantization payload, each pair of samples MUST be encoded into
40-bit word (five octets) prior to transmission, as specified
Section 6.
To allow for scan lines with octet lengths larger than the
maximum transmission unit (MTU), a scan offset field is included
the packet header. Applications SHOULD attempt path MTU
[6] and fragment scan lines into multiple packets no larger than
MTU
Tynan Standards Track [Page 3]
RFC 2431 RTP Payload Format for BT.656 October 1998
Fragmentation MUST occur on a sample-pair boundary, such that
chrominance and luminance values are not split across packets.
8-bit quantization this gives a four-octet alignment, and a five
octet alignment for 10-bit quantization. As a result, the
offset refers not to the byte offset within the payload, but
sample-pair offset
4. Usage of
Due to the unreliable nature of the RTP protocol, and the lack of
orderly delivery mechanism, each packet contains enough
to form a single scan line without reference to prior scan lines
prior frames. In addition to the RTP header, a fixed length
header is included in each packet. This header is four octets
length
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1. RTP Header
Each RTP packet starts with a fixed RTP header. The following
of the RTP fixed header are used for BT.656-3 encapsulation
Marker bit (M): The Marker bit of the RTP header is set to 1 for
last packet of a frame (or the last fragment of the last scan line
fragmented), and set to 0 on all other packets
Payload Type (PT): The Payload Type indicates the use of the
format defined in this document. A profile MAY assign a payload
value for this format either statically or dynamically as
in RFC 1890 [4].
Timestamp: The RTP Timestamp encodes the sampling instant of
video frame currently being rendered. All scan line packets
the same frame will have the same timestamp. The timestamp
refer to the 'Ov' field synchronization point of the first field
For the payload format defined by this document, the RTP timestamp
based on a 90kHz clock
Tynan Standards Track [Page 4]
RFC 2431 RTP Payload Format for BT.656 October 1998
5. Payload
The payload header is a fixed four-octet header broken down
follows
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1
When 0, indicates the first field of a frame (line 4 through 265
inclusive for Type=0 or 2, and line 1 through 312 inclusive for Type=1
or 3). Any other scan line is considered a component of the
field, and the F bit will be set to 1. This bit is copied
from the BT.656-compliant stream by the transmitter, and inserted
the stream by the receiver
V: 1
When 1, indicates that the scan line is part of the vertical interval
Should always be 0 unless frame blanking data is sent. In which case
the V bit SHOULD be set to 1 for scan lines which do not form
integral part of the image. This bit is copied directly from
BT.656-compliant stream by the transmitter, and inserted into
stream by the receiver. For receivers which do not receive scan
during the vertical interval, BT.656 vertical interval data MUST
generated by repeating the quad-sample sequence 0x80, 0x10, 0x80,
0x10, representing a true black level
Type: 4
This field indicates the type of frame encoding within the payload
It MUST remain unchanged for all scan lines within the same frame
Currently only four types of encoding are defined. These are
follows
0 - NTSC (13.5MHz sample rate; 720 samples per line; 60
per second; 525 lines per frame
1 - PAL (13.5MHz sample rate; 720 samples per line; 50
per second; 625 lines per frame
2 - High Definition NTSC (18MHz sample rate; 1144 samples
line; 60 fields per second; 525 lines per frame
3 - High Definition PAL (18MHz sample rate; 1152 samples
line; 50 fields per second; 625 lines per frame
Tynan Standards Track [Page 5]
RFC 2431 RTP Payload Format for BT.656 October 1998
Further encodings can only be defined through the Internet
Numbers Authority (IANA). For more information refer to Section 8,
"IANA Considerations".
P: 1
Indicates the required sample quantization size. When 0, the
is comprised of 8-bit samples. Otherwise, it carries 10-bit samples
This bit MUST remain unchanged for all scan lines within the
frame
Z: 2
Reserved for future use. Must be set to zero by the transmitter
ignored by the receiver
Scan Line (SL): 12
Indicates the scan line encapsulated in the payload. Valid
range from 1 through 625 inclusive. If no frame blanking data
being transmitted, only scan lines 23 through 310 inclusive,
lines 336 through 623 inclusive SHOULD be sent in the case of Type=1
or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263
inclusive and lines 273 through 525 SHOULD be transmitted
If a receiver is generating a BT.656-3 data stream directly from
packet, the F and V bits MUST be copied from the header rather
being generated implicitly from the scan line number. In the
of a conflict, the F and V bits have precedence
Scan Offset (SO): 11
Indicates the offset within the scan line for application-
fragmentation. After doing PMTU discovery, if the path MTU is
than the required size for one complete scan line, the data SHOULD
fragmented such that a given RTP packet does not exceed the
MTU. The offset for the first packet of a scan line MUST be set
zero. The scan offset refers to the sample-pair offset within
scan such that for a scan line width of 720, the maximum scan
is 359.
6. Payload
In keeping with the 4:2:2 color subsampling of BT.656 and BT.601,
each pair of color-difference samples will be intermixed with
luminance samples. As per BT.656, the format for transmission
be Cb, Y, Cr, Y. The following is a representation of a 720
packet with 8-bit quantization
Tynan Standards Track [Page 6]
RFC 2431 RTP Payload Format for BT.656 October 1998
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb0 | Y0 | Cr0 | Y1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb1 | Y2 | Cr1 | Y3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cb359 | Y718 | Cr359 | Y719 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1144 and 1152 sample packets SHOULD increase the packet
accordingly while maintaining the sample order
For 10-bit quantization, each group of four samples MUST be
into a 40-bit word (five octets) prior to transmission. The
order is identical to that for 8-bit quantization. The following
a representation of a 720 sample packet with 10-bit quantization
0 1 2 3
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
+---------+---------+---------+---------+
| Cb0 | Y0 | Cr0 | Y1 |
+---------+---------+---------+---------+
| Cb1 | Y2 | Cr1 | Y3 |
+---------+---------+---------+---------+
.
.
.
+---------+---------+---------+---------+
| Cb359 | Y718 | Cr359 | Y719 |
+---------+---------+---------+---------+
(Note that the word width is 40 bits
+-------+-------+-------+-------+-------+
Octets: | 0 | 1 | 2 | 3 | 4 |
+-------+-------+-------+-------+-------+
The octets shown in these diagrams are transmitted in network
order, that is, left-to-right as shown
Tynan Standards Track [Page 7]
RFC 2431 RTP Payload Format for BT.656 October 1998
7. Security
RTP packets using the payload format defined in this
are subject to the security considerations discussed in the
specification [1]. This implies that confidentiality of the
streams is achieved by encryption. Because the payload format
arranged end-to-end, encryption MAY be performed after
so there is no conflict between the two operations
This payload type does not exhibit any significant non-uniformity
the receiver side computational complexity for packet processing
cause a potential denial-of-service threat
8. IANA
The four encoding types defined by this document relate to
schema defined by ITU-R Recommendation BT.656-3. Future revisions
the recommendation may create further encoding types which need to
supported over RTP. The "Type" field is four bits wide allowing for
total of up to sixteen possible encodings, with twelve
reserved for future use. Due to the small number of
encodings and given that it is very unlikely that future revisions
BT.656 will introduce any new schema, requests to extend the
field MUST be vetted by the Internet Assigned Numbers Authority
Furthermore, implementors SHOULD check the IANA repository for
definitions of the Type field in order to comply with this document
Applications for a new Type value MUST be submitted to the IANA
include the requestors name and contact information, the reason
requesting a new Type and references to appropriate standards,
as an updated version of ITU-R Recommendation BT.656. Furthermore
in the unlikely event that the new Type will lessen the security of
compliant implementation, such security risk MUST be detailed in
application. The application will be reviewed by a Designated
and if appropriate, a new Type will be assigned. This type will
listed in the IANA repository for future implementations
Tynan Standards Track [Page 8]
RFC 2431 RTP Payload Format for BT.656 October 1998
9.
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson
"RTP: A Transport Protocol for Real-Time Applications",
1889, January 1996.
[2] Interfaces for Digital Component Video Signals in 525-Line
625-Line Television Systems operating at the 4:2:2 Level
Recommendation ITU-R BT.601 (Part A), ITU-R
BT.656-3, 1995.
[3] Studio Encoding Parameters of Digital Television for
4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R
BT.601-5, 1995.
[4] Schulzrinne, H., "RTP Profile for Audio and Video
with Minimal Control", RFC 1890, January 1996.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
10. Author's
Dermot
Claddagh Films
3 White
Clybaun
EMail: dtynan@claddagh.
Phone: +353 91 529944
Tynan Standards Track [Page 9]
RFC 2431 RTP Payload Format for BT.656 October 1998
11. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Tynan Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
