RFC2429 日本語訳
2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video(H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. (Format: TXT=43166 bytes) (Obsoleted by RFC4629) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group
Request for Comments: 2429 C. Bormann
Category: Standards Track Univ. Bremen
L. Cline
G. Deisher
T. Gardos
C. Maciocco
D. Newell
Intel
J. Ott
Univ. Bremen
G. Sullivan
PictureTel
S. Wenger
TU Berlin
C. Zhu
Intel
October 1998
Network Working Group Request for Comments: 2429 C. Bormann Category: Standards Track Univ. Bremen L. Cline G. Deisher T. Gardos C. Maciocco D. Newell Intel J. Ott Univ. Bremen G. Sullivan PictureTel S. Wenger TU Berlin C. Zhu Intel October 1998
RTP Payload Format for the 1998 Version of
ITU-T Rec. H.263 Video (H.263+)
RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Introduction
1. Introduction
This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 [3], and is recommended for this use by new implementations. This format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 shall use the format described in this document.
This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 [3], and is recommended for this use by new implementations. This format does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. Implementations using the new features of the 1998 version of H.263 shall use the format described in this document.
Bormann, et. al. Standards Track [Page 1] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 1] RFC 2429 H.263+ October 1998
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options.
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options.
The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries.
The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries.
With the independent segment decoding (ISD) option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others.
With the independent segment decoding (ISD) option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others.
The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode can be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information.
The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode can be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information.
H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to- noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both.
H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to- noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both.
Bormann, et. al. Standards Track [Page 2] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 2] RFC 2429 H.263+ October 1998
2. Usage of RTP
2. Usage of RTP
When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream including the fixed length codes and variable length codes will be included in the packet, with the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of the start code are removed and replaced by setting an indicator bit in the payload header.
When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream including the fixed length codes and variable length codes will be included in the packet, with the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of the start code are removed and replaced by setting an indicator bit in the payload header.
For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications.
For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications.
The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in section 4. This section defines the usage of the RTP fixed header and H.263+ video packet structure.
The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in section 4. This section defines the usage of the RTP fixed header and H.263+ video packet structure.
2.1 RTP Header Usage
2.1 RTP Header Usage
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263+ video streams:
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263+ video streams:
Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame, and is 0 otherwise.
Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame, and is 0 otherwise.
Payload Type (PT): The Payload Type shall specify the H.263+ video payload format.
Payload Type (PT): The Payload Type shall specify the H.263+ video payload format.
Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to the 1998 ITU-T Recommendation H.263 [4] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock,
Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to the 1998 ITU-T Recommendation H.263 [4] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock,
Bormann, et. al. Standards Track [Page 3] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 3] RFC 2429 H.263+ October 1998
the same as that of the RTP payload for H.261 stream [5]. Since both the H.263+ data and the RTP header contain time information, it is required that those timing information run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. Any H.263+ picture clock frequency can be expressed as 1800000/(cd*cf) source pictures per second, in which cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock of the RTP timestamp, the time increment between each coded H.263+ picture should therefore be a integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer display update rates of 60, 72 and 75 Hz, respectively). For RTP packetization of hypothetical H.263+ bitstreams using "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary for generating the RTP timestamps.
the same as that of the RTP payload for H.261 stream [5]. Since both the H.263+ data and the RTP header contain time information, it is required that those timing information run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. Any H.263+ picture clock frequency can be expressed as 1800000/(cd*cf) source pictures per second, in which cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock of the RTP timestamp, the time increment between each coded H.263+ picture should therefore be a integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer display update rates of 60, 72 and 75 Hz, respectively). For RTP packetization of hypothetical H.263+ bitstreams using "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary for generating the RTP timestamps.
2.2 Video Packet Structure
2.2 Video Packet Structure
A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable depending on the payload involved as detailed in the section 4. The layout of the RTP H.263+ video packet is shown as:
A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable depending on the payload involved as detailed in the section 4. The layout of the RTP H.263+ video packet is shown as:
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263+ Payload Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263+ Compressed Data Stream ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Payload Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Compressed Data Stream ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS starts codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned; however, since this is not required in H.263+, there may be some cases where GOB start codes are not aligned, such as when transmitting existing content, or when using H.263 encoders that do not support GOB start code alignment. In this case, follow-on packets (see section 5.2) should be used for packetization.
Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS starts codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned; however, since this is not required in H.263+, there may be some cases where GOB start codes are not aligned, such as when transmitting existing content, or when using H.263 encoders that do not support GOB start code alignment. In this case, follow-on packets (see section 5.2) should be used for packetization.
Bormann, et. al. Standards Track [Page 4] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 4] RFC 2429 H.263+ October 1998
All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header.
All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header.
3. Design Considerations
3. Design Considerations
The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in such cases in which another packet containing the original picture header becomes lost.
The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in such cases in which another packet containing the original picture header becomes lost.
There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video.
There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video.
o The optional slice structured mode described in Annex K of H.263+
[4] enables more flexibility for packetization. Similar to a
picture segment that begins with a GOB header, the motion vector
predictors in a slice are restricted to reside within its
boundaries. However, slices provide much greater freedom in the
selection of the size and shape of the area which is represented as
a distinct decodable region. In particular, slices can have a size
which is dynamically selected to allow the data for each slice to
fit into a chosen packet size. Slices can also be chosen to have a
rectangular shape which is conducive for minimizing the impact of
errors and packet losses on motion compensated prediction. For
these reasons, the use of the slice structured mode is strongly
recommended for any applications used in environments where
significant packet loss occurs.
o The optional slice structured mode described in Annex K of H.263+ [4] enables more flexibility for packetization. Similar to a picture segment that begins with a GOB header, the motion vector predictors in a slice are restricted to reside within its boundaries. However, slices provide much greater freedom in the selection of the size and shape of the area which is represented as a distinct decodable region. In particular, slices can have a size which is dynamically selected to allow the data for each slice to fit into a chosen packet size. Slices can also be chosen to have a rectangular shape which is conducive for minimizing the impact of errors and packet losses on motion compensated prediction. For these reasons, the use of the slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs.
o In non-rectangular slice structured mode, only complete slices
should be included in a packet. In other words, slices should not
be fragmented across packet boundaries. The only reasonable need
for a slice to be fragmented across packet boundaries is when the
encoder which generated the H.263+ data stream could not be
influenced by an awareness of the packetization process (such as
when sending H.263+ data through a network other than the one to
which the encoder is attached, as in network gateway
o In non-rectangular slice structured mode, only complete slices should be included in a packet. In other words, slices should not be fragmented across packet boundaries. The only reasonable need for a slice to be fragmented across packet boundaries is when the encoder which generated the H.263+ data stream could not be influenced by an awareness of the packetization process (such as when sending H.263+ data through a network other than the one to which the encoder is attached, as in network gateway
Bormann, et. al. Standards Track [Page 5] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 5] RFC 2429 H.263+ October 1998
implementations). Optimally, each packet will contain only one
slice.
implementations). Optimally, each packet will contain only one slice.
o The independent segment decoding (ISD) described in Annex R of [4]
prevents any data dependency across slice or GOB boundaries in the
reference picture. It can be utilized to further improve
resiliency in high loss conditions.
o The independent segment decoding (ISD) described in Annex R of [4] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to further improve resiliency in high loss conditions.
o If ISD is used in conjunction with the slice structure, the
rectangular slice submode shall be enabled and the dimensions and
quantity of the slices present in a frame shall remain the same
between each two intra-coded frames (I-frames), as required in
H.263+. The individual ISD segments may also be entirely intra
coded from time to time to realize quick error recovery without
adding the latency time associated with sending complete INTRA-
pictures.
o If ISD is used in conjunction with the slice structure, the rectangular slice submode shall be enabled and the dimensions and quantity of the slices present in a frame shall remain the same between each two intra-coded frames (I-frames), as required in H.263+. The individual ISD segments may also be entirely intra coded from time to time to realize quick error recovery without adding the latency time associated with sending complete INTRA- pictures.
o When the slice structure is not applied, the insertion of a
(preferably byte-aligned) GOB header can be used to provide resync
boundaries in the bitstream, as the presence of a GOB header
eliminates the dependency of motion vector prediction across GOB
boundaries. These resync boundaries provide natural locations for
packet payload boundaries.
o When the slice structure is not applied, the insertion of a (preferably byte-aligned) GOB header can be used to provide resync boundaries in the bitstream, as the presence of a GOB header eliminates the dependency of motion vector prediction across GOB boundaries. These resync boundaries provide natural locations for packet payload boundaries.
o H.263+ allows picture headers to be sent in an abbreviated form in
order to prevent repetition of overhead information that does not
change from picture to picture. For resiliency, sending a complete
picture header for every frame is often advisable. This means that
(especially in cases with high packet loss probability in which
picture header contents are not expected to be highly predictable),
the sender may find it advisable to always set the subfield UFEP in
PLUSPTYPE to '001' in the H.263+ video bitstream. (See [4] for the
definition of the UFEP and PLUSPTYPE fields).
o H.263+ allows picture headers to be sent in an abbreviated form in order to prevent repetition of overhead information that does not change from picture to picture. For resiliency, sending a complete picture header for every frame is often advisable. This means that (especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable), the sender may find it advisable to always set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. (See [4] for the definition of the UFEP and PLUSPTYPE fields).
o In a multi-layer scenario, each layer may be transmitted to a
different network address. The configuration of each layer such as
the enhancement layer number (ELNUM), reference layer number
(RLNUM), and scalability type should be determined at the start of
the session and should not change during the course of the session.
o In a multi-layer scenario, each layer may be transmitted to a different network address. The configuration of each layer such as the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type should be determined at the start of the session and should not change during the course of the session.
o All start codes can be byte aligned, and picture, slice, and EOSBS
start codes are always byte aligned. The boundaries of these
syntactical elements provide ideal locations for placing packet
boundaries.
o All start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned. The boundaries of these syntactical elements provide ideal locations for placing packet boundaries.
Bormann, et. al. Standards Track [Page 6] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 6] RFC 2429 H.263+ October 1998
o We assume that a maximum Picture Header size of 504 bits is
sufficient. The syntax of H.263+ does not explicitly prohibit
larger picture header sizes, but the use of such extremely large
picture headers is not expected.
o We assume that a maximum Picture Header size of 504 bits is sufficient. The syntax of H.263+ does not explicitly prohibit larger picture header sizes, but the use of such extremely large picture headers is not expected.
4. H.263+ Payload Header
4. H.263+ Payload Header
For H.263+ video streams, each RTP packet carries only one H.263+ video packet. The H.263+ payload header is always present for each H.263+ video packet. The payload header is of variable length. A 16 bit field of the basic payload header may be followed by an 8 bit field for Video Redundancy Coding (VRC) information, and/or by a variable length extra picture header as indicated by PLEN. These optional fields appear in the order given above when present.
For H.263+ video streams, each RTP packet carries only one H.263+ video packet. The H.263+ payload header is always present for each H.263+ video packet. The payload header is of variable length. A 16 bit field of the basic payload header may be followed by an 8 bit field for Video Redundancy Coding (VRC) information, and/or by a variable length extra picture header as indicated by PLEN. These optional fields appear in the order given above when present.
If an extra picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, corresponding to PLEN equal to 0 and no VRC information present.
If an extra picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, corresponding to PLEN equal to 0 and no VRC information present.
The remainder of this section defines the various components of the RTP payload header. Section five defines the various packet types that are used to carry different types of H.263+ coded data, and section six summarizes how to distinguish between the various packet types.
The remainder of this section defines the various components of the RTP payload header. Section five defines the various packet types that are used to carry different types of H.263+ coded data, and section six summarizes how to distinguish between the various packet types.
4.1 General H.263+ payload header
4.1 General H.263+ payload header
The H.263+ payload header is structured as follows:
The H.263+ payload header is structured as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |P|V| PLEN |PEBIT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |P|V| PLEN |PEBIT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR: 5 bits
Reserved bits. Shall be zero.
RR: 5 bits Reserved bits. Shall be zero.
P: 1 bit
Indicates the picture start or a picture segment (GOB/Slice) start
or a video sequence end (EOS or EOSBS). Two bytes of zero bits
then have to be prefixed to the payload of such a packet to compose
a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows
the omission of the two first bytes of the start codes, thus
improving the compression ratio.
P: 1 bit Indicates the picture start or a picture segment (GOB/Slice) start or a video sequence end (EOS or EOSBS). Two bytes of zero bits then have to be prefixed to the payload of such a packet to compose a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the omission of the two first bytes of the start codes, thus improving the compression ratio.
Bormann, et. al. Standards Track [Page 7] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 7] RFC 2429 H.263+ October 1998
V: 1 bit
Indicates the presence of an 8 bit field containing information for
Video Redundancy Coding (VRC), which follows immediately after the
initial 16 bits of the payload header if present. For syntax and
semantics of that 8 bit VRC field see section 4.2.
V: 1 bit Indicates the presence of an 8 bit field containing information for Video Redundancy Coding (VRC), which follows immediately after the initial 16 bits of the payload header if present. For syntax and semantics of that 8 bit VRC field see section 4.2.
PLEN: 6 bits
Length in bytes of the extra picture header. If no extra picture
header is attached, PLEN is 0. If PLEN>0, the extra picture header
is attached immediately following the rest of the payload header.
Note the length reflects the omission of the first two bytes of the
picture start code (PSC). See section 5.1.
PLEN: 6 bits Length in bytes of the extra picture header. If no extra picture header is attached, PLEN is 0. If PLEN>0, the extra picture header is attached immediately following the rest of the payload header. Note the length reflects the omission of the first two bytes of the picture start code (PSC). See section 5.1.
PEBIT: 3 bits
Indicates the number of bits that shall be ignored in the last byte
of the picture header. If PLEN is not zero, the ignored bits shall
be the least significant bits of the byte. If PLEN is zero, then
PEBIT shall also be zero.
PEBIT: 3 bits Indicates the number of bits that shall be ignored in the last byte of the picture header. If PLEN is not zero, the ignored bits shall be the least significant bits of the byte. If PLEN is zero, then PEBIT shall also be zero.
4.2 Video Redundancy Coding Header Extension
4.2 Video Redundancy Coding Header Extension
Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N of [4]. By having multiple "threads" of independently inter-frame predicted pictures, damage of individual frame will cause distortions only within its own thread but leave the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture which is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For more information on codec support for VRC see [7].
Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N of [4]. By having multiple "threads" of independently inter-frame predicted pictures, damage of individual frame will cause distortions only within its own thread but leave the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture which is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For more information on codec support for VRC see [7].
P-picture temporal scalability is another use of the reference picture selection mode and can be considered a special case of VRC in which only one copy of each sync frame may be sent. It offers a thread-based method of temporal scalability without the increased delay caused by the use of B pictures. In this use, sync frames sent in the first thread of pictures are also used for the prediction of a second thread of pictures which fall temporally between the sync frames to increase the resulting frame rate. In this use, the pictures in the second thread can be discarded in order to obtain a reduction of bit rate or decoding complexity without harming the ability to decode later pictures. A third or more threads can also be added as well, but each thread is predicted only from the sync frames (which are sent at least in thread 0) or from frames within the same thread.
P-picture temporal scalability is another use of the reference picture selection mode and can be considered a special case of VRC in which only one copy of each sync frame may be sent. It offers a thread-based method of temporal scalability without the increased delay caused by the use of B pictures. In this use, sync frames sent in the first thread of pictures are also used for the prediction of a second thread of pictures which fall temporally between the sync frames to increase the resulting frame rate. In this use, the pictures in the second thread can be discarded in order to obtain a reduction of bit rate or decoding complexity without harming the ability to decode later pictures. A third or more threads can also be added as well, but each thread is predicted only from the sync frames (which are sent at least in thread 0) or from frames within the same thread.
Bormann, et. al. Standards Track [Page 8] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 8] RFC 2429 H.263+ October 1998
While a VRC data stream is - like all H.263+ data - totally self- contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, and the thread-id and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension.
While a VRC data stream is - like all H.263+ data - totally self- contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, and the thread-id and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension.
The format of the VRC header extension is as follows:
The format of the VRC header extension is as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | TID | Trun |S| +-+-+-+-+-+-+-+-+
TID: 3 bits
Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC
data will use as reference information only sync frames or frames
within the same thread. By convention, thread 0 is expected to be
the "canonical" thread, which is the thread from which the sync
frame should ideally be used. In the case of corruption or loss of
the thread 0 representation, a representation of the sync frame
with a higher thread number can be used by the decoder. Lower
thread numbers are expected to contain equal or better
representations of the sync frames than higher thread numbers in
the absence of data corruption or loss. See [7] for a detailed
discussion of VRC.
TID: 3 bits Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC data will use as reference information only sync frames or frames within the same thread. By convention, thread 0 is expected to be the "canonical" thread, which is the thread from which the sync frame should ideally be used. In the case of corruption or loss of the thread 0 representation, a representation of the sync frame with a higher thread number can be used by the decoder. Lower thread numbers are expected to contain equal or better representations of the sync frames than higher thread numbers in the absence of data corruption or loss. See [7] for a detailed discussion of VRC.
Trun: 4 bits
Monotonically increasing (modulo 16) 4 bit number counting the
packet number within each thread.
Trun: 4 bits Monotonically increasing (modulo 16) 4 bit number counting the packet number within each thread.
S: 1 bit
A bit that indicates that the packet content is for a sync frame.
An encoder using VRC may send several representations of the same
"sync" picture, in order to ensure that regardless of which thread
of pictures is corrupted by errors or packet losses, the reception
of at least one representation of a particular picture is ensured
(within at least one thread). The sync picture can then be used
for the prediction of any thread. If packet losses have not
occurred, then the sync frame contents of thread 0 can be used and
those of other threads can be discarded (and similarly for other
threads). Thread 0 is considered the "canonical" thread, the use
of which is preferable to all others. The contents of packets
having lower thread numbers shall be considered as having a higher
processing and delivery priority than those with higher thread
numbers. Thus packets having lower thread numbers for a given sync
frame shall be delivered first to the decoder under loss-free and
S: 1 bit A bit that indicates that the packet content is for a sync frame. An encoder using VRC may send several representations of the same "sync" picture, in order to ensure that regardless of which thread of pictures is corrupted by errors or packet losses, the reception of at least one representation of a particular picture is ensured (within at least one thread). The sync picture can then be used for the prediction of any thread. If packet losses have not occurred, then the sync frame contents of thread 0 can be used and those of other threads can be discarded (and similarly for other threads). Thread 0 is considered the "canonical" thread, the use of which is preferable to all others. The contents of packets having lower thread numbers shall be considered as having a higher processing and delivery priority than those with higher thread numbers. Thus packets having lower thread numbers for a given sync frame shall be delivered first to the decoder under loss-free and
Bormann, et. al. Standards Track [Page 9] RFC 2429 H.263+ October 1998
Bormann, et. al. Standards Track [Page 9] RFC 2429 H.263+ October 1998
low-time-jitter conditions, which will result in the discarding of
the sync contents of the higher-numbered threads as specified in
Annex N of [4].
low-time-jitter conditions, which will result in the discarding of the sync contents of the higher-numbered threads as specified in Annex N of [4].
5. Packetization schemes
5. Packetization schemes
5.1 Picture Segment Packets and Sequence Ending Packets (P=1)
5.1 Picture Segment Packets and Sequence Ending Packets (P=1)
A picture segment packet is defined as a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This corresponds to the definition of the start of a video picture segment as defined in H.263+. For such packets, P=1 always.
絵のセグメントパケットはPicture、GOB、または部分スタートコードの位置でH.263+データ・ストリームで始まるパケットと定義されます。 これはH.263で定義されるようにビデオ絵のセグメントの始まりの定義に対応しています。+、そのようなパケット、P=1、いつも。
An extra picture header can sometimes be attached in the payload header of such packets. Whenever an extra picture header is attached as signified by PLEN>0, only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled on the receiving end by prepending the sixteen leading '0' bits.
そのようなパケットのペイロードヘッダーに時々余分な絵のヘッダーを取り付けることができます。 PLEN>0によって意味されているように余分な絵のヘッダーが付属しているときはいつも、絵のスタートコードの最後の6ビット('100000')だけがペイロードヘッダーに含まれています。 バイトの並べられた絵のスタートコードがある完全なH.263+絵のヘッダーは、受ける側になって'0'ビット導く16をprependingすることによって、便利に集まることができます。
When PLEN>0, the end bit position corresponding to the last byte of the picture header data is indicated by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header.
PLEN>0であるときに、絵のヘッダー・データの最後のバイトに対応する終わりのビット位置はPEBITによって示されます。 実際のbitstreamデータはペイロードヘッダーに続く8ビットのバイト境界で始まるものとします。
A sequence ending packet is defined as a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. This delineates the end of a sequence of H.263+ video data (more H.263+ video data may still follow later, however, as specified in ITU-T Recommendation H.263). For such packets, P=1 and PLEN=0 always.
系列の終わりのパケットはEOSの位置の始めかH.263+データのEOSBSコードが流すパケットと定義されます。 これはH.263+ビデオ・データの系列の終わりを図で表わします(しかしながら、より多くのH.263+ビデオ・データが後でITU-T Recommendation H.263で指定されるようにまだ従っているかもしれません)。 そのようなパケット、P=1、およびPLEN=0、いつも。
The optional header extension for VRC may or may not be present as indicated by the V bit flag.
VRCに、任意のヘッダー拡大はV噛み付いている旗で示されるように存在しているかもしれません。
5.1.1 Packets that begin with a Picture Start Code
5.1.1 Picture Start Codeと共に始まるパケット
Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC), and should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in such a case. However, if the coded picture contains an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization in order to provide greater error resilience. Thus, for packets that start at the location of a picture start code, PLEN shall be zero unless both of the following conditions apply:
コード化された絵の全体か始まりを含むどんなパケットも、絵のスタートコード(PSC)の位置で始まって、通常、絵のヘッダーの複本なしでカプセルに入れられるはずです。 言い換えれば、通常そのような場合におけるPLEN=0。 しかしながら、コード化された画像が不完全な絵のヘッダーを含んでいる、(UFEPが等しい、「0インチ)、完全の当時のa表現、(UFEP=「1インチ) 絵のヘッダーは、より大きい誤り弾力を提供するためにpacketizationの間、取り付けられるかもしれません」。 したがって、以下の条件の両方が適用されないなら、PLENは絵のスタートコードの位置で始まるパケットに関するゼロになるでしょう:
Bormann, et. al. Standards Track [Page 10] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[10ページ]RFC2429時間.263+10月1998
1) The picture header in the H.263+ bitstream payload is incomplete
(PLUSPTYPE present and UFEP="000"), and
1) H.263+bitstreamペイロードの絵のヘッダーが不完全である、(PLUSPTYPEが提示して、UFEPが等しい、「0インチ)、」
2) The additional picture header which is attached is not incomplete
(UFEP="001").
2) 付属追加の絵ヘッダーが不完全でない、(UFEPが等しい、「1インチ)」
A packet which begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream, and signify their presence by setting P=1 in the payload header.
Picture、GOB、部分、EOS、またはEOSBSスタートコードの位置で始まるパケットは、H.263+bitstreamから2(すべてのゼロ)バイト離れたところで1番目を省略して、ペイロードヘッダーにP=1をはめ込むことによって、それらの存在を意味するものとします。
Here is an example of encapsulating the first packet in a frame (without an attached redundant complete picture header):
ここに、フレーム(付属余分な完全な絵のヘッダーのない)で最初のパケットをカプセルに入れる例があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first two 0 bytes of the PSC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR|1|V|0|0|0|0|0|0|0|0|0| データをbitstreamします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初に、2 0バイトのPSC… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.2 Packets that begin with GBSC or SSC
5.1.2 GBSCかSSCと共に始まるパケット
For a packet that begins at the location of a GOB or slice start code, PLEN may be zero or may be nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when picture header contents are very seldom likely to change (except as can be detected from the GFID syntax of H.263+), a redundant copy of the picture header is not required. However, in less ideal circumstances a redundant picture header should be attached for enhanced error resilience, and its presence is indicated by PLEN>0.
GOBか部分スタートコードの位置で始まるパケットに関しては、PLENはゼロであるかもしれないか非零であるかもしれません、余分な絵のヘッダーがパケットに取り付けられるかどうかによって。 非常に低いパケット損失率がある環境かそれとも絵のヘッダー含有量がいつ非常にめったに変化しそうにないかとき(缶以外に、H.263+のGFID構文から、検出されてください)、絵のヘッダーの余分なコピーは必要ではありません。 しかしながら、それほど理想的でない事情では、余分な絵のヘッダーは高められた誤り弾力のために取り付けられるべきです、そして、存在はPLEN>0によって示されます。
Assuming a PLEN of 9 and P=1, below is an example of a packet that begins with a byte aligned GBSC or a SSC:
9とP=1のPLENを仮定して、1バイトが並べられている状態でGBSCかSSCを始めるパケットに関する例が以下にあります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| starting with TR, PTYPE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | bitstream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data starting with GBSC/SSC without its first two 0 bytes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR|1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| 絵のヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TR、PTYPEから始まります… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bitstream| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最初の2なしでGBSC/SSCから0バイト…始まるデータ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bormann, et. al. Standards Track [Page 11] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[11ページ]RFC2429時間.263+10月1998
Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled if needed on the receiving end by prepending the sixteen leading '0' bits.
絵のスタートコードの最後の6ビット('100000')だけがペイロードヘッダーに含まれているのに注意してください。 受ける側になって'0'ビット導く16をprependingすることによって必要であるなら、バイトの並べられた絵のスタートコードがある完全なH.263+絵のヘッダーは便利に集まることができます。
5.1.3 Packets that Begin with an EOS or EOSBS Code
5.1.3 パケットのEOSとそのBeginかEOSBS Code
For a packet that begins with an EOS or EOSBS code, PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet. As with other packets beginning with start codes, the two all-zero bytes that begin the EOS or EOSBS code at the beginning of the packet shall be omitted, and their presence shall be indicated by setting the P bit to 1 in the payload header.
ゼロにもかかわらず、Picture、GOB、またはどんなSliceも始めでないつもりであったならEOSかEOSBSコード、PLENと共に始まるパケットに関しては、コードは同じパケットの中に含まれているものとします。 他のパケットがスタートコードで始まっている場合、パケットの始めにおけるEOSかEOSBSコードを始める2オールゼロバイトは省略されるものとします、そして、彼らの存在は、1へのPビットをペイロードヘッダーにはめ込むことによって、示されるものとします。
System designers should be aware that some decoders may interpret the loss of a packet containing only EOS or EOSBS information as the loss of essential video data and may thus respond by not displaying some subsequent video information. Since EOS and EOSBS codes do not actually affect the decoding of video pictures, they are somewhat unnecessary to send at all. Because of the danger of misinterpretation of the loss of such a packet (which can be detected by the sequence number), encoders are generally to be discouraged from sending EOS and EOSBS.
システム設計者はいくつかのデコーダが不可欠のビデオ・データの損失としてEOSかEOSBS情報だけを含むパケットの損失を解釈して、その結果、何らかのその後のビデオ情報を表示しないことによって反応するかもしれないのを意識しているべきです。 EOSとEOSBSコードが実際にビデオの絵の解読に影響しないので、それらは全く送るためにいくらか不要です。 そのようなパケット(一連番号で、検出できる)の損失の誤解という危険のために、一般に、エンコーダは発信しているEOSとEOSBSからがっかりすることになっています。
Below is an example of a packet containing an EOS code:
以下に、EOSコードを含んでいて、パケットに関する例があります:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR|1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 Encapsulating Follow-On Packet (P=0)
5.2 フォローオンパケットをカプセルに入れること。(P=0)
A Follow-on packet contains a number of bytes of coded H.263+ data which does not start at a synchronization point. That is, a Follow- On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS header, and it may or may not start at a macroblock boundary. Since Follow-on packets do not start at synchronization points, the data at the beginning of a follow-on packet is not independently decodable. For such packets, P=0 always. If the preceding packet of a Follow-on packet got lost, the receiver may discard that Follow-on packet as well as all other following Follow-on packets. Better behavior, of course, would be for the receiver to scan the interior of the packet payload content to determine whether any start codes are found in the interior of the packet which can be used as resync points. The use of an attached copy of a picture header for a follow-on packet is
Followオンなパケットは同期ポイントで始まらない多くのバイトのコード化されたH.263+データを含んでいます。 すなわち、パケットの上のFollowはPicture、GOB、Slice、EOS、またはEOSBSヘッダーから始まりません、そして、それはmacroblock境界で始まるかもしれません。 Followオンなパケットが同期ポイントで始まらないので、フォローオンパケットの始めのデータは独自に解読可能ではありません。 そのようなパケット、P=0、いつも。 Followオンなパケットの前のパケットが失せたなら、受信機は他のすべての次のFollowオンなパケットと同様にそのFollowオンなパケットを捨てるかもしれません。 より良い振舞いは受信機が何かスタートコードが「再-同時性」が指すとき使用できるパケットの内部で見つけられるかどうか決定するためにもちろんパケットペイロード含有量の内部をスキャンするだろうことです。 絵のヘッダーの付属コピーのフォローオンパケットの使用はそうです。
Bormann, et. al. Standards Track [Page 12] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[12ページ]RFC2429時間.263+10月1998
useful only if the interior of the packet or some subsequent follow- on packet contains a resync code such as a GOB or slice start code. PLEN>0 is allowed, since it may allow resync in the interior of the packet. The decoder may also be resynchronized at the next segment or picture packet.
役に立つ、パケットの内部かパケットにおける何らかのその後の尾行がGOBか1つの部分などの「再-同時性」コードを含む場合にだけ、コードを開始させてください。 パケットの内部に「再-同時性」を許容するかもしれないので、PLEN>0は許容されています。 また、デコーダは次のセグメントか絵のパケットで再連動するかもしれません。
Here is an example of a follow-on packet (with PLEN=0):
ここに、フォローオンパケット(PLEN=0と)に関する例があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR|0|V|0|0|0|0|0|0|0|0|0| bitstreamデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Use of this payload specification
6. このペイロード仕様の使用
There is no syntactical difference between a picture segment packet and a Follow-on packet, other than the indication P=1 for picture segment or sequence ending packets and P=0 for Follow-on packets. See the following for a summary of the entire packet types and ways to distinguish between them.
絵のセグメントパケットとFollowオンなパケットの間には、どんな構文の違いもありません、Followオンなパケットのための系列の絵のセグメントのための指示P=1か終わりのパケットとP=0を除いて。 全体のパケットタイプとそれらを見分ける方法の概要に関して以下を見てください。
It is possible to distinguish between the different packet types by checking the P bit and the first 6 bits of the payload along with the header information. The following table shows the packet type for permutations of this information (see also the picture/GOB/Slice header descriptions in H.263+ for details):
ヘッダー情報に伴うペイロードのPビットと最初の6ビットをチェックすることによって異なったパケットタイプを見分けるのは可能です。 以下のテーブルはこの情報の順列のためにパケットタイプを見せています(また、詳細に関してH.263+の絵/GOB/部分ヘッダ記述を見てください):
--------------+--------------+----------------------+------------------- First 6 bits | P-Bit | PLEN | Packet | Remarks of Payload |(payload hdr.)| | --------------+--------------+----------------------+------------------- 100000 | 1 | 0 | Picture | Typical Picture 100000 | 1 | > 0 | Picture | Note UFEP 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs Xxxxxx | 0 | 0 | Follow-on | Xxxxxx | 0 | > 0 | Follow-on | Interior Resync --------------+--------------+----------------------+-------------------
--------------+--------------+----------------------+------------------- 最初に6ビット| P-ビット| PLEN| パケット| 有効搭載量に関する所見|(ペイロードhdr。)| | --------------+--------------+----------------------+------------------- 100000 | 1 | 0 | 絵| 典型的な絵100000| 1 | >0| 絵| 注意UFEP 1xxxxx| 1 | 0 | かたまり/部分/エオス/EOSBS| 可能なGNs 1xxxxxを見てください。| 1 | >0| かたまり/部分| 可能なGNs Xxxxxxを見てください。| 0 | 0 | フォローオン| Xxxxxx| 0 | >0| フォローオン| 内部のResync--------------+--------------+----------------------+-------------------
The details regarding the possible values of the five bit Group Number (GN) field which follows the initial "1" bit when the P-bit is "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3 of [4].
初期に続く5ビットのGroup Number(GN)分野の可能な値に関する詳細である、「P-ビットが「[4]のコネセクション5.2.3はかたまり、部分、エオス、またはEOSBSパケットのための1インチに見つけられます。」であるときに噛み付かれた1インチ
As defined in this specification, every start of a coded frame (as indicated by the presence of a PSC) has to be encapsulated as a picture segment packet. If the whole coded picture fits into one
この仕様に基づき定義されるように、コード化されたフレーム(PSCの存在によって示されるように)のあらゆる始まりが絵のセグメントパケットとして要約されなければなりません。 全体が絵の発作を1つにコード化したなら
Bormann, et. al. Standards Track [Page 13] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[13ページ]RFC2429時間.263+10月1998
packet of reasonable size (which is dependent on the connection characteristics), this is the only type of packet that may need to be used. Due to the high compression ratio achieved by H.263+ it is often possible to use this mechanism, especially for small spatial picture formats such as QCIF and typical Internet packet sizes around 1500 bytes.
妥当なサイズ(接続の特性に依存している)のパケット、これは使用される必要があるかもしれない唯一のタイプのパケットです。 H.263によって達成された高い圧縮比のために、+ それは特にQCIFやおよそ1500バイトの典型的なインターネットパケットサイズなどの小さい空間的な絵の形式にこのメカニズムを使用するのにおいてしばしば可能です。
If the complete coded frame does not fit into a single packet, two different ways for the packetization may be chosen. In case of very low or zero packet loss probability, one or more Follow-on packets may be used for coding the rest of the picture. Doing so leads to minimal coding and packetization overhead as well as to an optimal use of the maximal packet size, but does not provide any added error resilience.
完全なコード化されたフレームが単一のパケットに収まらないなら、packetizationのための2つの異なった方法が選ばれるかもしれません。 まさしくその安値にもかかわらず、パケット紛失率の場合にはではなく、1つ以上のFollowオンなパケットが、絵の残りをコード化するのに使用されるかもしれません。 そうするのは最大限度のパケットサイズの最適の使用に関して最小量のコード化とまた、packetizationオーバーヘッドに通じますが、少しの加えられた誤り弾力も提供しません。
The alternative is to break the picture into reasonably small partitions - called Segments - (by using the Slice or GOB mechanism), that do offer synchronization points. By doing so and using the Picture Segment payload with PLEN>0, decoding of the transmitted packets is possible even in such cases in which the Picture packet containing the picture header was lost (provided any necessary reference picture is available). Picture Segment packets can also be used in conjunction with Follow-on packets for large segment sizes.
代替手段が絵を合理的に小さいパーティション(Segmentsと呼ばれる)に細かく分ける(SliceかGOBメカニズムを使用することによって)ことであり、それは同期ポイントを提供します。 PLEN>0と共にそうして、Picture Segmentペイロードを使用することによって、伝えられたパケットの解読は絵のヘッダーを含むPictureパケットが失われたそのような場合でさえ可能です(何か必要な参照の絵が利用可能であるなら)。 また、大きいセグメントサイズのためのFollowオンなパケットに関連して絵のSegmentパケットを使用できます。
7. Security Considerations
7. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1], and any appropriate RTP profile (for example [2]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations.
この仕様に基づき定義されたペイロード書式を使用するRTPパケットがRTP仕様[1]、およびどんな適切なRTPプロフィールでも議論したセキュリティ問題を条件としています。(例えば、[2])。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
潜在的サービスの否定の脅威は、データencodingsのために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。 しかしながら、このコード化は少しの重要な非の一様性も示しません。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast
どんなIPベースのプロトコル、いくつかの事情ではも、受信機は単に必要であるか望まれないあまりに多くのパケットの領収書で積みすぎられるかもしれません。 ネットワーク層認証は望まれないソースからパケットを捨てるのに使用されるかもしれませんが、認証自体の加工費は高過ぎるかもしれません。 マルチキャストで
Bormann, et. al. Standards Track [Page 14] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[14ページ]RFC2429時間.263+10月1998
environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
環境、特定のソースを取り除くのは、受信機が、どのソースがそれに達することができるかを選択するのを許容するためにIGMP[5]の将来のバージョンとマルチキャストルーティング・プロトコルで実行されるかもしれません。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式の安全レビューはRTP仕様によるそれらを超えてどんな追加問題も見つけませんでした。
8. Addresses of Authors
8. 作者のアドレス
Carsten Bormann Universitaet Bremen FB3 TZI EMail: cabo@tzi.org Postfach 330440 Phone: +49.421.218-7024 D-28334 Bremen, GERMANY Fax: +49.421.218-7000
カルステンボルマンUniversitaetブレーメンFB3 TZIはメールします: cabo@tzi.org Postfach330440は以下に電話をします。 +49.421 .218-7024 D-28334ブレーメン、ドイツFax: +49.421.218-7000
Linda Cline Intel Corp. M/S JF3-206 EMail: lscline@jf.intel.com 2111 NE 25th Avenue Phone: +1 503 264 3501 Hillsboro, OR 97124, USA Fax: +1 503 264 3483
リンダクラインインテル社M/S JF3-206はメールします: 第25 lscline@jf.intel.com 2111Neアベニュー電話: +1 503 264 3501ヒースボロー、または97124、米国Fax: +1 503 264 3483
Gim Deisher Intel Corp. M/S JF2-78 EMail: gim.l.deisher@intel.com 2111 NE 25th Avenue Phone: +1 503 264 3758 Hillsboro, OR 97124, USA Fax: +1 503 264 9372
Gim Deisherインテル社M/S JF2-78はメールします: 第25 gim.l.deisher@intel.com 2111Neアベニュー電話: +1 503 264 3758ヒースボロー、または97124、米国Fax: +1 503 264 9372
Tom Gardos Intel Corp. M/S JF2-78 EMail: thomas.r.gardos@intel.com 2111 NE 25th Avenue Phone: +1 503 264 6459 Hillsboro, OR 97124, USA Fax: +1 503 264 9372
トムGardosインテル社M/S JF2-78はメールします: 第25 thomas.r.gardos@intel.com 2111Neアベニュー電話: +1 503 264 6459ヒースボロー、または97124、米国Fax: +1 503 264 9372
Christian Maciocco Intel Corp. M/S JF3-206 EMail: christian.maciocco@intel.com 2111 NE 25th Avenue Phone: +1 503 264 1770 Hillsboro, OR 97124, USA Fax: +1 503 264 9428
クリスチャンのMacioccoインテル社M/S JF3-206はメールします: 第25 christian.maciocco@intel.com 2111Neアベニュー電話: +1 503 264 1770ヒースボロー、または97124、米国Fax: +1 503 264 9428
Donald Newell Intel Corp. M/S JF3-206 EMail: donald.newell@intel.com 2111 NE 25th Avenue Phone: +1 503 264 9234 Hillsboro, OR 97124, USA Fax: +1 503 264 9428
ドナルドヌーエルインテル社M/S JF3-206はメールします: 第25 donald.newell@intel.com 2111Neアベニュー電話: +1 503 264 9234ヒースボロー、または97124、米国Fax: +1 503 264 9428
Bormann, et. al. Standards Track [Page 15] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[15ページ]RFC2429時間.263+10月1998
Joerg Ott Universitaet Bremen FB3 TZI EMail: jo@tzi.org Postfach 330440 Phone: +49.421.218-7024 D-28334 Bremen, GERMANY Fax: +49.421.218-7000
ヨルクオットUniversitaetブレーメンFB3 TZIはメールします: jo@tzi.org Postfach330440は以下に電話をします。 +49.421 .218-7024 D-28334ブレーメン、ドイツFax: +49.421.218-7000
Gary Sullivan PictureTel Corp. M/S 635 EMail: garys@pictel.com 100 Minuteman Road Phone: +1 978 623 4324 Andover, MA 01810, USA Fax: +1 978 749 2804
ゲーリーサリバンPictureTel社のM/S635はメールされます: garys@pictel.com 100ミニットマン道路電話: +1 4324アンドーバー、978 623MA 01810、米国Fax: +1 978 749 2804
Stephan Wenger Technische Universitaet Berlin FB13 Sekr. FR 6-3 EMail: stewe@cs.tu-berlin.de Franklinstr. 28/29 Phone: +49.30.314-73160 D-10587 Berlin, GERMANY Fax: +49.30.314-25156
シュテファンウェンガーTechnische UniversitaetベルリンFB13 Sekr。 FR6-3はメールします: stewe@cs.tu-berlin.de Franklinstr。 28/29は以下に電話をします。 +49.30 .314-73160 D-10587ベルリン、ドイツFax: +49.30.314-25156
Chad Zhu Intel Corp. M/S JF3-202 EMail: czhu@ix.netcom.com 2111 NE 25th Avenue Phone: +1 503 264 6004 Hillsboro, OR 97124, USA Fax: +1 503 264 1805
チャド朱インテル社M/S JF3-202はメールします: 第25 czhu@ix.netcom.com 2111Neアベニュー電話: +1 503 264 6004ヒースボロー、または97124、米国Fax: +1 503 264 1805
9. References
9. 参照
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP : A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[2] Schulzrinne, H., "RTP Profile for Audio and Video Conference with
Minimal Control", RFC 1890, January 1996.
[2]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
[3] "Video Coding for Low Bit Rate Communication," ITU-T
Recommendation H.263, March 1996.
[3] 「少ないビット伝送速度コミュニケーションのためのビデオ符号化」、ITU-T推薦H.263、1996年3月。
[4] "Video Coding for Low Bit Rate Communication," ITU-T
Recommendation H.263, January 1998.
[4] 「少ないビット伝送速度コミュニケーションのためのビデオ符号化」、ITU-T推薦H.263、1998年1月。
[5] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[5]TurlettiとT.とC.Huitema、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
[6] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190,
September 1997.
[6] 朱、C.、「H.263ビデオストリームのためのRTP有効搭載量形式」、RFC2190、1997年9月。
[7] S. Wenger, "Video Redundancy Coding in H.263+," Proc. Audio-
Visual Services over Packet Networks, Aberdeen, U.K., September
1997.
[7]S.ウェンガー、「H.263+でのビデオ冗長コード化」、Proc。 1997年9月のパケット網、アバディーン、イギリスの上のオーディオの視覚サービス。
Bormann, et. al. Standards Track [Page 16] RFC 2429 H.263+ October 1998
etボルマン、アル。 標準化過程[16ページ]RFC2429時間.263+10月1998
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Bormann, et. al. Standards Track [Page 17]
etボルマン、アル。 標準化過程[17ページ]
一覧
スポンサーリンク
