Distributed Multimedia (1)

8/2/2019 Distributed Multimedia (1)

1/52

NJIT1

Distributed Multimedia Systems

Coulouris, Dollimore and Kindberg,Distributed Systems, Concepts and

Design, Chapter 17Prepared by:

Pravin Kumar Katragadda


2/52

2

Introduction

Modern computers can handle streams ofcontinuous, time-based data such as

digital audio applications and video. This capability has led to the development

of distributed multimedia applications.


3/52

3

Introduction (contd..)

The requirements of multimedia applicationssignificantly differ from real-time applications:

Multimedia applications are highly distributedand therefore compute with other distributedapplications for network bandwidth andcomputing resources.

The resource requirements of multimediaapplications are dynamic.


4/52

4

Figure 17.1 A distributedmultimedia system

Wide area ga teway Videoserver

DigitalTV/radioserver

Video cameraand mike

Local network Local network


5/52

5

Distributed Multimedia System

The above figure illustrates a typicaldistributed multimedia system, capable of

supporting a variety of applications suchas desktop conferencing, video-on-demand services, accessing stored video

sequences using web-based multimediaand broadcast digital TV/ radio.


6/52

6

Web-based multimedia

These applications provide best effortaccess to streams of audio and video data

published via the Web. Their performance is constrained with limited

bandwidth and variable latencies found incurrent networks.

These applications are most successful whenthere is little need for the synchronization ofdata streams.


7/527

Network phone and audio

conferencing

These applications have relatively lowbandwidth requirements when efficient

compression techniques are used. However, its interactive nature demands

low round-trip delays which are not always

achievable.


8/528

Video-on-demand services

These supply video information in digitalform, retrieving data from large online

storage systems and delivering them tousers display.

These are successful only when dedicated

network bandwidth is available and wherethe video server and the receiving stationsare dedicated.


9/529

Figure 17.2 Window of scarcity forcomputing and communication

1980 1990

remotelogin

networkfile access

high-qualityaudio

interactivevideo

insufficientresources scarceresources

abundantresources

2000


10/5210

The Window of Scarcity

Many of todays computer systems provide

some capacity to handle multimedia data, but

the necessary resources are very limited. Especially, when dealing with large audio and

video streams many systems are constrainedin the quantity and quality of streams theycan support. This situation is depicted as theWindow of Scarcity.


11/5211

The Window of Scarcityoperation

If a certain class of application lies within thiswindow, a system needs to allocate and scheduleits resources carefully in order to provide the

desired service. Before the window of scarcity is reached, a system

has insufficient resources to execute relevantapplications.

Once an application class has left the window ofscarcity, system performance will be sufficient toprovide the service even under adverse

circumstances.


12/5212

Figure 17.3 Characteristics oftypical multimedia streams

Data rate(approximate)

Sample or framesizefrequency

Telephone speech 64 kbps 8 bits 8000/secCD-quality sound 1.4 Mbps 16 bits 44,000/secStandard TV video(uncompressed)

120 Mbps up to 640x 480pixelsx 16 bits

24/sec

Standard TV video(MPEG-1 compressed)

1.5 Mbps variable 24/sec

HDTV video(uncompressed) 10003000 Mbps up to 1920x 1080pixelsx 24 bits 2460/sec

HDTV videoMPEG-2 compressed)

1030 Mbps variable 2460/sec


13/5213

Characteristics of multimedia data

Multimedia data (video and audio) is continuous and time-based.

Continuous data is represented as sequence of

discrete values that replace each other over time. Time-based (or isochronous data) is so called because

timed data elements in audio and video streams definethe semantics or content of the stream. The time at

which the values are played effect the validity of thedata. Hence, the timing should be preserved.

Multimedia systems are often bulky. Hence the datashould be moved with greater throughput.


14/52

14

Characteristics of multimedia data(contd..)

Figure 17.3 shows typical data rates andframe/sample frequencies.

The resource bandwidth requirements for some

