Media Data Streaming - Scalable Continuous Media Streaming Systems - page 116

as the contributing source identifiers (typically inserted by RTP mixers), followed by the media
data payload. A payload type field is included in every RTP packet to enable the sender (or a
RTP mixer) to dynamically switch to a different encoding format in the middle of a session.
This feature will be useful in media adaptation, e.g., switching to a lower bit-rate codec when
available network bandwidth drops. Every RTP packet also includes a sequence number and a
timestamp. The sequence number specifies the position of the payload within the media stream
being carried by the RTP flow. Thus, the receiver can always resequence the incoming data
into a proper media data stream even if out-of-order data delivery occurs in the underlying
network.
If a multimedia stream contains multiple media streams, such as an MPEG system stream
that includes an audio stream and a video stream, then the individual media streams should
be delivered over separate RTP flows, in this case, one for audio and one for video. Note
that the timestamp used in each RTP flow is not measured in real time but a sampling instant
derived from a clock that increments monotonically and linearly in time. The clock frequency
is application and payload format dependent. Thus, the timestamps from, say, an audio stream
and a video stream may not be directly comparable. Instead, the sender will periodically send
Sender Report packets using RTCP to communicate to the receivers the proper interpretation
of the timestamps for synchronization purpose. There are many other features in RTP/RTCP
and it is beyond the scope of this chapter to cover all the features. Interested readers are referred
to RFC 3550 for more details.
The RTSP/RTP/RTCP protocols have since gained increasing support from the Internet
community as well as from commercial vendors. Many commercial streaming products now
also support RTSP/RTP/RTCP streaming in addition to their proprietary streaming protocols.
Nevertheless vendors have kept some advanced features within their proprietary protocols,
such as multi-rate-encoded media streams used in adaptive media streaming.
6.3 Summary
Media data transmission comprises two separate issues - protocol and scheduling. With the
standardization of RTSP/RTP/RTCP set of protocols, more and more media streaming appli-
cations will support this set of Internet standards, thereby enhancing the inter-operability of
media servers and clients from different vendors. Scheduling, on the other hand, is a more
complex problem involving issues in admission control, resource allocation/reservation, and
data transmission scheduling. Ideally, if the media data have a fixed playback data rate, and
the network supports resource allocation (i.e., ability to allocate and guarantee a given amount
of bandwidth from a source to a destination for the duration of the media streaming session),
then the problem of transmission scheduling is nothing more than keeping the transmission
rate the same as the playback data rate.
In practice, both assumptions may be invalid - the media playback data rate may not be
constant and the available network bandwidth may also fluctuate. For example, the choice
of media encoder (CBR versus VBR codec) determines if the media playback data rate will
vary; and the underlying network architecture, e.g., whether it is a best-effort network or
one supporting QoS guarantee, determines if the available network bandwidth will fluctuate.
In Chapter 7 we investigate the scheduling problem for streaming variable bit-rate media
over a mixed-traffic network that supports resource allocation/reservation. This scenario is
representative of residential broadband networks operated by a service provider, who have