Introduction - Scalable Continuous Media Streaming Systems - page 5

By contrast, the second type of media data - continuousmedia - does have explicit presenting
timing requirements embedded within the media data. The primary examples are audio and
video data. For example, video data are usually encoded into video frames to be displayed
sequentially at a certain frequency, such as 25 frames per second (fps) for the PAL video
standard or 29.9 fps for the NTSC video standard. Thus, to correctly display a video media
object, it is necessary not only to receive the video data correctly, but also to decode and
present them according to the specified timings. Failure to do so will substantially degrade the
perceived quality of the video data (e.g., resulting in jerky motions) even if the video data are
all correctly received [1]. Thus, network traffic for continuous media data are also known as
inelastic traffic because of the need to maintain the timing integrity.
Therefore, the challenge in multimedia data delivery in general and continuous media data
delivery, in particular, is to ensure the integrity in both data as well as presentation timing.
Moreover, multimedia content often comprises multiple media data streams composed accord-
ing to a synchronized presentation schedule. In such a synchronized multimedia data stream,
we then not only need to ensure the timing integrity in presenting a single media data stream,
but also the relative timing integrity between multiple synchronized media data streams as
well.
To solve the latter problem the systemwill need to schedule the data transmission of individ-
ual embedded media data objects, taking into account their relative presentation schedule and
the network bandwidth available in order to ensure the media data are available at the receiver
for synchronized playback. Alternatively, the multiple synchronized media data streams can
be multiplexed into a single data stream before delivery. The multiplexer can then take into
account the buffer size available at the decoder, as well as the timing relationships between
the embedded media data streams to interleave the media streams so that presentation timing
integrity is guaranteed (provided that the multiplexed media stream is received and buffered
according to the specification). This approach greatly simplifies the media server as the mul-
tiple media data streams can be treated as a single media data stream. The downside is less
flexibility, as the media stream composition is fixed and thus cannot be dynamically adjusted
(e.g., switching to a lower bit-rate stream when bandwidth is insufficient).
1.3 Media Delivery
Of the two types of media data discussed earlier, we will focus on the delivery of continuous
media in the rest of the topic. We can broadly classify continuous media data delivery into two
categories - real-time delivery and soft-real-time delivery.
Real-time delivery refers to applications where the media data must be delivered from the
source and presented at the destination within a given delay budget . This is most common in
applications where there are interactions between users, such as in Internet phone or video
conferencing applications (Figure 1.2).
Take Internet phone [2] as an example, the one-way delay, i.e., the delay from capturing the
voice data from the speaking user to the time the voice data are played back to the listening
user should be no more than 150ms [3]. Longer delays will lead to talking collisions, i.e., both
users trying to speak at the same time as commonly experienced in long-distance telephone
conversations, and thus this degrades the service quality.
Clearly this real-time delivery requirement often conflicts with the requirements for data
integrity and timing integrity. In fact, for applications such as Internet phone, the requirement