are very large especially for video of reasonablequality.

A standard TV/Video stream requires more than120 Mbps.

The figures for HDTV are even higher and in video-conferencing there is a need to handle multiplestreams concurrently. Hence compression is used.


15/52

15

QoS Management

When multimedia run in networks of PCs, theycompete for resources at workstations running theapplications and in the network.

In multi-tasking operating system, the centralprocessor is allocated to individual tasks in aRound-Robin or other scheduling scheme.

The key feature of these schemes is that theyhandle increases in demand by spreading theavailable resources more thinly between thecompeting tasks.


16/52

16

QoS Management (contd..)

The timely processing and transmission ofmultimedia streams in crucial. In order to achievetimely delivery, applications need guarantees thatthe necessary resources will be allocated andscheduled at the required times.

The management and allocation of resources to

provide such guarantee is referred to as Quality ofService Management(QoS Management)


17/52

17

Figure 17.4 Typical infrastructure

components for multimedia applications

Microphones

Camera

Screen

Window system

CodecD

BMixer

PC/workstation PC/workstation

CVideostore

Networkconnections

K

L

M

: multime diastream

CodecA G

Codec

H

Window system

White boxes represent med ia p rocessing components,

many of which are implemented in software, including:codec: coding/decodingfilter

mixer: sound-mixing component

Videof ile system


18/52

18

Typical infrastructure components for

multimedia applications (contd..)

The above figure shows the most commonlyused abstract architecture for multimediasoftware.

Continuously flowing streams of media dataelements are processed by a collection ofprocessed and transferred between the

processes by inter-process connections. The processes produce, transform and

consume continuous streams of multimediadata.


19/52

19

Typical infrastructure components formultimedia applications (contd..)

The connections link the processes in asequence from a source of media elements to atarget.

For the elements of multimedia data to arrive attheir target on time , each process must beallocated adequate resources to perform its taskand must be scheduled to use the resources

sufficiently frequently to enable it to deliver thedata elements in its stream to the next processon time.


20/52

20

Figure 17.5 QoS specifications forcomponents in Figure 17.4

Component Bandwidth Latency Loss rate Resources required

Camera Out: 10 frames/sec, raw video640x480x16 bits

Zero

A Codec In:Out: 10 frames/sec, raw videoMPEG-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 Windowsystem

In:

Out:

various

50 frame/sec framebuffer

Interactive Low 5 ms CPU each 100 ms;

5 Mbytes RAM

K Networkconnection In/Out: MPEG-1 stream, approx.1.5 Mbps Interactive Low 1.5 Mbps, low-lossstream protocol

L Networkconnection

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


21/52

21

QoS specifications for components

The figure 17.5 sets out the resourcerequirements for the main software

components and network connections (inFig 17.4)

The required resources can beguaranteed only if there is a system

component responsible for the allocationand scheduling of those resources.

We refer to that as the Quality of Service

(QoS) manager.


22/52

22

Figure 17.6The QoS managers task

Application c omponents s pecify their QoS

requirements to QoS manager

Yes No

Yes No

Flow spec.

Resource contract

Admission contro l QoS negotiation

QoSmanager ev aluates new requirements

against the av ailableresources.

Suff icient?

Reserve the reques ted resources

Allow applica tion to proceed

Application runs with resources as

per resource contract

Negot iate reduced resource prov ision with application.

Agreement?

Do not allow application to proceed

Application not if ies QoS manager of

increased resource requirements


23/52

23

QoS Managers Tasks

The QoS Managers two main subtasks are:

Quality of Service Negotiation

Admission control


24/52

24

QoS Negotiation

The application indicates its resourcerequirements to the QoS manager.

To Negotiate QoS between an applicationand its underlying system an applicationmust specify its QoS requirements to theQoS manager.

This is done by transmitting a set ofparameters.


25/52

25

QoS Negotiation Parameters

Bandwidth: The rate at which data flowsthrough a multimedia stream.

