As per Relevance of the word experimental, we have this rfc below:
Network Working Group M.
Request for Comments: 2343 G.
Category: Experimental B.
AT&T Labs-
May 1998
RTP Payload Format for Bundled
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes a payload type for bundled, MPEG-2
video and audio data that may be used with RTP, version 2.
has some advantages for this payload type particularly when it
used for video-on-demand applications. This payload type may be
when its advantages are important enough to sacrifice the
of having separate audio and video streams
1.
This document describes a bundled packetization scheme for MPEG-2
encoded audio and video streams using the Real-time
Protocol (RTP), version 2 [1].
The MPEG-2 International standard consists of three layers: audio
video and systems [2]. The audio and the video layers define
syntax and semantics of the corresponding "elementary streams."
systems layer supports synchronization and interleaving of
compressed streams, buffer initialization and management, and
identification. RFC 2250 [3] describes packetization techniques
transport individual audio and video elementary streams as well
the transport stream, which is defined at the system layer, using
RTP
Civanlar, et. al. Experimental [Page 1]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
The bundled packetization scheme is needed because it has
advantages over other schemes for some important
including video-on-demand (VOD) where, audio and video are
used together. Its advantages over independent packetization
audio and video are
1. Uses a single port per "program" (i.e. bundled A/V). This
increase the number of streams that can be served e.g., from a
server. Also, it eliminates the performance hit when two ports
used for the separate audio and video streams on the client side
2. Provides implicit synchronization of audio and video. This
particularly convenient when the A/V data is stored in
interleaved format at the server
3. Reduces the header overhead. Since using large packets
the effects of losses and delay, audio only packets need to
smaller increasing the overhead. An A/V bundled format can
about 1% overall overhead reduction. Considering the high
used for MPEG-2 encoded material, e.g. 4 Mbps, the number of
saved, e.g. 40 Kbps, may provide noticeable audio or video
improvement
4. May reduce overall receiver buffer size. Audio and video
may experience different delays when transmitted separately.
receiver buffers need to be designed for the longest of
delays. For example, let's assume that using two buffers, each
a size B, is sufficient with probability P when each stream
transmitted individually. The probability that the same buffer
will be sufficient when both streams need to be received is P
the conditional probability of B being sufficient for the
stream given that it was sufficient for the first one.
conditional probability is, generally, less than one requiring
of a larger buffer size to achieve the same probability level
5. May help with the control of the overall bandwidth used by
A/V program
And, the advantages over packetization of the transport layer
are
1. Reduced overhead. It does not contain systems layer
which is redundant for the RTP (essentially they address
issues).
Civanlar, et. al. Experimental [Page 2]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
2. Easier error recovery. Because of the structured
consistent with the application layer framing (ALF) principle,
concealment and error recovery can be made simpler and
effective
2. Encapsulation of Bundled MPEG Video and
Video encapsulation follows rules similar to the ones described
[3] for encapsulation of MPEG elementary streams. Specifically
1. The MPEG Video_Sequence_Header, when present, will always be
the beginning of an RTP payload
2. An MPEG GOP_header, when present, will always be at
beginning of the RTP payload, or will follow
Video_Sequence_Header
3. An MPEG Picture_Header, when present, will always be at
beginning of a RTP payload, or will follow a GOP_header
In addition to these, it is required that
4. Each packet must contain an integral number of video slices
It is the application's responsibility to adjust the slice sizes
the number of slices put in each RTP packet so that lower
fragmentation does not occur. This approach simplifies the
while somewhat increasing the complexity of the transmitter'
packetizer. Considering that a slice can be as small as a
macroblock, it is possible to prevent fragmentation for most of
cases. If a packet size exceeds the path maximum transmission
(path-MTU) [4], this payload type depends on the lower
layers for fragmentation although, this may cause problems
packet classification for integrated services (e.g. with RSVP).
The video data is followed by a sufficient number of integral
frames to cover the duration of the video segment included in
packet. For example, if the first packet contains three 1/900
seconds long slices of video, and Layer I audio coding is used at
44.1kHz sampling rate, only one audio frame covering 384/44100
seconds of audio need be included in this packet. Since the length
this audio frame (8.71 msec.) is longer than that of the
segment contained in this packet (3.33 msec), the next few
may not contain any audio frames until the packet in which
covered video time extends outside the length of the
transmitted audio frames. Alternatively, it is possible, in
proposal, to repeat the latest audio frame in "no-audio" packets
Civanlar, et. al. Experimental [Page 3]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
packet loss resilience. Again, it is the application's
to adjust the bundled packet size according to the minimum MTU
to prevent fragmentation
2.1. RTP Fixed Header for BMPEG
The following RTP header fields are used
Payload Type: A distinct payload type number, which may be dynamic
should be assigned to BMPEG
M Bit: Set for packets containing end of a picture
timestamp: 32-bit 90 kHz timestamp representing sampling time
the MPEG picture. May not be monotonically increasing if B
are present. Same for all packets belonging to the same picture
For packets that contain only a sequence, extension and/or
header, the timestamp is that of the subsequent picture
2.2. BMPEG Specific 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P |N|MBZ| Audio Length | | Audio Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P: Picture type (2 bits). I (0), P (1), B (2).
N: Header data changed (1 bit). Set if any part of the
sequence, extension, GOP and picture header data is different
that of the previously sent headers. It gets reset when all
header data gets repeated (see Appendix 1).
MBZ: Must be zero. Reserved for future use
Audio Length: (10 bits) Length of the audio data in this packet
bytes. Start of the audio data is found by subtracting "
Length" from the total length of the received packet
Audio Offset: (16 bits) The offset between the start of the
frame and the RTP timestamp for this packet in number of
samples (for multi-channel sources, a set of samples covering
channels is counted as one sample for this purpose.)
Civanlar, et. al. Experimental [Page 4]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
Audio offset is a signed integer in two's complement form. It
a ~ +/- 750 msec offset at 44.1 KHz audio sampling rate. For a
low video frame rate (e.g., a frame per second), this offset may
be sufficient and this payload format may not be usable
If B frames are present, audio frames are not re-ordered along
video. Instead, they are packetized along with video frames
their transmission order (e.g., an audio segment packetized with
video segment corresponding to a P picture may belong to a
picture, which will be transmitted later and should be rendered
the same time with this audio segment.) Even though the
segments are reordered, the audio offset for a particular
segment is still relative to the RTP timestamp in the
containing that audio segment
Since a special picture counter, such as the "temporal
(TR)" field of [3], is not included in this payload format, lost
headers may not be detected. The only effect of this may
incorrect decoding of the B pictures immediately following the
GOP header for some edited video material
3. Security
RTP packets using the payload format defined in this
are subject to the security considerations discussed in the
specification [1]. This implies that confidentiality of the
streams is achieved by encryption. Because the data compression
with this payload format is applied end-to-end, encryption may
performed after compression so there is no conflict between the
operations
This payload type does not exhibit any significant non-uniformity
the receiver side computational complexity for packet processing
cause a potential denial-of-service threat
A security review of this payload format found no
considerations beyond those in the RTP specification
Civanlar, et. al. Experimental [Page 5]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
Appendix 1. Error
Packet losses can be detected from a combination of the
number and the timestamp fields of the RTP fixed header. The
of the loss can be determined from the timestamp, the slice
and the horizontal location of the first slice in the packet.
slice number and the horizontal location can be determined from
slice header and the first macroblock address increment, which
located at fixed bit positions
If lost data consists of slices all from the same picture, new
following the loss may simply be given to the video decoder
will normally repeat missing pixels from a previous picture. The
audio frame must be played at the appropriate time determined by
timestamp and the audio offset contained in the received packet
Appropriate audio frames (e.g., representing background noise)
need to be fed to the audio decoder in place of the lost audio
to keep the lip-synch and/or to conceal the effects of the losses
If the received new data after a loss is from the next picture (i.e
no complete picture loss) and the N bit is not set,
received headers for the particular picture type (determined from
P bits) can be given to the video decoder followed by the new data
If N is set, data deletion until a new picture start code
advisable unless headers are made available to the receiver
some other channel
If data for more than one picture is lost and headers are
available, unless N is zero and at least one packet has been
for every intervening picture of the same type and that the N bit
0 for each of those pictures, resynchronization to a new
sequence header is advisable
In all cases of heavy packet losses, if the correct headers for
missing Pictures are available, they can be given to the
decoder and the received data can be used irrespective of the N
value or the number of lost pictures
Appendix 2.
As described in [3], use of frequent video sequence headers makes
possible to join in a program at arbitrary times. Also, it
the resynchronization time after severe losses
Civanlar, et. al. Experimental [Page 6]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson
"RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[2] ISO/IEC International Standard 13818; "Generic coding of
pictures and associated audio information," November 1994.
[3] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "
Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[4] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
Authors'
M. Reha
AT&T Labs-
100 Schultz
Red Bank, NJ 07701
EMail: civanlar@research.att.
Glenn L.
AT&T Labs-
100 Schultz
Red Bank, NJ 07701
EMail: glenn@research.att.
Barry G.
AT&T Labs-
100 Schultz
Red Bank, NJ 07701
EMail: bgh@research.att.
Civanlar, et. al. Experimental [Page 7]
RFC 2343 RTP Payload Format for Bundled MPEG May 1998
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
Civanlar, et. al. Experimental [Page 8]
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
