As per Relevance of the word reference, we have this rfc below:
Network Working
Request for Comments: 2429 C.
Category: Standards Track Univ.
L.
G.
T.
C.
D.
J.
Univ.
G.
S.
TU
C.
October 1998
RTP Payload Format for the 1998 Version
ITU-T Rec. H.263 Video (H.263+)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
1.
This document specifies an RTP payload header format applicable
the transmission of video streams generated based on the 1998
of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263
is a superset of the 1996 syntax, this format can also be used
the 1996 version of H.263 [3], and is recommended for this use by
implementations. This format does not replace RFC 2190,
continues to be used by existing implementations, and may be
for backward compatibility in new implementations.
using the new features of the 1998 version of H.263 shall use
format described in this document
Bormann, et. al. Standards Track [Page 1]
RFC 2429 H.263+ October 1998
The 1998 version of ITU-T Recommendation H.263 added numerous
options to improve codec performance over the 1996 version. The 1998
version is referred to as H.263+ in this document. Among the
options, the ones with the biggest impact on the RTP
specification and the error resilience of the video content are
slice structured mode, the independent segment decoding mode,
reference picture selection mode, and the scalability mode.
section summarizes the impact of these new coding options
packetization. Refer to [4] for more information on coding options
The slice structured mode was added to H.263+ for three purposes:
provide enhanced error resilience capability, to make the
more amenable to use with an underlying packet transport such as RTP
and to minimize video delay. The slice structured mode
fragmentation at macroblock boundaries
With the independent segment decoding (ISD) option, a video
frame is broken into segments and encoded in such a way that
segment is independently decodable. Utilizing ISD in a lossy
environment helps to prevent the propagation of errors from
segment of the picture to others
The reference picture selection mode allows the use of an
reference picture rather than the one immediately preceding
current picture. Usually, the last transmitted frame is
used as the reference picture for inter-frame prediction. If
reference picture selection mode is used, the data stream
information on what reference frame should be used, indicated by
temporal reference as an ID for that reference frame. The
picture selection mode can be used with or without a back channel
which provides information to the encoder about the internal
of the decoder. However, no special provision is made herein
carrying back channel information
H.263+ also includes bitstream scalability as an optional
mode. Three kinds of scalability are defined: temporal, signal-to
noise ratio (SNR), and spatial scalability. Temporal scalability
achieved via the disposable nature of bi-directionally
frames, or B-frames. (A low-delay form of temporal scalability
as P-picture temporal scalability can also be achieved by using
reference picture selection mode described in the
paragraph.) SNR scalability permits refinement of encoded
frames, thereby improving the quality (or SNR). Spatial
is similar to SNR scalability except the refinement layer is
the size of the base layer in the horizontal dimension,
dimension, or both
Bormann, et. al. Standards Track [Page 2]
RFC 2429 H.263+ October 1998
2. Usage of
When transmitting H.263+ video streams over the Internet, the
of the encoder can be packetized directly. All the bits
from the bitstream including the fixed length codes and
length codes will be included in the packet, with the only
being that when the payload of a packet begins with a Picture, GOB
Slice, EOS, or EOSBS start code, the first two (all-zero) bytes
the start code are removed and replaced by setting an indicator
in the payload header
For H.263+ bitstreams coded with temporal, spatial, or
scalability, each layer may be transported to a different
address. More specifically, each layer may use a unique IP
and port number combination. The temporal relations between
shall be expressed using the RTP timestamp so that they can
synchronized at the receiving ends in multicast or
applications
The H.263+ video stream will be carried as payload data within
packets. A new H.263+ payload header is defined in section 4.
section defines the usage of the RTP fixed header and H.263+
packet structure
2.1 RTP Header
Each RTP packet starts with a fixed RTP header. The following
of the RTP fixed header are used for H.263+ video streams
Marker bit (M bit): The Marker bit of the RTP header is set to 1
the current packet carries the end of current frame, and is 0
otherwise
Payload Type (PT): The Payload Type shall specify the H.263+
payload format
Timestamp: The RTP Timestamp encodes the sampling instance of
first video frame data contained in the RTP data packet. The
timestamp shall be the same on successive packets if a video
occupies more than one packet. In a multilayer scenario,
pictures corresponding to the same temporal reference should use
same timestamp. If temporal scalability is used (if B-frames
present), the timestamp may not be monotonically increasing in
RTP stream. If B-frames are transmitted on a separate layer
address, they must be synchronized properly with the
frames. Refer to the 1998 ITU-T Recommendation H.263 [4]
information on required transmission order to a decoder. For
H.263+ video stream, the RTP timestamp is based on a 90 kHz clock
Bormann, et. al. Standards Track [Page 3]
RFC 2429 H.263+ October 1998
the same as that of the RTP payload for H.261 stream [5]. Since
the H.263+ data and the RTP header contain time information, it
required that those timing information run synchronously. That is
both the RTP timestamp and the temporal reference (TR in the
header of H.263) should carry the same relative timing information
Any H.263+ picture clock frequency can be expressed
1800000/(cd*cf) source pictures per second, in which cd is an
from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz
of the RTP timestamp, the time increment between each coded H.263+
picture should therefore be a integer multiple of (cd*cf)/20.
will always be an integer for any "reasonable" picture
frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25
PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the
display update rates of 60, 72 and 75 Hz, respectively). For
packetization of hypothetical H.263+ bitstreams using "unreasonable
custom picture clock frequencies, mathematical rounding could
necessary for generating the RTP timestamps
2.2 Video Packet
A section of an H.263+ compressed bitstream is carried as a
within each RTP packet. For each RTP packet, the RTP header
followed by an H.263+ payload header, which is followed by a
of bytes of a standard H.263+ compressed bitstream. The size of
H.263+ payload header is variable depending on the payload
as detailed in the section 4. The layout of the RTP H.263+
packet is shown as
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263+ Payload Header ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263+ Compressed Data Stream ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any H.263+ start codes can be byte aligned by an encoder by using
stuffing mechanisms of H.263+. As specified in H.263+, picture
slice, and EOSBS starts codes shall always be byte aligned, and
and EOS start codes may be byte aligned. For packetization purposes
GOB start codes should be byte aligned; however, since this is
required in H.263+, there may be some cases where GOB start codes
not aligned, such as when transmitting existing content, or
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
packetization
Bormann, et. al. Standards Track [Page 4]
RFC 2429 H.263+ October 1998
All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS)
with 16 zero-valued bits. If a start code is byte aligned and
occurs at the beginning of a packet, these two bytes shall be
from the H.263+ compressed data stream in the packetization
and shall instead be represented by setting a bit (the P bit) in
payload header
3. Design
The goals of this payload format are to specify an efficient way
encapsulating an H.263+ standard compliant bitstream and to
the resiliency towards packet losses. Due to the large number
different possible coding schemes in H.263+, a copy of the
header with configuration information is inserted into the
header when appropriate. The use of that copy of the picture
along with the payload data can allow decoding of a received
even in such cases in which another packet containing the
picture header becomes lost
There are a few assumptions and constraints associated with
H.263+ payload header design. The purpose of this section is
point out various design issues and also to discuss several
options provided by H.263+ that may impact the performance
network-based H.263+ video
o The optional slice structured mode described in Annex K of H.263+
[4] enables more flexibility for packetization. Similar to
picture segment that begins with a GOB header, the motion
predictors in a slice are restricted to reside within
boundaries. However, slices provide much greater freedom in
selection of the size and shape of the area which is represented
a distinct decodable region. In particular, slices can have a
which is dynamically selected to allow the data for each slice
fit into a chosen packet size. Slices can also be chosen to have
rectangular shape which is conducive for minimizing the impact
errors and packet losses on motion compensated prediction.
these reasons, the use of the slice structured mode is
recommended for any applications used in environments
significant packet loss occurs
o In non-rectangular slice structured mode, only complete
should be included in a packet. In other words, slices should
be fragmented across packet boundaries. The only reasonable
for a slice to be fragmented across packet boundaries is when
encoder which generated the H.263+ data stream could not
influenced by an awareness of the packetization process (such
when sending H.263+ data through a network other than the one
which the encoder is attached, as in network
Bormann, et. al. Standards Track [Page 5]
RFC 2429 H.263+ October 1998
implementations). Optimally, each packet will contain only
slice
o The independent segment decoding (ISD) described in Annex R of [4]
prevents any data dependency across slice or GOB boundaries in
reference picture. It can be utilized to further
resiliency in high loss conditions
o If ISD is used in conjunction with the slice structure,
rectangular slice submode shall be enabled and the dimensions
quantity of the slices present in a frame shall remain the
between each two intra-coded frames (I-frames), as required
H.263+. The individual ISD segments may also be entirely
coded from time to time to realize quick error recovery
adding the latency time associated with sending complete INTRA
pictures
o When the slice structure is not applied, the insertion of
(preferably byte-aligned) GOB header can be used to provide
boundaries in the bitstream, as the presence of a GOB
eliminates the dependency of motion vector prediction across
boundaries. These resync boundaries provide natural locations
packet payload boundaries
o H.263+ allows picture headers to be sent in an abbreviated form
order to prevent repetition of overhead information that does
change from picture to picture. For resiliency, sending a
picture header for every frame is often advisable. This means
(especially in cases with high packet loss probability in
picture header contents are not expected to be highly predictable),
the sender may find it advisable to always set the subfield UFEP
PLUSPTYPE to '001' in the H.263+ video bitstream. (See [4] for
definition of the UFEP and PLUSPTYPE fields).
o In a multi-layer scenario, each layer may be transmitted to
different network address. The configuration of each layer such
the enhancement layer number (ELNUM), reference layer
(RLNUM), and scalability type should be determined at the start
the session and should not change during the course of the session
o All start codes can be byte aligned, and picture, slice, and
start codes are always byte aligned. The boundaries of
syntactical elements provide ideal locations for placing
boundaries
Bormann, et. al. Standards Track [Page 6]
RFC 2429 H.263+ October 1998
o We assume that a maximum Picture Header size of 504 bits
sufficient. The syntax of H.263+ does not explicitly
larger picture header sizes, but the use of such extremely
picture headers is not expected
4. H.263+ Payload
For H.263+ video streams, each RTP packet carries only one H.263+
video packet. The H.263+ payload header is always present for
H.263+ video packet. The payload header is of variable length. A 16
bit field of the basic payload header may be followed by an 8
field for Video Redundancy Coding (VRC) information, and/or by
variable length extra picture header as indicated by PLEN.
optional fields appear in the order given above when present
If an extra picture header is included in the payload header,
length of the picture header in number of bytes is specified by PLEN
The minimum length of the payload header is 16 bits, corresponding
PLEN equal to 0 and no VRC information present
The remainder of this section defines the various components of
RTP payload header. Section five defines the various packet
that are used to carry different types of H.263+ coded data,
section six summarizes how to distinguish between the various
types
4.1 General H.263+ payload
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR: 5
Reserved bits. Shall be zero
P: 1
Indicates the picture start or a picture segment (GOB/Slice)
or a video sequence end (EOS or EOSBS). Two bytes of zero
then have to be prefixed to the payload of such a packet to
a complete picture/GOB/slice/EOS/EOSBS start code. This bit
the omission of the two first bytes of the start codes,
improving the compression ratio
Bormann, et. al. Standards Track [Page 7]
RFC 2429 H.263+ October 1998
V: 1
Indicates the presence of an 8 bit field containing information
Video Redundancy Coding (VRC), which follows immediately after
initial 16 bits of the payload header if present. For syntax
semantics of that 8 bit VRC field see section 4.2.
PLEN: 6
Length in bytes of the extra picture header. If no extra
header is attached, PLEN is 0. If PLEN>0, the extra picture
is attached immediately following the rest of the payload header
Note the length reflects the omission of the first two bytes of
picture start code (PSC). See section 5.1.
PEBIT: 3
Indicates the number of bits that shall be ignored in the last
of the picture header. If PLEN is not zero, the ignored bits
be the least significant bits of the byte. If PLEN is zero,
PEBIT shall also be zero
4.2 Video Redundancy Coding Header
Video Redundancy Coding (VRC) is an optional mechanism intended
improve error resilience over packet networks. Implementing VRC
H.263+ will require the Reference Picture Selection option
in Annex N of [4]. By having multiple "threads" of
inter-frame predicted pictures, damage of individual frame will
distortions only within its own thread but leave the other
unaffected. From time to time, all threads converge to a so-
sync frame (an INTRA picture or a non-INTRA picture which
redundantly represented within multiple threads); from this
frame, the independent threads are started again. For
information on codec support for VRC see [7].
P-picture temporal scalability is another use of the
picture selection mode and can be considered a special case of VRC
which only one copy of each sync frame may be sent. It offers
thread-based method of temporal scalability without the
delay caused by the use of B pictures. In this use, sync frames
in the first thread of pictures are also used for the prediction of
second thread of pictures which fall temporally between the
frames to increase the resulting frame rate. In this use,
pictures in the second thread can be discarded in order to obtain
reduction of bit rate or decoding complexity without harming
ability to decode later pictures. A third or more threads can
be added as well, but each thread is predicted only from the
frames (which are sent at least in thread 0) or from frames
the same thread
Bormann, et. al. Standards Track [Page 8]
RFC 2429 H.263+ October 1998
While a VRC data stream is - like all H.263+ data - totally self
contained, it may be useful for the transport
implementation to have knowledge about the current damage status
each thread. On the Internet, this status can easily be
by observing the marker bit, the sequence number of the RTP header
and the thread-id and a circling "packet per thread" number.
latter two numbers are coded in the VRC header extension
The format of the VRC header extension is as follows
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S
+-+-+-+-+-+-+-+-+
TID: 3
Thread ID. Up to 7 threads are allowed. Each frame of H.263+
data will use as reference information only sync frames or
within the same thread. By convention, thread 0 is expected to
the "canonical" thread, which is the thread from which the
frame should ideally be used. In the case of corruption or loss
the thread 0 representation, a representation of the sync
with a higher thread number can be used by the decoder.
thread numbers are expected to contain equal or
representations of the sync frames than higher thread numbers
the absence of data corruption or loss. See [7] for a
discussion of VRC
Trun: 4
Monotonically increasing (modulo 16) 4 bit number counting
packet number within each thread
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
"sync" picture, in order to ensure that regardless of which
of pictures is corrupted by errors or packet losses, the
of at least one representation of a particular picture is
(within at least one thread). The sync picture can then be
for the prediction of any thread. If packet losses have
occurred, then the sync frame contents of thread 0 can be used
those of other threads can be discarded (and similarly for
threads). Thread 0 is considered the "canonical" thread, the
of which is preferable to all others. The contents of
having lower thread numbers shall be considered as having a
processing and delivery priority than those with higher
numbers. Thus packets having lower thread numbers for a given
frame shall be delivered first to the decoder under loss-free
Bormann, et. al. Standards Track [Page 9]
RFC 2429 H.263+ October 1998
low-time-jitter conditions, which will result in the discarding
the sync contents of the higher-numbered threads as specified
Annex N of [4].
5. Packetization
5.1 Picture Segment Packets and Sequence Ending Packets (P=1)
A picture segment packet is defined as a packet that starts at
location of a Picture, GOB, or slice start code in the H.263+
stream. This corresponds to the definition of the start of a
picture segment as defined in H.263+. For such packets, P=1 always
An extra picture header can sometimes be attached in the
header of such packets. Whenever an extra picture header is
as signified by PLEN>0, only the last six bits of its picture
code, '100000', are included in the payload header. A
H.263+ picture header with byte aligned picture start code can
conveniently assembled on the receiving end by prepending the
leading '0' bits
When PLEN>0, the end bit position corresponding to the last byte
the picture header data is indicated by PEBIT. The actual
data shall begin on an 8-bit byte boundary following the
header
A sequence ending packet is defined as a packet that starts at
location of an EOS or EOSBS code in the H.263+ data stream.
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-
Recommendation H.263). For such packets, P=1 and PLEN=0 always
The optional header extension for VRC may or may not be present
indicated by the V bit flag
5.1.1 Packets that begin with a Picture Start
Any packet that contains the whole or the start of a coded
shall start at the location of the picture start code (PSC),
should normally be encapsulated with no extra copy of the
header. In other words, normally PLEN=0 in such a case. However,
the coded picture contains an incomplete picture header (UFEP =
"000"), then a representation of the complete (UFEP = "001")
header may be attached during packetization in order to
greater error resilience. Thus, for packets that start at
location of a picture start code, PLEN shall be zero unless both
the following conditions apply
Bormann, et. al. Standards Track [Page 10]
RFC 2429 H.263+ October 1998
1) The picture header in the H.263+ bitstream payload is
(PLUSPTYPE present and UFEP="000"),
2) The additional picture header which is attached is not
(UFEP="001").
A packet which begins at the location of a Picture, GOB, slice, EOS
or EOSBS start code shall omit the first two (all zero) bytes
the H.263+ bitstream, and signify their presence by setting P=1
the payload header
Here is an example of encapsulating the first packet in a
(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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.2 Packets that begin with GBSC or
For a packet that begins at the location of a GOB or slice
code, PLEN may be zero or may be nonzero, depending on whether
redundant picture header is attached to the packet. In
with very low packet loss rates, or when picture header contents
very seldom likely to change (except as can be detected from the
syntax of H.263+), a redundant copy of the picture header is
required. However, in less ideal circumstances a redundant
header should be attached for enhanced error resilience, and
presence is indicated by PLEN>0.
Assuming a PLEN of 9 and P=1, below is an example of a packet
begins with a byte aligned GBSC or a 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bormann, et. al. Standards Track [Page 11]
RFC 2429 H.263+ October 1998
Notice that only the last six bits of the picture start code
'100000', are included in the payload header. A complete H.263+
picture header with byte aligned picture start code can
conveniently assembled if needed on the receiving end by
the sixteen leading '0' bits
5.1.3 Packets that Begin with an EOS or EOSBS
For a packet that begins with an EOS or EOSBS code, PLEN shall
zero, and no Picture, GOB, or Slice start codes shall be
within the same packet. As with other packets beginning with
codes, the two all-zero bytes that begin the EOS or EOSBS code at
beginning of the packet shall be omitted, and their presence shall
indicated by setting the P bit to 1 in the payload header
System designers should be aware that some decoders may interpret
loss of a packet containing only EOS or EOSBS information as the
of essential video data and may thus respond by not displaying
subsequent video information. Since EOS and EOSBS codes do
actually affect the decoding of video pictures, they are
unnecessary to send at all. Because of the danger
misinterpretation of the loss of such a packet (which can be
by the sequence number), encoders are generally to be
from sending EOS and EOSBS
Below is an example of a packet containing an EOS code
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 Encapsulating Follow-On Packet (P=0)
A Follow-on packet contains a number of bytes of coded H.263+
which does not start at a synchronization point. That is, a Follow
On packet does not start with a Picture, GOB, Slice, EOS, or
header, and it may or may not start at a macroblock boundary.
Follow-on packets do not start at synchronization points, the data
the beginning of a follow-on packet is not independently decodable
For such packets, P=0 always. If the preceding packet of a Follow-
packet got lost, the receiver may discard that Follow-on packet
well as all other following Follow-on packets. Better behavior,
course, would be for the receiver to scan the interior of the
payload content to determine whether any start codes are found in
interior of the packet which can be used as resync points. The
of an attached copy of a picture header for a follow-on packet
Bormann, et. al. Standards Track [Page 12]
RFC 2429 H.263+ October 1998
useful only if the interior of the packet or some subsequent follow
on packet contains a resync code such as a GOB or slice start code
PLEN>0 is allowed, since it may allow resync in the interior of
packet. The decoder may also be resynchronized at the next
or picture packet
Here is an example of a follow-on packet (with 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Use of this payload
There is no syntactical difference between a picture segment packet
a Follow-on packet, other than the indication P=1 for picture segment
sequence ending packets and P=0 for Follow-on packets. See
following for a summary of the entire packet types and ways
distinguish between them
It is possible to distinguish between the different packet types
checking the P bit and the first 6 bits of the payload along with
header information. The following table shows the packet type
permutations of this information (see also the picture/GOB/Slice
descriptions in H.263+ for details):
--------------+--------------+----------------------+-------------------
First 6 bits | P-Bit | PLEN | Packet |
of Payload |(payload hdr.)| |
--------------+--------------+----------------------+-------------------
100000 | 1 | 0 | Picture | Typical
100000 | 1 | > 0 | Picture | Note
1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible
1xxxxx | 1 | > 0 | GOB/Slice | See possible
Xxxxxx | 0 | 0 | Follow-on |
Xxxxxx | 0 | > 0 | Follow-on | Interior
--------------+--------------+----------------------+-------------------
The details regarding the possible values of the five bit
Number (GN) field which follows the initial "1" bit when the P-bit
"1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3
of [4].
As defined in this specification, every start of a coded frame (
indicated by the presence of a PSC) has to be encapsulated as
picture segment packet. If the whole coded picture fits into
Bormann, et. al. Standards Track [Page 13]
RFC 2429 H.263+ October 1998
packet of reasonable size (which is dependent on the
characteristics), this is the only type of packet that may need to
used. Due to the high compression ratio achieved by H.263+ it
often possible to use this mechanism, especially for small
picture formats such as QCIF and typical Internet packet sizes
1500 bytes
If the complete coded frame does not fit into a single packet,
different ways for the packetization may be chosen. In case of
low or zero packet loss probability, one or more Follow-on
may be used for coding the rest of the picture. Doing so leads
minimal coding and packetization overhead as well as to an
use of the maximal packet size, but does not provide any added
resilience
The alternative is to break the picture into reasonably
partitions - called Segments - (by using the Slice or GOB mechanism),
that do offer synchronization points. By doing so and using
Picture Segment payload with PLEN>0, decoding of the
packets is possible even in such cases in which the Picture
containing the picture header was lost (provided any
reference picture is available). Picture Segment packets can also
used in conjunction with Follow-on packets for large segment sizes
7. Security
RTP packets using the payload format defined in this
are subject to the security considerations discussed in the
specification [1], and any appropriate RTP profile (for example [2]).
This implies that confidentiality of the media streams is achieved
encryption. Because the data compression used with this
format is applied end-to-end, encryption may be performed
compression so there is no conflict between the two operations
A potential denial-of-service threat exists for data encodings
compression techniques that have non-uniform receiver-
computational load. The attacker can inject pathological
into the stream which are complex to decode and cause the receiver
be overloaded. However, this encoding does not exhibit
significant non-uniformity
As with any IP-based protocol, in some circumstances a receiver
be overloaded simply by the receipt of too many packets,
desired or undesired. Network-layer authentication may be used
discard packets from undesired sources, but the processing cost
the authentication itself may be too high. In a
Bormann, et. al. Standards Track [Page 14]
RFC 2429 H.263+ October 1998
environment, pruning of specific sources may be implemented in
versions of IGMP [5] and in multicast routing protocols to allow
receiver to select which sources are allowed to reach it
A security review of this payload format found no
considerations beyond those in the RTP specification
8. Addresses of
Carsten
Universitaet Bremen FB3 TZI EMail: cabo@tzi.
Postfach 330440 Phone: +49.421.218-7024
D-28334 Bremen, GERMANY Fax: +49.421.218-7000
Linda
Intel Corp. M/S JF3-206 EMail: lscline@jf.intel.
2111 NE 25th Avenue Phone: +1 503 264 3501
Hillsboro, OR 97124, USA Fax: +1 503 264 3483
Gim
Intel Corp. M/S JF2-78 EMail: gim.l.deisher@intel.
2111 NE 25th Avenue Phone: +1 503 264 3758
Hillsboro, OR 97124, USA Fax: +1 503 264 9372
Tom
Intel Corp. M/S JF2-78 EMail: thomas.r.gardos@intel.
2111 NE 25th Avenue Phone: +1 503 264 6459
Hillsboro, OR 97124, USA Fax: +1 503 264 9372
Christian
Intel Corp. M/S JF3-206 EMail: christian.maciocco@intel.
2111 NE 25th Avenue Phone: +1 503 264 1770
Hillsboro, OR 97124, USA Fax: +1 503 264 9428
Donald
Intel Corp. M/S JF3-206 EMail: donald.newell@intel.
2111 NE 25th Avenue Phone: +1 503 264 9234
Hillsboro, OR 97124, USA Fax: +1 503 264 9428
Bormann, et. al. Standards Track [Page 15]
RFC 2429 H.263+ October 1998
Joerg
Universitaet Bremen FB3 TZI EMail: jo@tzi.
Postfach 330440 Phone: +49.421.218-7024
D-28334 Bremen, GERMANY Fax: +49.421.218-7000
Gary
PictureTel Corp. M/S 635 EMail: garys@pictel.
100 Minuteman Road Phone: +1 978 623 4324
Andover, MA 01810, USA Fax: +1 978 749 2804
Stephan
Technische Universitaet Berlin FB13
Sekr. FR 6-3 EMail: stewe@cs.tu-berlin.
Franklinstr. 28/29 Phone: +49.30.314-73160
D-10587 Berlin, GERMANY Fax: +49.30.314-25156
Chad
Intel Corp. M/S JF3-202 EMail: czhu@ix.netcom.
2111 NE 25th Avenue Phone: +1 503 264 6004
Hillsboro, OR 97124, USA Fax: +1 503 264 1805
9.
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson
"RTP : A Transport Protocol for Real-Time Applications",
1889, January 1996.
[2] Schulzrinne, H., "RTP Profile for Audio and Video Conference
Minimal Control", RFC 1890, January 1996.
[3] "Video Coding for Low Bit Rate Communication," ITU-
Recommendation H.263, March 1996.
[4] "Video Coding for Low Bit Rate Communication," ITU-
Recommendation H.263, January 1998.
[5] Turletti, T. and C. Huitema, "RTP Payload Format for H.261
Streams", RFC 2032, October 1996.
[6] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190,
September 1997.
[7] S. Wenger, "Video Redundancy Coding in H.263+," Proc. Audio
Visual Services over Packet Networks, Aberdeen, U.K.,
1997.
Bormann, et. al. Standards Track [Page 16]
RFC 2429 H.263+ October 1998
10. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Bormann, et. al. Standards Track [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
