powerpoint 演示文稿

• Introduction

• Characteristics of multimedia data

• Quality of service management

• Resource management

• Stream adaptation

• Case study: the Tiger video file server

• Summary

Chapter 15: Distributed Multimedia Systems

• Distributed multimedia applications– Networked video library, Internet telephony, videoco

nference

• Characteristics of multimedia applications– Timely delivery of streams of multimedia data to en

d-users• Audio sample, video frame

• To meet the timing requirements– QoS( quality of service)

Characteristics of distributed multimedia applications

• Traditional real-time system– E.g. avionics, air traffic control, telephone switching– Small quantities of data, strict time requirement– QoS management: fixed schedule that ensures worst-c

ase requirements are always met

• Different requirements of multimedia app.– General environment

• Compete with other distributed app. for network bandwidth, computing resource

– Dynamic resource requirements • E.g. the number of participants of a video conference may va

ry

– User participant in the control of resource consumption

QoS management

• Web-based multimedia– Extensive buffering– Best-effort

• Network phone and audio conference– Relatively low bandwidth– Efficient compression techniques– High interactive latency

• Video-on-demand services– Require sufficient dedicated network bandwidth

Existing distributed multimedia Apps. without QoS

• Examples– Videoconference (cooperative)– Distributed online ensemble (synchronous)

• Requirements– Low-latency communication

• round trip delays < 100 ms

– Synchronous distributed state• If one user stops a video on a given frame, the other users should see it st

opped at the same frame

– Media synchronization• All participants in a music performance should hear the performance at a

pproximately the same time

– External synchronization• Sometime, other information need to be synchronized with the time-base

d multimedia streams

• Expecting rigorous QoS management

Highly interactive applications

• A history of computer systems that support distributed data access

The window of scarcity

1980 1990

remotelogin

networkfile access

high-qualityaudio

interactivevideo

insufficientresources

scarceresources

abundantresources

2000

• Introduction






• Summary


• Continuous– Refer to the user’s view of the data– Video: a image array is replaced 25 times per second– Audio: the amplitude value is replaced 8000 times

per second

• Time-based– The delivery delay for each element is bounded in a

value– Bulky multimedia stream– Data compression

• Reduce bandwidth requirements by factors between 10 and 100

• E.g. GIF, TIFF, JPEG, MPEG-1, MPEG-2, MPEG-4

Characteristics of multimedia data

• Introduction






• Summary


• Multimedia App. compete with other App. for– Processor cycles, bus cycles, buffer capacity– Physical transmission links, switches, gateways

• Best-effort policies– Multi-task OS: round-robin scheduling

• Each task is allocated so few cycles when there are so many tasks

– Ethernet: conflict detecting• Much collisions when the network is heavily loaded

• Best-effort policies are not fit to multimedia apps.

Traditional computer systems

• Architecture of a typical system– Source

• Stream processors

– Connections• Network connection

• In-memory transfer

– Target• Each process must be allocated adequate CPU time,

memory capacity and network bandwidth

• Resource requirement

QoS management for distributed multimedia apps.

• The OoS manager’s task– Quality of service negotiation

• Apps. specify the resource requirements

• QoS manager evaluates the feasibility

• Give a positive or negative response

– Admission control• Applications run under a resource contract

• Recycle the released resource

The QoS manager’s task

• Resource requirements specification– bandwidth

• The rate at which a multimedia stream flows

– Latency• The time required for an individual data element to

move through a stream from the source to the destination

– Loss rate• Data loss due to unmet resource requirements

• A rate of data loss that can be accepted. E.g., 1%

Quality of service negotiation

• Describe a multimedia stream– Describe the characteristics of a multimedia stream in

a particular environment– E.g. a video conference

• Bandwidth: 1.5Mbps; delay: 150ms, loss rate: 1%

• Describe the resources– Describe the capabilities of resources to transport a st

ream– E.g. a network may provide

• Bandwidth: 64kbps; delay: 10ms; loss rate: 1/1000

The usage of resource requirements spec.

• Bandwidth– Specified as minimum-maximum value or av

erage value• Required bandwidth varies according to the compression

rate of the video. E.g., 1:50 - 1:100 of MPEG video

– Specify burstiness• Different traffic patterns of streams with the same averag

e bandwidth

• LBAP model: Rt + B, where R is the rate, B is the maximum size of burst

Specify the QoS parameters for streams

• Latency– The frames of a stream should be processed with the

same rate at which frames arrive– No human perception

• E.g. 150ms for interactive apps, 500ms for demand on video

– No jitter• Jitter: the variation in the period between the delivery of two adjacent

frames

• Loss rate– Typically be expressed as a probability

• Be calculated based on worst-cast assumptions or on standard distributions

Specify the QoS parameters for streams (2)

• Traffic shaping– Output buffering to smooth the flow of data

elements

• The leaky bucket algorithm– Eliminate burst– R

• A stream will never flow with a rate higher than R