Latency: It is the time required for anindividual data element to move through astream from the source to the destination.

Loss Rate: The rate at which the dataelements are dropped due to untimelydelivery.


26/52

26

Traffic Shaping

Traffic shaping is the term used to describe theuse of output buffering to smooth the flow ofdata elements.

The bandwidth parameter of a multimediastream provides an idealistic approximation ofthe actual traffic pattern.

The closer the actual pattern matches thedescription, the better the system will handle thetraffic.


27/52

27

LBAP Model of bandwidthvariations

This calls for the regulation of burstiness of themultimedia streams.

Any stream can be regulated by inserting abuffer at the source and by defining a method bywhich data elements leave the buffer.

This can be illustrated using followingalgorithms:

Leaky Bucket

Token Bucket


28/52

28

Figure 17.7Traffic shaping algorithms

Token generator

(a) Leaky bucket (b) Token bucket


29/52

29

Leaky Bucket Algorithm

The bucket can be filled arbitrarily with wateruntil it is full. Through a leak at the bottom of thebucket water will flow out.

The algorithm ensures that a stream will neverflow at a rate higher than R.

The size of the buffer B defines the maximum

burst a string an incur without losing elements. This algorithm completely eliminates bursts.


30/52

30

Token Bucket Algorithm

The elimination of bursts in the previousalgorithm is not necessary as long as bandwidthis bounded over any time interval.

The token bucket algorithm allows larger burststo occur when the stream has been idle for awhile.

Tokens are generated at a rate R and collectedin a bucket of size B. Data can be sent onlywhen atleast S tokens are in bucket.

This ensures that over any interval t the amountof data sent is not larger than Rt+B

Fi 17 8


31/52

31

Figure 17.8The RFC 1363 Flow Spec

Protocol version

Maximum transmission unit

Token bucket rate

Token bucket sizeMaximum transmission rate

Minimum delay noticed

Maximum delay variation

Loss sensitivity

Burst loss sensitivity

Loss interval

Quality of guarantee

Bandwidth:

Delay:

Loss:


32/52

32

Flow Specifications

A collection of QoS parameters is typicallyknown as a flow specification, or flow spec

for short. Several examples for flow spec exists. In

Internet RFC 1363 , a flow spec is defined

as a 16-bit numeric values, which reflectthe QoS parameters.


33/52

33

QoS Admission Control

Admission control regulates access toresources to avoid resource overload and

to protect resources from requests thatthey cannot fulfill.

An admission control scheme is based on

the overall system capacity and the loadgenerated by each application.


34/52

34

QoS Admission Control

Bandwidth reservation: A common way toensure a certain QoS level for a multimediastream is to reserve some portion of resourcebandwidth for its exclusive use.

Statistical multiplexing: It is based on thehypothesis that for a large number of streams

the aggregate bandwidth required remainsnearly constant regardless of the bandwidth ofindividual streams.


35/52

35

Resource Management

To provide a certain QoS level to an application,a system needs to have sufficient resources, italso needs to make the resources available to

an application when they are needed(scheduling). Resource Scheduling: A process needs to have

resources assigned to them according to theirpriority. Following 2 methods are used: Fair Scheduling Real-time scheduling


36/52

36

Fair Scheduling

If several streams compete for the sameresource, it becomes necessary to considerfairness and to prevent ill-behaved streams

taking too much bandwidth. A straight forward approach is to apply round-

robin scheduling to all streams in the sameclass, to ensure fairness.

In Nagle, a method was introduced on a packet-by-packet basis that provides more fairness w.r.tvarying packet sizes and arrival times. This iscalled Fair Queuing.


37/52

37

Real-time scheduling

Several algorithms were developed to meetCPU scheduling needs of applications.

Traditional real-time scheduling methods suit themodel of regular continuous multimedia streamsvery well.

Earliest-Deadline-First (EDF) scheduler uses

a deadline i.e. associated with each of itswork items to determine the next item: Theitem with earliest deadline goes in first.


38/52

38

