RFC4629 日本語訳
4629 RTP Payload Format for ITU-T Rec. H.263 Video. J. Ott, C.Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. January 2007. (Format: TXT=67231 bytes) (Obsoletes RFC2429) (Updates RFC3555) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Ott
Request for Comments: 4629 Helsinki University of Technology
Obsoletes: 2429 C. Bormann
Updates: 3555 Universitaet Bremen TZI
Category: Standards Track G. Sullivan
Microsoft
S. Wenger
Nokia
R. Even, Ed.
Polycom
January 2007
Network Working Group J. Ott Request for Comments: 4629 Helsinki University of Technology Obsoletes: 2429 C. Bormann Updates: 3555 Universitaet Bremen TZI Category: Standards Track G. Sullivan Microsoft S. Wenger Nokia R. Even, Ed. Polycom January 2007
RTP Payload Format for ITU-T Rec. H.263 Video
RTP Payload Format for ITU-T Rec. H.263 Video
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 IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract
Abstract
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.
The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.
The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type in RFC 3555.
The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type in RFC 3555.
Ott, et al. Standards Track [Page 1] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 1] RFC 4629 H.263 RTP Payload Format January 2007
Table of Contents
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. New H.263 Features ..............................................3
3. Usage of RTP ....................................................4
3.1. RTP Header Usage ...........................................5
3.2. Video Packet Structure .....................................6
4. Design Considerations ...........................................7
5. H.263+ Payload Header ...........................................9
5.1. General H.263+ Payload Header ..............................9
5.2. Video Redundancy Coding Header Extension ..................10
6. Packetization Schemes ..........................................12
6.1. Picture Segment Packets and Sequence Ending
Packets (P=1) .............................................12
6.1.1. Packets that begin with a Picture Start Code .......12
6.1.2. Packets that begin with GBSC or SSC ................13
6.1.3. Packets that begin with an EOS or EOSBS Code .......14
6.2. Encapsulating Follow-on Packet (P=0) ......................15
7. Use of this Payload Specification ..............................15
8. Media Type Definition ..........................................17
8.1. Media Type Registrations ..................................17
8.1.1. Registration of Media Type video/H263-1998 .........17
8.1.2. Registration of Media Type video/H263-2000 .........21
8.2. SDP Usage .................................................22
8.2.1. Usage with the SDP Offer Answer Model ..............23
9. Backward Compatibility to RFC 2429 .............................25
9.1. New Optional Parameters for SDP ...........................25
10. IANA Considerations ...........................................25
11. Security Considerations .......................................25
12. Acknowledgments ...............................................26
13. Changes from Previous Versions of the Documents ...............26
13.1. Changes from RFC 2429 ....................................26
13.2. Changes from RFC 3555 ....................................26
14. References ....................................................26
14.1. Normative References .....................................26
14.2. Informative References ...................................27
1. Introduction ....................................................3 1.1. Terminology ................................................3 2. New H.263 Features ..............................................3 3. Usage of RTP ....................................................4 3.1. RTP Header Usage ...........................................5 3.2. Video Packet Structure .....................................6 4. Design Considerations ...........................................7 5. H.263+ Payload Header ...........................................9 5.1. General H.263+ Payload Header ..............................9 5.2. Video Redundancy Coding Header Extension ..................10 6. Packetization Schemes ..........................................12 6.1. Picture Segment Packets and Sequence Ending Packets (P=1) .............................................12 6.1.1. Packets that begin with a Picture Start Code .......12 6.1.2. Packets that begin with GBSC or SSC ................13 6.1.3. Packets that begin with an EOS or EOSBS Code .......14 6.2. Encapsulating Follow-on Packet (P=0) ......................15 7. Use of this Payload Specification ..............................15 8. Media Type Definition ..........................................17 8.1. Media Type Registrations ..................................17 8.1.1. Registration of Media Type video/H263-1998 .........17 8.1.2. Registration of Media Type video/H263-2000 .........21 8.2. SDP Usage .................................................22 8.2.1. Usage with the SDP Offer Answer Model ..............23 9. Backward Compatibility to RFC 2429 .............................25 9.1. New Optional Parameters for SDP ...........................25 10. IANA Considerations ...........................................25 11. Security Considerations .......................................25 12. Acknowledgments ...............................................26 13. Changes from Previous Versions of the Documents ...............26 13.1. Changes from RFC 2429 ....................................26 13.2. Changes from RFC 3555 ....................................26 14. References ....................................................26 14.1. Normative References .....................................26 14.2. Informative References ...................................27
Ott, et al. Standards Track [Page 2] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 2] RFC 4629 H.263 RTP Payload Format January 2007
1. Introduction
1. Introduction
This document specifies an RTP payload header format applicable to the transmission of video streams based on the 1998 and 2000 versions of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.263 [H263]. Because the 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 and is recommended for this use by new implementations. This format replaces the payload format in RFC 2190 [RFC2190], which continues to be used by some existing implementations, and can be useful for backward compatibility. New implementations supporting H.263 SHALL use the payload format described in this document. RFC 2190 is moved to historic status [RFC4628].
This document specifies an RTP payload header format applicable to the transmission of video streams based on the 1998 and 2000 versions of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.263 [H263]. Because the 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 and is recommended for this use by new implementations. This format replaces the payload format in RFC 2190 [RFC2190], which continues to be used by some existing implementations, and can be useful for backward compatibility. New implementations supporting H.263 SHALL use the payload format described in this document. RFC 2190 is moved to historic status [RFC4628].
The document updates the media type registration that was previously in RFC 3555 [RFC3555].
The document updates the media type registration that was previously in RFC 3555 [RFC3555].
This document obsoletes RFC 2429 [RFC2429].
This document obsoletes RFC 2429 [RFC2429].
1.1. Terminology
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant RTP implementations.
2. New H.263 Features
2. New H.263 Features
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. In this document, the 1998 version is referred to as H.263+ and the 2000 version as H.263++.
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. In this document, the 1998 version is referred to as H.263+ and the 2000 version as H.263++.
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 [H263] for more information on coding options.
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 [H263] 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 for 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 for use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries.
Ott, et al. Standards Track [Page 3] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 3] RFC 4629 H.263 RTP Payload Format January 2007
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 may 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 Extended RTP Profile for RTP Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a back channel mechanism.
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 may 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 Extended RTP Profile for RTP Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a back channel mechanism.
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 that 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 that the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both.
H.263++ added some new functionalities. Among the new functionalities are support for interlace mode, specified in H.263, annex W.6.3.11, and the definition of profiles and levels in H.263 annex X.
H.263++ added some new functionalities. Among the new functionalities are support for interlace mode, specified in H.263, annex W.6.3.11, and the definition of profiles and levels in H.263 annex X.
3. Usage of RTP
3. 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, the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start code, the first 2 (all-zero) bytes of the start code shall be 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, the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start code, the first 2 (all-zero) bytes of the start code shall be removed and replaced by setting an indicator bit in the payload header.
Ott, et al. Standards Track [Page 4] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 4] RFC 4629 H.263 RTP Payload Format January 2007
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 5; it updates the one specified in RFC 2190. 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 5; it updates the one specified in RFC 2190. This section defines the usage of the RTP fixed header and H.263+ video packet structure.
3.1. RTP Header Usage
3.1. RTP Header Usage
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header used for H.263+ video streams are further emphasized here.
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header used for H.263+ video streams are further emphasized here.
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 RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, a payload type in the dynamic range shall be chosen by the sender.
Payload Type (PT): The RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, a payload type in the dynamic range shall be chosen by the sender.
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 ITU-T Recommendation H.263 [H263] 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, the same as that of the RTP payload for H.261 stream [RFC2032]. Since both the H.263+ data and the RTP header contain time information, that timing information must 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
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 ITU-T Recommendation H.263 [H263] 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, the same as that of the RTP payload for H.261 stream [RFC2032]. Since both the H.263+ data and the RTP header contain time information, that timing information must 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
Ott, et al. Standards Track [Page 5] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 5] RFC 4629 H.263 RTP Payload Format January 2007
increment between each coded H.263+ picture should therefore be an integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 30/1.001 Hz NTSC; 3600 for 25 Hz PAL; 3750 for 24 Hz film; and 1500, 1250, or 1200 for the computer display update rates of 60, 72, or 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.
increment between each coded H.263+ picture should therefore be an integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 30/1.001 Hz NTSC; 3600 for 25 Hz PAL; 3750 for 24 Hz film; and 1500, 1250, or 1200 for the computer display update rates of 60, 72, or 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.
3.2. Video Packet Structure
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RTP Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Payload Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Compressed Data Stream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 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.
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.
Ott, et al. Standards Track [Page 6] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 6] RFC 4629 H.263 RTP Payload Format January 2007
4. Design Considerations
4. 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 cases when 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 cases when 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 [H263]
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 that is represented as
a distinct decodable region. In particular, slices can have a
size that 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 [H263] 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 that is represented as a distinct decodable region. In particular, slices can have a size that 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 that 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
implementations). Optimally, each packet will contain only one
slice.
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 that 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 implementations). Optimally, each packet will contain only one slice.
Ott, et al. Standards Track [Page 7] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 7] RFC 4629 H.263 RTP Payload Format January 2007
o The independent segment decoding (ISD) described in Annex R of
[H263] prevents any data dependency across slice or GOB boundaries
in the reference picture. It can be utilized to improve
resiliency further in high loss conditions.
o The independent segment decoding (ISD) described in Annex R of [H263] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to improve resiliency further 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 (especially in cases with high packet loss probability in
which picture header contents are not expected to be highly
predictable) that the sender may find it advisable always to set
the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video
bitstream. (See [H263] 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 (especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable) that the sender may find it advisable always to set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263] 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.
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.
Ott, et al. Standards Track [Page 8] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 8] RFC 4629 H.263 RTP Payload Format January 2007
5. H.263+ Payload Header
5. H.263+ Payload Header
For H.263+ video streams, each RTP packet shall carry only one H.263+ video packet. The H.263+ payload header shall always be present for each H.263+ video packet. The payload header is of variable length. A 16-bit field of the general payload header, defined in 5.1, 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 shall carry only one H.263+ video packet. The H.263+ payload header shall always be present for each H.263+ video packet. The payload header is of variable length. A 16-bit field of the general payload header, defined in 5.1, 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, PLEN equal to 0 and no VRC information being 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, PLEN equal to 0 and no VRC information being present.
The remainder of this section defines the various components of the RTP payload header. Section 6 defines the various packet types that are used to carry different types of H.263+ coded data, and Section 7 summarizes how to distinguish between the various packet types.
The remainder of this section defines the various components of the RTP payload header. Section 6 defines the various packet types that are used to carry different types of H.263+ coded data, and Section 7 summarizes how to distinguish between the various packet types.
5.1. General H.263+ Payload Header
5.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
RR: 5 bits
Reserved bits. It SHALL be zero and MUST be ignored by receivers.
Reserved bits. It SHALL be zero and MUST be ignored by receivers.
P: 1 bit
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.
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.
Ott, et al. Standards Track [Page 9] RFC 4629 H.263 RTP Payload Format January 2007
Ott, et al. Standards Track [Page 9] RFC 4629 H.263 RTP Payload Format January 2007
V: 1 bit
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 5.2.
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 5.2.
PLEN: 6 bits
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 that the length reflects the omission of the
first two bytes of the picture start code (PSC). See Section 6.1.
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 that the length reflects the omission of the first two bytes of the picture start code (PSC). See Section 6.1.
PEBIT: 3 bits
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.
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.
5.2. Video Redundancy Coding Header Extension
5.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 [H263]. By having multiple "threads" of independently inter-frame predicted pictures, damage to an individual frame will cause distortions only within its own thread, leaving 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 that 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 [Vredun].
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 [H263]. By having multiple "threads" of independently inter-frame predicted pictures, damage to an individual frame will cause distortions only within its own thread, leaving 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 that 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 [Vredun].
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 that 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, but each thread is predicted only from the sync frames
P-絵の時のスケーラビリティを、参照絵の選択モードの別の使用であり、それぞれの同時性フレームのコピー1部だけを送ってもよいVRCの特別なケースであると考えることができます。 それはBの絵の使用で引き起こされた増加する遅れなしで時のスケーラビリティの糸のベースの方法を提供します。 また、この使用で、絵の最初の糸で送られた同時性フレームは結果として起こるフレームレートを増加させるように同時性フレームの間に時間的に落ちる絵の2番目の糸の予測に使用されます。 この使用で、後の絵を解読する能力に害を及ぼさないで、2番目の糸の絵は、ビット伝送速度の減少を得るために捨てられるか、または複雑さを解読できます。 3分の1以上は、縫うように通って、また、加えることができますが、各糸は単に同時性フレームから予測されます。
Ott, et al. Standards Track [Page 10] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[10ページ]RFC RTP有効搭載量形式2007年1月
(which are sent at least in thread 0) or from frames within the same thread.
(少なくとも糸0)か同じ糸の中のフレームから送られる。
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, the thread-id, and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension.
VRCデータ・ストリームは完全に含まれた(すべてのH.263+データのような)自己ですが、輸送階層構造実現はそれぞれの糸の現在の損害状態の周りで心得があるのが、役に立つかもしれません。 インターネットでは、この状態は、マーカービット、RTPヘッダーの一連番号、糸イド、および旋回「1糸あたりのパケット」番号を観察することによって、容易に決定できます。 後者の2つの番号がVRCヘッダー拡張子でコード化されます。
The format of the VRC header extension is as follows:
VRCヘッダー拡張子の形式は以下の通りです:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | TID| トリン|S| +-+-+-+-+-+-+-+-+
TID: 3 bits
TID: 3ビット
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 representations of the sync frames equal to or better than higher thread numbers in the absence of data corruption or loss. See [Vredun] for a detailed discussion of VRC.
IDに糸を通してください。 最大7個の糸が許容されています。 H.263+VRCデータの各フレームは参考情報だけとして同じ糸の中に同時性フレームかフレームを使用するでしょう。 コンベンションによって、糸0は「正準な」糸であると予想されます。(それは、同時性フレームが理想的に使用されるべきである糸です)。 不正の場合か糸の0表現の損失では、デコーダは、より大きい糸の番号がある同時性フレームの表現を使用できます。 下側の糸の番号がデータの汚染か損失が不在のとき等しいか、より大きい糸の番号より良い同時性フレームの表現を含むと予想されます。 VRCの詳細な論議に関して[Vredun]を見てください。
Trun: 4 bits
トリン: 4ビット
Monotonically increasing (modulo 16) 4-bit number counting the packet number within each thread.
単調に、それぞれ中でパケット番号を数える増加する(法16)4ビットの数が縫うように通ります。
S: 1 bit
S: 1ビット
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
少し、それは、同時性フレームにはパケット含有量があるのを示します。 VRCを使用するエンコーダは同じ「同時性」の絵のいくつかの表現を送るかもしれません、絵のどの糸が誤りかパケット損失で崩壊するかにかかわらず特定の絵の少なくとも1つの表現のレセプションが確実にされるのを(少なくとも1個の糸の中に)確実にするために。 そして、どんな糸の予測にも同時性の絵を使用できます。 パケット損失が起こっていないなら糸0の同時性フレームコンテンツを使用できて、他の糸のものを捨てることができる、(同様である、他の糸) 糸0は「正準な」糸であると考えられます。その使用は望ましいです。
Ott, et al. Standards Track [Page 11] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[11ページ]RFC RTP有効搭載量形式2007年1月
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 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 [H263].
すべての他のものに。 下側の糸の番号を持っているパケットのコンテンツは、より大きい糸の番号があるそれらより高い処理と配送優先度を持ちながら、みなされるものとします。 その結果最初に、与えられた同時性フレームの下側の糸の番号を持っているのを損失なしの下のデコーダに渡すものとして、低い時間ジターが条件とさせるパケット。(そのパケットはN Annex[H263]の指定されるとしての、より高い番号付の糸の同時性コンテンツを捨てることをもたらすでしょう)。
6. Packetization Schemes
6. Packetization計画
6.1. Picture Segment Packets and Sequence Ending Packets (P=1)
6.1. 絵のセグメントパケットと系列の終わりのパケット(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噛み付いている旗で示されるように存在しているかもしれません。
6.1.1. Packets that begin with a Picture Start Code
6.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
コード化された絵の全体か始まりを含むどんなパケットも、絵のスタートコード(PSC)の位置で始まって、通常、絵のヘッダーの複本なしでカプセルに入れられるはずです。 言い換えれば、通常そのような場合におけるPLEN=0。 しかしながら、コード化された画像が不完全な絵のヘッダーを含んでいる、(UFEPが等しい、「0インチ)、完全の当時のa表現、(UFEPは「1インチ) 絵のヘッダーは提供するためにpacketizationの間、取り付けられるかもしれないこと」と等しいです。
Ott, et al. Standards Track [Page 12] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[12ページ]RFC RTP有効搭載量形式2007年1月
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:
より大きい誤り弾力。 したがって、以下の条件の両方が適用されないなら、PLENは絵のスタートコードの位置で始まるパケットに関するゼロになるでしょう:
1) The picture header in the H.263+ bitstream payload is incomplete
(PLUSPTYPE present and UFEP="000").
1) H.263+bitstreamペイロードの絵のヘッダーが不完全である、(PLUSPTYPEが提示して、UFEPが等しい、「0インチ)」
2) The additional picture header that is attached is not incomplete
(UFEP="001").
2) 付属追加の絵ヘッダーが不完全でない、(UFEPが等しい、「1インチ)」
A packet that 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、PSC+++++++++++++++++++++++++++++++++の0バイト
6.1.2. Packets that begin with GBSC or SSC
6.1.2. GBSCかSSCと共に始まるパケット
For a packet that begins at the location of a GOB or slice start code (GBSC), PLEN may be zero or 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 GOB Frame ID (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か1つの部分の位置でスタートコード(GBSC)を始めるパケットに関しては、PLENはゼロか非零であるかもしれません、余分な絵のヘッダーがパケットに取り付けられるかどうかによって。 非常に低いパケット損失率がある環境かそれとも絵のヘッダー含有量がいつ非常にめったに変化しそうにないかとき(缶以外に、H.263+のGOB Frame ID(GFID)構文から、検出されてください)、絵のヘッダーの余分なコピーは必要ではありません。 しかしながら、それほど理想的でない事情では、余分な絵のヘッダーは高められた誤り弾力のために取り付けられるべきです、そして、存在はPLEN>0によって示されます。
Ott, et al. Standards Track [Page 13] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[13ページ]RFC RTP有効搭載量形式2007年1月
Assuming a PLEN of 9 and P=1, below is an example of a packet that begins with a byte-aligned GBSC or a Slice Start Code (SSC):
9とP=1のPLENを仮定して、バイトで並べられたGBSCかSlice Start Code(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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : GBSC/SSCから最初の2なしで0バイト+++++++++++++++++++++++++++++++++を始めるデータ
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')だけがペイロードヘッダーに含まれているのに注意してください。 バイトの並べられた絵のスタートコードがある完全なH.263+絵のヘッダーは便利に集まることができます、必要であるなら、受ける側になって'0'ビット導く16をprependingすることによって。
6.1.3. Packets that begin with an EOS or EOSBS Code
6.1.3. EOSと共に始まるパケットか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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ott, et al. Standards Track [Page 14] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[14ページ]RFC RTP有効搭載量形式2007年1月
6.2. Encapsulating Follow-on Packet (P=0)
6.2. フォローオンパケットをカプセルに入れります。(P=0)
A Follow-on Packet contains a number of bytes of coded H.263+ data that do 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 that can be used as resync points. The use of an attached copy of a picture header for a Follow-on Packet is 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.
FollowオンなPacketは同期ポイントで始まらない多くのバイトのコード化されたH.263+データを含んでいます。 すなわち、FollowオンなPacketはPicture、GOB、Slice、EOS、またはEOSBSヘッダーから始まりません、そして、それはmacroblock境界で始まるかもしれません。 FollowオンなPacketsが同期ポイントで始まらないので、FollowオンなPacketの始めのデータは独自に解読可能ではありません。 そのようなパケット、P=0、いつも。 FollowオンなPacketの前のパケットが失せたなら、受信機はそのFollowオンなPacketを捨てるかもしれません、他のすべての次のFollowオンなPacketsと同様に。 より良い振舞いは受信機が何かスタートコードが「再-同時性」が指すとき使用できるパケットの内部で見つけられるかどうか決定するためにもちろんパケットペイロード含有量の内部をスキャンするだろうことです。 パケットの内部かいくらかのその後のFollowオンなPacketが「再-同時性」コードを含んでいる場合にだけ、絵のヘッダーの付属コピーのFollowオンなPacketの使用は役に立ちます、GOBや部分スタートコードのように。 パケットの内部に「再-同時性」を許容するかもしれないので、PLEN>0は許容されています。 また、デコーダは次のセグメントか絵のパケットで再連動するかもしれません。
Here is an example of a Follow-on Packet (with PLEN=0):
ここに、FollowオンなPacket(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データ++++++++++++++++++++++++++++++++、-
7. Use of this Payload Specification
7. この有効搭載量Specificationの使用
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オンなPacketの間には、どんな構文の違いもありません、FollowオンなPacketsのための系列の絵のセグメントのための指示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/部分ヘッダ記述を見てください):
Ott, et al. Standards Track [Page 15] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[15ページ]RFC RTP有効搭載量形式2007年1月
-------------+--------------+----------------------+---------------- 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 that 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 H.263 [H263].
初期に続く5ビットのGroup Number(GN)分野の可能な値に関する詳細である、「P-ビットが「かたまり、部分、エオス、またはEOSBSパケットのための1インチは.3セクション5.2H.263[H263]で見つけられます。」であるときに噛み付かれた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 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 Quarter Common Intermediate Format (QCIF) and typical Internet packet sizes around 1500 bytes.
この仕様に基づき定義されるように、コード化されたフレーム(PSCの存在によって示されるように)のあらゆる始まりが絵のセグメントパケットとして要約されなければなりません。 全体が妥当なサイズ(接続の特性に依存している)の1つのパケットに絵の発作をコード化したなら、これは使用される必要があるかもしれない唯一のタイプのパケットです。 H.263+によって達成された高い圧縮比のために、このメカニズムを使用するのはしばしば可能です、特にQuarter共通中間フォーマットなどの小さい空間的な絵の形式(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つの異なった方法が選ばれるかもしれません。 まさしくその安値にもかかわらず、パケット紛失率の場合にはではなく、1FollowオンなPacketsが、絵の残りをコード化するのに使用されるかもしれません。 そうするのは最小量のコード化と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 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オンなPacketsに関連して絵のSegmentパケットを使用できます。
Ott, et al. Standards Track [Page 16] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[16ページ]RFC RTP有効搭載量形式2007年1月
8. Media Type Definition
8. メディア型定義
This section specifies optional parameters that MAY be used to select optional features of the H.263 codec. The parameters are specified here as part of the Media Type registration for the ITU-T H.263 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
このセクションはH.263コーデックに関するオプション機能を選択するのに使用されるかもしれない任意のパラメタを指定します。ITU-T H.263コーデックのためのメディアType登録の一部としてここでパラメタを指定します。また、Session記述プロトコル(SDP)[RFC4566]へのパラメタに関するマッピングをSDPを使用するアプリケーションに提供します。 メディアがストリングをタイプするので複数のパラメタSHOULDが急送されて、パラメタ=のセミコロンで切り離されたリストの形では、値は対にされます。
8.1. Media Type Registrations
8.1. メディアは登録証明書をタイプします。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555].
このセクションはこのペイロード形式に関連しているメディアタイプと名前について説明します。 セクションはRFC3555[RFC3555]の前の登録済みのバージョンをアップデートします。
8.1.1. Registration of Media Type video/H263-1998
8.1.1. メディアタイプビデオ/H263-1998の登録
Type name: video
型名: ビデオ
Subtype name: H263-1998
Subtypeは以下を命名します。 H263-1998
Required parameters: None
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF
resolution. Permissible values are integer values from 1 to 32,
which correspond to a maximum frame rate of 30/(1.001 * the
specified value) frames per second.
SQCIF: MPI(最小のPicture Interval)をSQCIF解決に指定します。 1〜32まで許容値が整数値である、(1.001 *規定値) 1秒あたりのフレーム。(値は30/の最大のフレームレートに対応します)。
QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF
resolution. Permissible values are integer values from 1 to 32,
which correspond to a maximum frame rate of 30/(1.001 * the
specified value) frames per second.
QCIF: MPI(最小のPicture Interval)をQCIF解決に指定します。 1〜32まで許容値が整数値である、(1.001 *規定値) 1秒あたりのフレーム。(値は30/の最大のフレームレートに対応します)。
CIF: Specifies the MPI (Minimum Picture Interval) for CIF
resolution. Permissible values are integer values from 1 to 32,
which correspond to a maximum frame rate of 30/(1.001 * the
specified value) frames per second.
CIF: MPI(最小のPicture Interval)をCIF解決に指定します。 1〜32まで許容値が整数値である、(1.001 *規定値) 1秒あたりのフレーム。(値は30/の最大のフレームレートに対応します)。
CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF
resolution. Permissible values are integer values from 1 to 32,
which correspond to a maximum frame rate of 30/(1.001 * the
specified value) frames per second.
CIF4: MPI(最小のPicture Interval)を4CIF解決に指定します。 1〜32まで許容値が整数値である、(1.001 *規定値) 1秒あたりのフレーム。(値は30/の最大のフレームレートに対応します)。
Ott, et al. Standards Track [Page 17] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[17ページ]RFC RTP有効搭載量形式2007年1月
CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF
resolution. Permissible values are integer values from 1 to 32,
which correspond to a maximum frame rate of 30/(1.001 * the
specified value) frames per second.
CIF16: MPI(最小のPicture Interval)を16CIF解決に指定します。 1〜32まで許容値が整数値である、(1.001 *規定値) 1秒あたりのフレーム。(値は30/の最大のフレームレートに対応します)。
CUSTOM: Specifies the MPI (Minimum Picture Interval) for a
custom-defined resolution. The custom parameter receives three
comma-separated values, Xmax, Ymax, and MPI. The Xmax and Ymax
parameters describe the number of pixels in the X and Y axis and
must be evenly divisible by 4. The permissible values for MPI are
integer values from 1 to 32, which correspond to a maximum frame
rate of 30/(1.001 *the specified value).
習慣: MPI(最小のPicture Interval)を習慣で定義された解決に指定します。 カスタムパラメタは3つのコンマ区切り値、Xmax、Ymax、およびMPIを受けます。 XmaxとYmaxパラメタは、XとY軸でピクセル数について説明して、均等に説明するに違いありません。4で、分割可能です。 1〜32までMPIのための許容値が30/の最大のフレームレートに対応する整数値である、(1.001、指定が評価する*)
A system that declares support of a specific MPI for one of the
resolutions SHALL also implicitly support a lower resolution with
the same MPI.
また、SHALLがそれとなく同じMPIとの低い解像度を支持するという解決の1つのために特定のMPIのサポートを宣言するシステム。
A list of optional annexes specifies which annexes of H.263 are
supported. The optional annexes are defined as part of H263-1998,
H263-2000. H.263 annex X [H263] defines profiles that group
annexes for specific applications. A system that supports a
specific annex SHALL specify its support using the optional
parameters. If no annex is specified, then the stream is Baseline
H.263.
任意の別館のリストは、H.263のどの別館が支えられるかを指定します。 任意の別館はH263-1998、H263-2000の一部と定義されます。 H.263別館X[H263]は特定のアプリケーションのために別館を分類するプロフィールを定義します。 特定の別館SHALLを支持するシステムは、任意のパラメタを使用することでサポートを指定します。 別館が全く指定されないなら、流れはBaseline H.263です。
The allowed optional parameters for the annexes are "F", "I", "J",
"T", "K", "N", and "P".
別館のための許容任意のパラメタは、「F」と、「私」と、「J」と、「T」と、「K」と、「N」と、「P」です。
"F", "I", "J", and "T" if supported, SHALL have the value "1". If
not supported, they should not be listed or SHALL have the value
"0".
「F」、「私」、「J」、および「T」、支持されて、値「1インチ」を持つでしょう。 支持しないなら、それらを記載するべきではありませんか、またはSHALLには値「0インチ」があります。
"K" can receive one of four values 1 - 4:
「K」は4つの値1--4の1つを受け取ることができます:
1: Slices In Order, Non-Rectangular
1: 注文で、非長方形であることの形でコネを切ります。
2: Slices In Order, Rectangular
2: 注文で、長方形であることの形でコネを切ります。
3: Slices Not Ordered, Non-Rectangular
3: 非長方形であることの形で注文されなかった部分
4: Slices Not Ordered, Rectangular
4: 長方形であることの形で注文されなかった部分
"N": Reference Picture Selection mode - Four numeric choices
(1 - 4) are available, representing the following modes:
「N」: 参照Picture Selectionモード--以下のモードを表して、4つの数値選択(1--4)が利用可能です:
1: NEITHER: No back-channel data is returned from the decoder to
the encoder.
1: どちらも: デコーダからエンコーダまで戻っているチャンネルデータを全く返しません。
Ott, et al. Standards Track [Page 18] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[18ページ]RFC RTP有効搭載量形式2007年1月
2: ACK: The decoder returns only acknowledgment messages.
2: ACK: デコーダは承認メッセージだけを返します。
3: NACK: The decoder returns only non-acknowledgment messages.
3: ナック: デコーダは非承認メッセージだけを返します。
4: ACK+NACK: The decoder returns both acknowledgment and non-
acknowledgment messages.
4: ACK+ナック: デコーダは承認と非承認の両方にメッセージを返します。
No special provision is made herein for carrying back channel
information. The Extended RTP Profile for RTCP-based Feedback
[RFC4585] MAY be used as a back channel mechanism.
特別条項は、全く経路情報を戻すためにここに作られていません。 RTCPベースのFeedback[RFC4585]のためのExtended RTP Profileは逆チャンネルメカニズムとして使用されるかもしれません。
"P": Reference Picture Resampling, in which the following submodes
are represented as a number from 1 to 4:
「P」: 参照Picture Resampling:そこでは、以下の「副-モード」が数として1〜4まで表されます。
1: dynamicPictureResizingByFour
1: dynamicPictureResizingByFour
2: dynamicPictureResizingBySixteenthPel
2: dynamicPictureResizingBySixteenthPel
3: dynamicWarpingHalfPel
3: dynamicWarpingHalfPel
4: dynamicWarpingSixteenthPel
4: dynamicWarpingSixteenthPel
Example: P=1,3
例: P=1、3
PAR: Arbitrary Pixel Aspect Ratio. Defines the width:height ratio
by two colon-separated integers between 0 and 255. Default ratio
is 12:11, if not otherwise specified.
平価: 任意のピクセルアスペクト。 0と255の間の2つのコロンで切り離された整数に従って、幅: 高さの比を定義します。 別の方法で指定されないなら、デフォルト比は12:11です。
CPCF: Arbitrary (Custom) Picture Clock Frequency: CPCF is a
comma-separated list of eight parameters specifying a custom
picture clock frequency and the MPI (minimum picture interval) for
the supported picture sizes when using that picture clock
frequency. The first two parameters are cd, which is an integer
from 1 to 127, and cf, which is either 1000 or 1001. The custom
picture clock frequency is given by the formula 1800000/(cd*cf)
provided in the RTP Timestamp semantics in Section 3.1 above (as
specified in H.263 section 5.1.7). Following the values of cd and
cf, the remaining six parameters are SQCIFMPI, QCIFMPI, CIFMPI,
CIF4MPI, CIF16MPI, and CUSTOMMPI, which each specify an integer
MPI (minimum picture interval) for the standard picture sizes
SQCIF, QCIF, CIF, 4CIF, 16CIF, and CUSTOM, respectively, as
described above. The MPI value indicates a maximum frame rate of
1800000/(cd*cf*MPI) frames per second for MPI parameters having a
value in the range from 1 to 2048, inclusive. An MPI value of 0
specifies that the associated picture size is not supported for
the custom picture clock frequency. If the CUSTOMMPI parameter is
not equal to 0, the CUSTOM parameter SHALL also be present (so
CPCF: 任意(カスタム)の絵のクロック周波数: CPCFはその絵のクロック周波数を使用するときカスタム絵のクロック周波数とMPI(最小の絵の間隔)を支持された絵のサイズに指定する8つのパラメタのコンマで切り離されたリストです。 (1〜127までcdは整数です)。最初の2つのパラメタが、cdと、Cfです。(それは、1000か1001です)。 上でセクション3.1のRTP Timestamp意味論に提供された公式1800000/(cd*Cf)でカスタム絵のクロック周波数を与えます(H.263部5.1の.7で指定されるように)。 cdとCfの値に続いて、残っている6つのパラメタが、上で説明されるようにそれぞれSQCIFMPIと、QCIFMPIと、CIFMPIと、CIF4MPIと、CIF16MPIと、CUSTOMMPIとCUSTOMです。(それぞれ、CUSTOMMPIは標準の絵のサイズSQCIF、QCIF、CIF、4CIF、16CIFに整数MPI(最小の絵の間隔)を指定します)。 MPI値は1800000個の/(cd*Cf*MPI)1〜2048への範囲に値を持っているMPIパラメタのための秒あたりフレームの最大のフレーム料金を示します、包括的です。 0のMPI値は、関連絵のサイズがカスタム絵のクロック周波数のために支持されないと指定します。 0への同輩、CUSTOMパラメタがCUSTOMMPIパラメタであるならSHALLでなく、また、存在してください、(そのように。
Ott, et al. Standards Track [Page 19] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[19ページ]RFC RTP有効搭載量形式2007年1月
that the Xmax and Ymax dimensions of the custom picture size are
defined).
カスタム絵のサイズのXmaxとYmax次元は定義されます)
BPP: BitsPerPictureMaxKb. Maximum number of bits in units of 1024
bits allowed to represent a single picture. If this parameter is
not present, then the default value, based on the maximum
supported resolution, is used. BPP is integer value between 0 and
65536.
BPP: BitsPerPictureMaxKb。 ただ一つの絵を表すことができた1024ビットの単位の最大数のビット。 このパラメタが存在していないなら、最大の支持された解決に基づくデフォルト値は使用されています。 BPPは0と65536の間の整数値です。
HRD: Hypothetical Reference Decoder. See annex B of H.263
specification [H263]. This parameter, if supported, SHALL have
the value "1". If not supported, it should not be listed or SHALL
have the value "0".
HRD: 仮定している参照デコーダ。 H.263仕様[H263]の別館Bを見てください。 このパラメタであり、支持されるなら、SHALLには値「1インチ」があります。 支持しないなら、それを記載するべきではありませんか、またはSHALLには値「0インチ」があります。
Encoding considerations:
問題をコード化します:
This media type is framed and binary; see Section 4.8 in [RFC4288]
このメディアタイプは、縁どられて2進です。 中でセクション4.8を見てください。[RFC4288]
Security considerations: See Section 11 of RFC 4629
セキュリティ問題: RFC4629のセクション11を見てください。
Interoperability considerations:
相互運用性問題:
These are receiver options; current implementations will not send
any optional parameters in their SDP. They will ignore the
optional parameters and will encode the H.263 stream without any
of the annexes. Most decoders support at least QCIF and CIF fixed
resolutions, and they are expected to be available almost in every
H.263-based video application.
これらは受信機オプションです。 現在の実現はそれらのSDPのどんな任意のパラメタも送らないでしょう。 彼らは、任意のパラメタを無視して、別館のいずれなしでもH.263の流れをコード化するでしょう。 ほとんどのデコーダサポートの少なくともQCIFとCIFは解決を修理しました、そして、ほとんどあらゆるH.263ベースのビデオ・アプリケーションで利用可能であると予想されます。
Published specification: RFC 4629
広められた仕様: RFC4629
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Audio and video streaming and conferencing tools.
オーディオ、ビデオ・ストリーミング、および会議ツール。
Additional information: None
追加情報: なし
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Roni Even: roni.even@polycom.co.il
ロニ、同等: roni.even@polycom.co.il
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
用法における制限:
This media type depends on RTP framing and thus is only defined
for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time.
このメディアタイプは、RTP縁どりによって、その結果、転送のためにRTP[RFC3550]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送はこのとき、定義されません。
Ott, et al. Standards Track [Page 20] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[20ページ]RFC RTP有効搭載量形式2007年1月
Author: Roni Even
以下を書いてください。 ロニ、同等
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
8.1.2. Registration of Media Type video/H263-2000
8.1.2. メディアタイプビデオ/H263-2000の登録
Type name: video
型名: ビデオ
Subtype name: H263-2000
Subtypeは以下を命名します。 H263-2000
Required parameters: None
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
The optional parameters of the H263-1998 type MAY be used with
this media subtype. Specific optional parameters that may be used
with the H263-2000 type are as follows:
H263-1998タイプの任意のパラメタはこのメディア「副-タイプ」と共に使用されるかもしれません。 H263-2000タイプで使用されるかもしれない特定の任意のパラメタは以下の通りです:
PROFILE: H.263 profile number, in the range 0 through 10,
specifying the supported H.263 annexes/subparts based on H.263
annex X [H263]. The annexes supported in each profile are listed
in table X.1 of H.263 annex X. If no profile or H.263 annex is
specified, then the stream is Baseline H.263 (profile 0 of H.263
annex X).
以下の輪郭を描いてください。 H.263別館X[H263]に基づく支持されたH.263別館/下位区分を指定して、H.263は範囲で0〜10に数の輪郭を描きます。 H.263別館は指定されます、そして、各プロフィールで支えられた別館はIfノー、が輪郭を描くH.263別館X.のテーブルX.1に記載されているか、そして、流れがBaseline H.263(H.263別館Xのプロフィール0)です。
LEVEL: Level of bitstream operation, in the range 0 through 100,
specifying the level of computational complexity of the decoding
process. The level are described in table X.2 of H.263 annex X.
レベル: 解読過程の計算量のレベルを指定する範囲0〜100のbitstream操作のレベル。 レベルはH.263別館XのテーブルX.2で説明されます。
According to H.263 annex X, support of any level other than level
45 implies support of all lower levels. Support of level 45
implies support of level 10.
H.263別館Xに従って、レベル45以外のどんなレベルのサポートもすべての下のレベルのサポートを含意します。 レベル45のサポートはレベル10のサポートを含意します。
A system that specifies support of a PROFILE MUST specify the
supported LEVEL.
PROFILE MUSTのサポートを指定するシステムは支持されたLEVELを指定します。
INTERLACE: Interlaced or 60 fields indicates the support for
interlace display mode, as specified in H.263 annex W.6.3.11.
This parameter, if supported SHALL have the value "1". If not
supported, it should not be listed or SHALL have the value "0".
インターレース: 交錯するか60の分野がH.263別館W.6.3.11で指定されるようにインターレース表示モードのサポートを示します。 このパラメタであり、支持されるなら、SHALLには値「1インチ」があります。 支持しないなら、それを記載するべきではありませんか、またはSHALLには値「0インチ」があります。
Encoding considerations:
問題をコード化します:
This media type is framed and binary; see Section 4.8 in [RFC4288]
このメディアタイプは、縁どられて2進です。 中でセクション4.8を見てください。[RFC4288]
Security considerations: See Section 11 of RFC 4629
セキュリティ問題: RFC4629のセクション11を見てください。
Ott, et al. Standards Track [Page 21] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[21ページ]RFC RTP有効搭載量形式2007年1月
Interoperability considerations:
相互運用性問題:
The optional parameters PROFILE and LEVEL SHALL NOT be used with
any of the other optional parameters.
任意のパラメタのPROFILEとLEVEL SHALL NOT、他の任意のパラメタのいずれと共にも使用されてください。
Published specification: RFC 4629
広められた仕様: RFC4629
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Audio and video streaming and conferencing tools.
オーディオ、ビデオ・ストリーミング、および会議ツール。
Additional information: None
追加情報: なし
Person and email address to contact for further information :
詳細のために連絡する人とEメールアドレス:
Roni Even: roni.even@polycom.co.il
ロニ、同等: roni.even@polycom.co.il
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
用法における制限:
This media type depends on RTP framing and thus is only defined
for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time.
このメディアタイプは、RTP縁どりによって、その結果、転送のためにRTP[RFC3550]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送はこのとき、定義されません。
Author: Roni Even
以下を書いてください。 ロニ、同等
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport working group delegated from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
8.2. SDP Usage
8.2. SDP用法
The media types video/H263-1998 and video/H263-2000 are mapped to fields in the Session Description Protocol (SDP) as follows:
メディアタイプのビデオ/H263-1998とビデオ/H263-2000は以下のSession記述プロトコル(SDP)の分野に写像されます:
o The media name in the "m=" line of SDP MUST be video.
o メディアは「m=」で台詞を命名します。SDP MUSTでは、ビデオになってください。
o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998
or H263-2000 (the media subtype).
o "a=rtpmap"のコード化名はH263-1998かH263-2000が(メディア「副-タイプ」)であったならSDP MUSTに立ち並んでいます。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o "a=rtpmap"線におけるクロックレートは90000であるに違いありません。
o The optional parameters, if any, MUST be included in the "a=fmtp"
line of SDP. These parameters are expressed as a media type
string, in the form of a semicolon-separated list of
parameter=value pairs. The optional parameters PROFILE and LEVEL
SHALL NOT be used with any of the other optional parameters.
o SDPの"a=fmtp"線にもしあれば任意のパラメタを含まなければなりません。 メディアタイプがパラメタ=のセミコロンで切り離されたリストの形で値の組を結ぶとき、これらのパラメタは言い表されます。 任意のパラメタのPROFILEとLEVEL SHALL NOT、他の任意のパラメタのいずれと共にも使用されてください。
Ott, et al. Standards Track [Page 22] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[22ページ]RFC RTP有効搭載量形式2007年1月
8.2.1. Usage with the SDP Offer Answer Model
8.2.1. SDP申し出答えモデルがある用法
For offering H.263 over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
Offer/答えモデル[RFC3264]でSDPを使用することでRTPの上にH.263を提供するのに、以下の問題が必要です。
Codec options (F,I,J,K,N,P,T): These options MUST NOT appear unless the sender of these SDP parameters is able to decode those options. These options designate receiver capabilities even when sent in a "sendonly" offer.
コーデックオプション(F、I、J、K、N、P、T): これらのSDPパラメタの送付者がそれらのオプションを解読できないなら、これらのオプションは現れてはいけません。 "sendonly"申し出で送ると、これらのオプションは受信機能力を指定します。
Profile: The offer of a SDP profile parameter signals that the offerer can decode a stream that uses the specified profile. Each profile uses different H.263 annexes, so there is no implied relationship between them. An answerer SHALL NOT change the profile parameter and MUST reject the payload type containing an unsupported profile. A decoder that supports a profile SHALL also support H.263 baseline profile (profile 0). An offerer is RECOMMENDED to offer all the different profiles it is interested to use as individual payload types. In addition an offerer, sending an offer using the PROFILE optional parameter, is RECOMMENDED to offer profile 0, as this will enable communication, and in addition allows an answerer to add those profiles it does support in an answer.
以下の輪郭を描いてください。 SDPプロフィールパラメタの申し出は、申出人が指定されたプロフィールを使用する流れを解読できるのを示します。 各プロフィールが異なったH.263別館を使用するので、それらの間には、どんな暗示している関係もありません。 answerer SHALLはプロフィールパラメタを変えて、サポートされないプロフィールを含むペイロードタイプを拒絶してはいけません。 また、プロフィールSHALLを支持するデコーダはH.263基線プロフィール(プロフィール0)を支えます。 申出人は個々のペイロードがタイプされるようにそれが使用したがっているすべての異なったプロフィールを提供するRECOMMENDEDです。 PROFILEの任意のパラメタを使用することで申し出を送って、さらに、申出人はプロフィール0を提供するRECOMMENDEDです、これが、コミュニケーションを可能にして、answererがそれが答えで支えるそれらのプロフィールを加えるのをさらに、許容するとき。
LEVEL: The LEVEL parameter in an offer indicates the maximum computational complexity supported by the offerer in performing decoding for the given PROFILE. An answerer MAY change the value (both up and down) of the LEVEL parameter in its answer to indicate the highest value it supports.
レベル: 申し出におけるLEVELパラメタは与えられたPROFILEのために解読しながら働く際に申出人によって支持された最大の計算量を示します。 answererは、支持する中で最も高い値を示すために、答えにおける、LEVELパラメタの値(ともに上下に)を変えるかもしれません。
INTERLACE: The parameter MAY be included in either offer or answer to indicate that the offerer or answerer respectively supports reception of interlaced content. The inclusion in either offer or answer is independent of each other.
インターレース: パラメタは、どちらの申し出にも含まれているか、または申出人かanswererがそれぞれ交錯している内容のレセプションを支持するのを示すために答えるかもしれません。 申し出か答えのどちらかでの包含は互いから独立しています。
Picture sizes and MPI: Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.263 can be combined. All picture sizes can be advertised to the other party, or only a subset. The terminal announces only those picture sizes (with their MPIs) which it is willing to receive. For example, MPI=2 means that the maximum (decodable) picture rate per second is 15/1.001 (approximately 14.985).
サイズとMPIについて描写してください: 支持された絵のサイズとH.263のためのそれらの対応する最小の絵の間隔(MPI)情報を結合できます。 他のパーティー、または部分集合だけにすべての絵のサイズの広告を出すことができます。 端末はそれが受けても構わないと思っているそれらの絵のサイズ(それらのMPIsと)だけを発表します。 例えば、MPI=2は、1秒あたりの最大(解読可能)の絵のレートが15/1.001(およそ14.985)であることを意味します。
If the receiver does not specify the picture size/MPI optional parameter, then it SHOULD be ready to receive QCIF resolution with MPI=1.
受信機は絵のサイズ/MPI任意のパラメタを指定しないで、次に、それはSHOULDです。MPI=1とのQCIF解決を受ける準備ができていてください。
Parameters offered first are the most preferred picture mode to be received.
最初に提供されたパラメタは受け取られるべき最も都合のよい絵のモードです。
Ott, et al. Standards Track [Page 23] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[23ページ]RFC RTP有効搭載量形式2007年1月
Here is an example of the usage of these parameters:
ここに、これらのパラメタの用法に関する例があります:
CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2
CIF=4; 36万240、QCIF=3; SQCIF=2; 習慣=2
This means that the encoder SHOULD send CIF picture size, which it can decode at MPI=4. If that is not possible, then QCIF with MPI value 3 should be sent; if neither are possible, then SQCIF with MPI value=2. The receiver is capable of (but least preferred) decoding custom picture sizes (max 360x240) with MPI=2. Note that most decoders support at least QCIF and CIF fixed resolutions, and that they are expected to be available almost in every H.263-based video application.
これは、エンコーダSHOULDが絵のサイズをCIFに送ることを意味します。(それはMPI=4でサイズを解読できます)。 それが可能でないなら、MPI値3があるQCIFを送るべきです。 どちらも可能でないなら、次に、MPI値があるSQCIF=2です。 受信機はMPI=2と共に(しかし、最も最少に好まれます)解読習慣絵のサイズ(最大360x240)ができます。 ほとんどのデコーダサポートの少なくともQCIFとCIFが解決を修理して、ほとんどあらゆるH.263ベースのビデオ・アプリケーションで利用可能であると予想されることに注意してください。
Below is an example of H.263 SDP in an offer:
以下に、申し出におけるH.263 SDPに関する例があります:
a=fmtp:xx CIF=4;QCIF=2;F=1;K=1
a=fmtp: xx CIF=4; QCIF=2; F=1; K=1
This means that the sender of this message can decode an H.263 bit stream with the following options and parameters: preferred resolution is CIF (at up to 30/4.004 frames per second), but if that is not possible then QCIF size is also supported (at up to 30/2.002 frames per second). Advanced Prediction mode (AP) and slicesInOrder-NonRect options MAY be used.
これは、このメッセージの送付者が以下のオプションとパラメタがあるH.263ビットストリームを解読できることを意味します: 都合のよい解決はCIF(1秒あたり最大30/4.004個のフレームの)ですが、それが可能でないなら、また、QCIFサイズは支持されます(1秒あたり最大30/2.002個のフレームで)。 高度なPredictionモード(AP)とslicesInOrder-NonRectオプションは使用されるかもしれません。
Below is an example of H.263 SDP in an offer that includes the CPCF parameter.
以下に、CPCFパラメタを含んでいる申し出におけるH.263 SDPに関する例があります。
a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1
a=fmtp: xx CPCF=36、1000、0、1、1、0、0、2; CUSTOM=640,480、2;CIF=1; QCIF=1
This means that the sender of this message can decode an H.263 bit stream with a preferred custom picture size of 640x480 at a maximum frame rate of 25 frames per second using a custom picture clock frequency of 50 Hz. If that is not possible, then the 640x480 picture size is also supported at up to 30/2.002 frames per second using the ordinary picture clock frequency of 30/1.001 Hz. If neither of those is possible, then the CIF and QCIF picture sizes are also supported at up to 50 frames per second using the custom picture clock frequency of 50 Hz or up to 30/1.001 frames per second using the ordinary picture clock frequency of 30/1.001 Hz, and CIF is preferred over QCIF.
これは、このメッセージの送付者が2番目に、50Hzのカスタム絵のクロック周波数を使用するのあたり25個のフレームの最大のフレーム料金で640×480の都合のよいカスタム絵のサイズがあるH.263ビットストリームを解読できることを意味します。 また、それが可能でないなら、640×480絵のサイズは2番目に、30/1.001Hzの普通の絵のクロック周波数を使用するのあたり最大30/2.002個のフレームで支持されます。 また、それらのどちらも可能でないならCIFとQCIF絵のサイズが2番目に、50Hzのカスタム絵のクロック周波数を使用するのあたり最大50個のフレームか2番目に、30/1.001Hzの普通の絵のクロック周波数を使用するのあたり最大30/1.001個のフレームで支持されて、CIFはQCIFより好まれます。
The following limitation applies for usage of these media types when performing offer/answer for sessions using multicast transport. An answerer SHALL NOT change any of the parameters in an answer, instead if the indicated values are not supported the payload type MUST be rejected.
セッションのためにマルチキャスト輸送を使用することで申し出/答えを実行するとき、以下の制限はこれらのメディアタイプの使用法に申し込みます。 answerer SHALLは答えにおけるパラメタのいずれも変えないで、表示値が支持されないなら、代わりに、ペイロードタイプを拒絶しなければなりません。
Ott, et al. Standards Track [Page 24] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[24ページ]RFC RTP有効搭載量形式2007年1月
9. Backward Compatibility to RFC 2429
9. RFC2429への後方の互換性
The current document is a revision of RFC 2429 and obsoletes it. This section will address the backward compatibility issues.
現在のドキュメントは、RFC2429の改正であり、それを時代遅れにします。 このセクションは後方の互換性の問題を記述するでしょう。
9.1. New Optional Parameters for SDP
9.1. 新しいSDPに、任意のパラメタ
The document adds new optional parameters to the H263-1998 and H263- 2000 payload type, defined in RFC 3555 [RFC3555]. Since these are optional parameters we expect that old implementations will ignore these parameters, and that new implementations that will receive the H263-1998 and H263-2000 payload types with no parameters will behave as if the other side can accept H.263 at QCIF resolution at a frame rate not exceeding 15/1.001 (approximately 14.985) frames per second.
ドキュメントはRFC3555[RFC3555]で定義されたH263-1998とH263 2000ペイロードタイプに新しい任意のパラメタを追加します。 私たちは、これらが任意のパラメタであって、古い実現がこれらのパラメタを無視すると予想します、そして、まるで反対側が1秒あたり15/1.001個(およそ14.985)のフレームを超えていないフレームレートでQCIF解決でH.263を受け入れることができるかのようにパラメタなしでH263-1998とH263-2000ペイロードタイプを受ける新しい実現が振る舞うでしょう。
10. IANA Considerations
10. IANA問題
This document updates the H.263 (1998) and H.263 (2000) media types, described in RFC 3555 [RFC3555]. The updated media type registrations are in Section 8.1.
このドキュメントはRFC3555[RFC3555]で説明されたH.263(1998)とH.263(2000)メディアタイプをアップデートします。 アップデートされたメディアタイプ登録証明書がセクション8.1にあります。
11. Security Considerations
11. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile (for example, [RFC3551]). 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仕様[RFC3550]とどんな適切なRTPプロフィール(例えば、[RFC3551])でも議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED.
潜在的サービスの否定の脅威は、zデータの符号化のために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。 少なくともRTPパケットの認証の用法はRECOMMENDEDです。
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 environment, pruning of specific sources may be implemented in future versions of IGMP [RFC2032] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
どんなIPベースのプロトコル、いくつかの事情ではも、受信機は単に必要であるか望まれないあまりに多くのパケットの領収書で積みすぎられるかもしれません。 ネットワーク層認証は望まれないソースからパケットを捨てるのに使用されるかもしれませんが、認証自体の加工費は高過ぎるかもしれません。 マルチキャスト環境で、特定のソースを取り除くのは、受信機が、どのソースがそれに達することができるかを選択するのを許容するためにIGMP[RFC2032]の将来のバージョンとマルチキャストルーティング・プロトコルで実行されるかもしれません。
Ott, et al. Standards Track [Page 25] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[25ページ]RFC RTP有効搭載量形式2007年1月
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式の安全レビューはRTP仕様によるそれらを超えてどんな追加問題も見つけませんでした。
12. Acknowledgements
12. 承認
This is to acknowledge the work done by Chad Zhu, Linda Cline, Gim Deisher, Tom Gardos, Christian Maciocco, and Donald Newell from Intel Corp., who co-authored RFC 2429.
これは、チャドの朱、リンダCline、Gim Deisher、トムGardos、クリスチャンのMaciocco、およびドナルド・ヌーエルによってインテル社から行われた仕事を承諾するためのものです。インテル社は、RFC2429について共同執筆しました。
We would also like to acknowledge the work of Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with composing the text for the new media types.
また、ノキアとNermeenイスマイルからシスコからペトリKoskelainenの仕事を承諾したいと思います。(シスコは、ニューメディアタイプのためにテキストを構成するのに助けました)。
13. Changes from Previous Versions of the Documents
13. ドキュメントの旧バージョンからの変化
13.1. Changes from RFC 2429
13.1. RFC2429からの変化
The changes from the RFC 2429 are:
RFC2429からの変化は以下の通りです。
1. The H.263 1998 and 2000 media type are now in the payload
specification.
1. H.263 1998と2000メディアタイプが現在、ペイロード仕様にあります。
2. Added optional parameters to the H.263 1998 and 2000 media types.
2. H.263 1998と2000年のメディアタイプに任意のパラメタを追加しました。
3. Mandate the usage of RFC 2429 for all H.263. RFC 2190 payload
format should be used only to interact with legacy systems.
3. すべてのH.263のためにRFC2429の使用法を強制してください。 RFC2190ペイロード形式は使用されるべきですが、遺産システムと対話します。
13.2. Changes from RFC 3555
13.2. RFC3555からの変化
This document adds new optional parameters to the H263-1998 and H263-2000 payload types.
このドキュメントはH263-1998とH263-2000ペイロードタイプに新しい任意のパラメタを追加します。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[H263] International Telecommunications Union - Telecommunication
Standardization Sector, "Video coding for low bit rate
communication", ITU-T Recommendation H.263, January 2005.
[H263]国際Telecommunications Union--電気通信Standardization Sector、「少ないビット伝送速度コミュニケーションのためのビデオ符号化」、ITU-T Recommendation H.263、2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Ott, et al. Standards Track [Page 26] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[26ページ]RFC RTP有効搭載量形式2007年1月
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC3555] CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
14.2. Informative References
14.2. 有益な参照
[RFC2032] Turletti, T., "RTP Payload Format for H.261 Video
Streams", RFC 2032, October 1996.
[RFC2032] Turletti、T.、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC
2190, September 1997.
[RFC2190] 朱、C.、「H.263ビデオストリームのためのRTP有効搭載量形式」、RFC2190、1997年9月。
[RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco,
C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C.
Zhu, "RTP Payload Format for the 1998 Version of ITU-T
Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[RFC2429] ボルマン、C.、クライン、L.、Deisher、G.、Gardos、T.、Maciocco、C.、ヌーエル、D.、オット、J.、サリバン、G.、ウェンガー、S.、およびC.朱、「1998年のITU-T RecのバージョンのためのRTP有効搭載量形式。」 「H.263ビデオ(H.263+)」、RFC2429、1998年10月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、バーマイスター、C.、およびJ.レイは「リアルタイムの輸送制御プロトコル(RTCP)ベースのフィードバック(RTP/AVPF)のためにRTPプロフィールを広げました」、RFC4585、2006年7月。
[RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to
Historic Status", RFC 4628, January 2007.
[RFC4628] 同等である、R.、「H.263運動のためのRTP有効搭載量形式、歴史的な状態へのRFC2190、」、RFC4628、1月2007日
[Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc.
Audio-Visual Services over Packet Networks, Aberdeen, U.K.
9/1997, September 1997.
[Vredun] ウェンガー、S.、「H.263+でのビデオ冗長コード化」、Proc。 1997年9月のパケット網、アバディーン、イギリス9/1997の上の視聴覚のサービス。
Ott, et al. Standards Track [Page 27] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[27ページ]RFC RTP有効搭載量形式2007年1月
Authors' Addresses
作者のアドレス
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 02015 TKK, Finland
TKK、技術ネットワーク研究所PO Box3000 02015フィンランドのヨルクオットヘルシンキ大学
EMail: jo@netlab.tkk.fi
メール: jo@netlab.tkk.fi
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, GERMANY
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
Phone: +49.421.218-7024 Fax: +49.421.218-7000 EMail: cabo@tzi.org
以下に電話をしてください。 +49.421 .218-7024Fax: +49.421 .218-7000メール: cabo@tzi.org
Gary Sullivan Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
ゲーリーサリバンMicrosoft Corp.1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: garysull@microsoft.com
メール: garysull@microsoft.com
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
シュテファン・ウェンガーノキアリサーチセンター私書箱100 33721タンペレフィンランド
EMail: stewe@stewe.org
メール: stewe@stewe.org
Roni Even (editor) Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
ロニ(エディタ)同等のPolycom94DerechイエムHamoshavot Petach Tikva49130イスラエル
EMail: roni.even@polycom.co.il
メール: roni.even@polycom.co.il
Ott, et al. Standards Track [Page 28] RFC 4629 H.263 RTP Payload Format January 2007
オット、他 4629時間.263の標準化過程[28ページ]RFC RTP有効搭載量形式2007年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ott, et al. Standards Track [Page 29]
オット、他 標準化過程[29ページ]
一覧
スポンサーリンク