– B• Size of the buffer

• Bound the time for which an element will remain in the buffer

Traffic shaping

• The token bucket algorithm– Allow larger burst– Token is generated at a fixed rate of R– the tokens are collected in a bucket of size B– Data of size S can be sent only if at least S tokens a

re in the bucket– The sender process removes these S tokens– Ensure: over any interval t, the amount of data sent

is not larger than Rt+B, • An implementation of the LBAP model

Traffic shaping (2)

• Bandwidth– The maximum transmission unit and maximum trans

mission rate– The burstiness of the stream

• The token bucket size and rate

• Delay– The minimum delay that an application can notice, t

he maximum jitter it can accept

• Loss rate– The total acceptable number of losses over a certain i

nterval– The maximum number of consecutive losses

Flow specification – RFC 1363

• Simple approach– Follow the flow of data along each stream from the s

ource to the target• The source send out a flow spec to local QoS manager

• The manager check against its database of available resources whether the requested QoS can be provided

• The flow spec is forwarded to the next node until the last node

• The result is passed from the target to the source

• Transactional QoS negotiation procedure– Deal with concurrent QoS negotiations

Negotiation procedures

• Avoid resource overload• Bandwidth reservation

– Reserve maximum bandwidth exclusively• Used for applications that cannot adapt to different QoS le

vels, e.g. x-ray video

• Statistical multiplexing– Reserve minimum or average bandwidth– Handle burst that cause some service drop level occa

sionally– Hypothesis

• a large number of streams the aggregate bandwidth required remains nearly constant regardless of the bandwidth of individual streams

Admission control

• Introduction






• Summary


• Fair scheduling– Round-robin

• Packet-by-packet• Bit-by-bit

– Weighted fair queuing

• Real-time scheduling– Earliest-deadline-first (EDF)

• Each media element is assigned a deadline by which it must be sent out

• The scheduler send media elements according to their deadline

Resource scheduling

• Introduction






• Summary


• Stream adaptation– An application adapt to changing QoS levels

when a certain QoS cannot be guaranteed

• Drop pieces of information– Audio stream

• Drop can be noticed immediately by the listener

– Video stream• Motion JPEG: easy since frames are independent• MPEG: difficult since frames are interdependent

• Increase delay– Acceptable for non-interactive applications

Stream adaptation

• When to perform scaling– Adapt a stream to the bandwidth available in t

he system before it enters a bottleneck resource

• Scaling approach– Subsample

• E.g. reduce the rate of audio sample• E.g. drop a channel in a stereo transmission

– Implementation• A monitor process at the target• A scaler process at the source

Scaling

• Temporal scaling– Decrease the number of video frames transmitted within an int

erval

• Spatial scaling– Reduce the number of pixels of each image in an vide

o stream, e.g., JPEG and MPEG-2

• Frequency scaling– Modify the compression algorithm applied to an image

• Amplitudinal scaling– Reduce the color depths for each image pixel

• Color space scaling– Reduce the number of entries in the color space, e.g., from colo

r to grey-scale presentation

Different scaling methods

• Scaling is not suitable to a stream that has several receivers– Since scaling is conducted at the source, a scale-down

message will degrade the quality of all streams

• Filtering– A stream is partitioned into a set of

hierarchical sub-streams

– The capacity of nodes on a path determines the number of sub-streams a target receives

Filtering

• Introduction






• Summary


• Video-on-demand for a large number of users– A large stored digital movie library– Delay of receiving the first frame is within a few seconds– Users can perform pause, rewind, fast-forward

• Quality of service– Constant rate– a maximum jitter and low loss rate

• Scalable and distributed– Support up to 10000 clients simultaneously

• Low-cost hardware– Constructed by commodity PC

• Fault tolerant– Tolerant to the failure of any single server or disk

Design goals

• One controller – Connect with each server by low-bandwidth network

• Cubs – the server group– Each cub is attached by a number of disks ( 2-4)– Cubs are connected to clients by ATM

System architecture

Controller

Cub 0 Cub 1 Cub 2 Cub 3 Cub n

ATM switching network

video distribution to clientsStart/Stop

requests from clients

low-bandwidth network

high-bandwidth

0 n+1 1 n+2 2 n+3 n+4 n 2n+13

• Stripping– A movie is divided into blocks

– The blocks of a movie are stored on disks attached to different cubs in a sequence of the disk number

– Deliver a movie: deliver the blocks of the movie from different disks in the sequence number

– Load-balance when delivering hotspot movies

• Mirroring– Each block is divided into several portions (secondaries)

– The secondaries are stored in the successors• If a block is on a disk i, then the secondaries are stored on disks i+1 to i

+d

– Fault-tolerance for single cub or disk failure

Storage organization

• Slot– The work to be done to play one block of a movie

• Deliver a stream– Deliver the blocks of the stream disk by disk– Can be viewed as a slot moving along disks step by step

• Deliver multiple streams– Multiple slots moving along disks step by step