Stream Adaptation

The simplest form of adjustment whenQoS cannot be guaranteed is adjusting its

performance by dropping pieces ofinformation.

Two methodologies are used:

Scaling Filtering


39/52

39

Scaling Best applied when live streams are sampled. Scaling algorithms are media-dependent, although

overall scaling approach is the same: to subsample

a given signal. A system to perform scaling consists of a monitor

process at the target and a scalar process at thesource.

Monitor keeps track of the arrival times ofmessages in a stream. Delayed messages are anindication of bottle neck in the system.

Monitor sends a scale-down message to the source

that scales up again .


40/52

40

Figure 17.9 Filtering

Source Targets

Highbandwidth

Mediumbandwidth

Lowbandwidth


41/52

41

Filtering

It is a method that provides the best possibleQoS to each target by applying scaling at eachtarget by applying scaling at each relevant node

on the path from source to the target. Filtering requires that a stream be partitioned

into a set of hierarchical substreams, eachadding a higher level of quality.

A substream is not filtered at an intermediatenode if somewhere downstream a path existsthat can carry the entire substream.

C t d Th Ti id


42/52

42

Case study: The Tiger videofile server

A video storage system that suppliesmultiple real-time video streams

simultaneously is an important componentto support consumer oriented multimediaapplications.

One of the most advanced prototypes ofthese is the Tiger video file server.


43/52

43

Design Goals

Video-on-demand for a large number ofusers.

Quality of Service Scalable and distributed

Low cost hardware

Fault tolerant


44/52

44

Figure 17.10 Tiger video file serverhardware configuration

Controller

Cub 0 Cub 1 Cub 2 Cub 3 Cub n

ATM switching network

video distribution to clients

Start/Stoprequests from clients

low-bandwidth network

high-bandwidth

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


45/52

45

Architecture

The cub computers shown in the Fig 17.10 areidentical PCs with the same number of hard diskdrives attached to each.

They are equipped with Ethernet and ATMnetwork cards.

The controller is another PC, not involved in the

handling of multimedia data and onlyresponsible for handling client requests and themanagement of work schedules for the cubs.


46/52

46

Storage Organization

The key design issue is the distribution of videodata among the disks attached to the cubs inorder to enable them to share the load.

Schemes used: Striping, Mirroring Movies are stored in striped representation

among all disks. This could lead to a gap in thesequence of every movie if a disk fails. This is

overcome by a storage mirroring scheme thatreplicates the data and a fault tolerancemechanism.


47/52

47

Distributed schedule

The heart of the Tigers design is the

scheduling of the workload for the cubs.

The schedule is organized as a list of slotswhere each slot represents the work thatmust be done.

There is exactly one slot for each potentialclient and each occupied slot represents 1viewer receiving a real-time video datastream.


48/52

48

Distributed schedule (contd..)

The viewer state is represented by :

Address of the client computer

Identity of the file being played

Viewers position in the file

The viewers play sequence number

Bookeeping information


49/52

49

Figure 17.11 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 timeT

block service

time t

state state state state state


50/52

50

Tiger Schedule

The block play time T is the time that isrequired by a viewer to display a block onthe client computer.

Tiger must therefore maintain a timeinterval T between delivery times of theblocks.

Each cub maintains a pointer into theschedule for each disk that it controls.


51/52

51

Tiger Schedule (contd..)

The cub steps through the schedule in real-timeprocessing slots as follows:

Read the next block into buffer storage at the

cub. Packetize the block and deliver it to the cubs

ATM network controller with the address of theclient computer.

Update viewer state in the schedule to show thenew next block and play sequence number andpass the updated slot to the next cub.


52/52

George Coulouris, Jean Dollimore and TimKindberg, Distributed Systems, Concepts andDesign, Addison Wesley, Fourth Edition, 2005

Figures from the Coulouris text are from theinstructors guide and are copyrighted by

Pearson Education 2005

Bibliography

Distributed Multimedia (1)

Documents