• Viewer state– Network address of client– File ID for current movie– Number of next block– Viewer’s next play slot

Distributed schedule

• Block play time - T– The time that will be required for a viewer to display a block on

the client computer– Typically about 1 second for all streams– The next block of a stream must begin to be delivered T time

after the current block begin to be delivered

• Block service time – t ( a slot )– Read the next block into buffer– Deliver it to the client– Update viewer state in the schedule and pass the updated slot to

the next cub– T / t typically result in a value > 4

• The maximum streams the Tiger system can support simultaneously – T/t * the number of disks

Distributed schedule (2)

• Initial prototype [1994]– 5 x cubs: 133MHz Pentium PCs(48M RAM, 2G SCSI

disk, Windows NT), ATM network• 68 simultaneous streams with perfect quality• One cub failed, the loss rate is 0.02%

• 14 cubs: each 4 disks, ATM network [1997]– 602 simultaneous streams ( 2Mbps)– Loss rate < 0.01%; with one cub failed, loss rate <

0.04%

• The designers suggested that Tiger could be scaled to 1000 cubs supporting 30,000 clients.

• Microsoft NetShow Theater Server

Performance and scalability

• Introduction






• Summary


• Characteristics of distributed multimedia apps.– Large volumes of time-dependent data

• QoS management– QoS negotiation

• Bandwidth, latency, loss rate

• Traffic shapping: bucket leaky algorithm, token bucket leaky algorithm

– Admission control

• Schedule– Fair schedule– Real-time schedule

Summary

• Stream adaption– Scale– Filter

• The Tiger video file servers– Date layout

• Striping

• Mirroring

– Distributed schedule• slots

Summary

A typical distributed multimedia system

Wide area gateway Videoserver

DigitalTV/radioserver

Video cameraand mike

Local network Local network

Characteristics of typical multimedia streams

Data rate

(approximate)

Sample or frame frequency size

Telephone speech 64 kbps 8 bits 8000/sec

CD-quality sound 1.4 Mbps 16 bits 44,000/sec

Standard TV video

(uncompressed)

120 Mbps up to 640 x 480pixels x 16 bits

24/sec

Standard TV video

(MPEG-1 compressed)

1.5 Mbps variable 24/sec

HDTV video

(uncompressed)

1000–3000 Mbps up to 1920 x 1080pixels x 24 bits

24–60/sec

HDTV video

MPEG-2 compressed)

10–30 Mbps variable 24–60/sec

Typical infrastructure components for multimedia applications

Microphones

Camera

Screen

Window system

CodecD

BMixer

PC/workstation PC/workstation

CVideostore

Networkconnections

K

L

M

: multimedia stream

CodecA G

Codec

H

Window system

White boxes represent media processing components, many of which are implemented in software, including:codec: coding/decoding filter

mixer: sound-mixing component

Video file system

QoS specifications for components of the application shown in Figure 15.4

Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video -

640x480x16 bits

Zero -

A Codec In:

Out:

10 frames/sec, raw video

MPEG-1 stream

Interactive Low 10 ms CPU each 100 ms;

10 Mbytes RAM

B Mixer In:

Out:

2 44 kbps audio

1 44 kbps audio

Interactive Very low 1 ms CPU each 100 ms;

1 Mbytes RAM

H Window

system

In:

Out:

various

50 frame/sec framebuffer

Interactive Low 5 ms CPU each 100 ms; 5 Mbytes RAM

K Network

connection

In/Out: MPEG-1 stream, approx.

1.5 Mbps

Interactive Low 1.5 Mbps, low-loss

stream protocol

L Network

connection

In/Out: Audio 44 kbps Interactive Very low 44 kbps, very low-loss

stream protocol

The QoS manager’s task

Application components specify their QoS requirements to QoS manager

Yes No

Yes No

Flow spec.

Resource contract

Admission control QoS negotiation

QoS manager evaluates new requirementsagainst the available resources.

Sufficient?

Reserve the requested resources

Allow application to proceed

Application runs with resources as per resource contract

Negotiate reduced resource provision with application.Agreement?

Do not allow application to proceed

Application notifies QoS manager of increased resource requirements

Traffic shaping algorithm

Token generator

(a) Leaky bucket (b) Token bucket

The RFC 1363 flow Spec

Protocol version

Maximum transmission unit

Token bucket rate

Token bucket size

Maximum transmission rate

Minimum delay noticed

Maximum delay variation

Loss sensitivity

Burst loss sensitivity

Loss interval

Quality of guarantee

Bandwidth:

Delay:

Loss:

Filtering

SourceTargets

High bandwidth

Medium bandwidth

Low bandwidth

Tiger schedule

012

slot 0

viewer 4

slot 1

free

slot 2

free

slot 3

viewer 0

slot 4

viewer 3

slot 5

viewer 2

slot 6

free

slot 7

viewer 1

block play time T

block service

time t

state state state state state

powerpoint 演示文稿

Documents