12/7/14
Multimedia vs. Other (Ch. 2) Apps
Classes of multimedia applications:
1) Stored streaming
2) Live streaming
3) Interactive, real-time
Multimedia: Chapter 7
Sections 7.1 – 7.3
q Packet Loss?
❍ Tolerant?
❍ Intolerant?
q Variable delay between packets (jitter)?
❍
CSC 249, December 8, 2014
❍
Tolerant?
Intolerant?
7-3
Internet Evolution for Multimedia
Streaming stored video:
Services for video streaming
❍
Cumulative data
§ Client buffering
Absorb server-to-client delay; allows (temporary)
continuous playback if server-to-client bandwidth drops
below video consumption rate
§ Pre-fetching
❍
Download video at rate > consumption rate
§ Adapting quality to available bandwidth
1. video
recorded
(e.g., 30
frames/sec)
Evolution
2. video
sent
network delay
(fixed in this
example)
3. video received,
played out at client
(30 frames/sec) time
streaming: at this time, client
playing out early part of video,
while server still sending later
part of video
Best-effort service (UDP)
2. Differentiated quality of service (HTTP)
3. Guaranteed quality of service (DASH (HTTP))
1.
7-5
1
12/7/14
Client-side buffering, playout
Streaming stored video: with delay
buffer fill level,
Q(t)
client video
reception
variable
network
Delay
(jitter)
client
1. Initial fill of buffer until playout begins at tp
2. playout begins at tp,
3. buffer fill level varies over time as fill rate
x(t) varies and playout rate r is constant
time
client-side buffering and playout delay:
compensate for network-added delay, delay jitter
Streaming multimedia: HTTP
❒ Use of HTTP (TCP) has eclipsed use of UDP
❍ Fill rate fluctuates due to TCP congestion control,
retransmissions (in-order delivery)
❍ But… HTTP/TCP passes more easily through firewalls
Streaming multimedia: DASH
❒
DASH: Dynamic, Adaptive Streaming over HTTP
❒
server:
❍
❍
❒ Multimedia file retrieved via HTTP GET
❍ Sent at maximum possible rate under TCP
❍
❍
variable
rate, x(t)
❒
TCP send
buffer
server
TCP receive
buffer
application
playout buffer
client
Addresses problem of varying bandwidth available to client
Multiple copies of video are stored and encoded at
different rates
Server divides video file into multiple chunks
manifest file: provides URLs for the different copies
client:
❍
video
file
client application
buffer, size B
video server
client playout
delay
❒
playout rate,
e.g., CBR r
variable fill
rate, x(t)
constant bit
rate video
playout at client
buffered
video
Cumulative data
constant bit
rate video
transmission
❍
periodically measures server-to-client bandwidth
consulting manifest, requests one chunk of video at a time
• chooses maximum coding rate sustainable given current
bandwidth
• can choose different coding rates at different points
in time (depending on available bandwidth at time)
2
12/7/14
Streaming multimedia: DASH
1) Transfer as HTTP Object
DASH: Dynamic, Adaptive Streaming over HTTP
❒ “intelligence” is implemented at client: client
determines
❒
❍
❍
❍
when to request chunk (so that buffer starvation, or
overflow does not occur)
what encoding rate to request (higher quality when more
bandwidth available)
where to request chunk (can request from URL server
that is “close” to client or has high available bandwidth)
1. Audio or video stored in a file
2. Files transferred as HTTP object
❍
❍
Received in entirety at client
Then passed to player
audio, video not streamed!
❒ no, “pipelining,” long delays until playout
7-15
2) Metafile Example
2) Streaming From Web Server
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
1. Browser requests metafile
2. Browser launches media player, passing the metafile
3. Player contacts web server
4. Server streams audio/video to player
7-16
7: Multimedia Networking 7-17
3
12/7/14
3) Streaming from a Streaming Server
User Control of Streaming Media: RTSP
HTTP
❒ Was not designed for multimedia content
❒ No commands for fast forward, etc.
RTSP
❒ (Real-time streaming protocol)
❒ Client-server application layer protocol
❒ User control
1. Allows for non-HTTP protocol between the
rewind, fast forward, pause, resume,
repositioning, etc…
server & the media player
2. Uses RTSP (real-time streaming protocol)
7-18
Chapter 2 FTP
the file transfer protocol
FTP
user
interface
user
at host
FTP
client
local file
system
file transfer
FTP
server
7-19
FTP: separate control & data connections
TCP control connection
port 21
FTP
client
remote file
system
TCP data connection
port 20
FTP
server
The Server:
❒ Listens on port 21 for an incoming connection request
❒ When server receives a command for a file transfer,
the server opens a TCP Data Connection to client
❒ After transferring one file, server closes the data
connection.
4
12/7/14
FTP: separate control & data connections
TCP control connection
port 21
FTP
client
TCP data connection
port 20
FTP
server
q The server opens a second TCP data connection to
transfer another file, using the same control connection.
q The control connection remains open until ‘logout’
q The control connection is “out of band”
q FTP server maintains “state”: current directory, user
authentication
RTSP: out of band control
RTSP uses “out-of-band”
message channel:
❒ RTSP control
messages use
different port
numbers than media
stream
❒ The actual media
stream is considered
“in-band”
FTP uses “out-of-band”
control channel:
❒ Control info (directory
changes, file deletion,
rename) is sent over
one TCP connection
❒ File transfer occurs
over a second TCP
connection.
❒ “Out-of-band” & “inband” channels use
different port
numbers
7-23
RTSP Operation
3) Streaming from a Streaming Server
1. Allows for non-HTTP protocol between the
server & the media player
2. Uses RTSP
7-24
7-25
5
12/7/14
Content distribution networks
❒
❒
challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
option 1: single, large “mega-server”
❍
❍
❍
❍
Content distribution networks
❒
❒
single point of failure
point of network congestion
long path to distant clients
multiple copies of video sent over outgoing link
challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
option 2: store/serve multiple copies of videos at
multiple geographically distributed sites (CDN)
❍
Use DNS to determine location of client
…. this solution doesn’t scale
Summary
Case study: Netflix
Amazon cloud
upload copies of
multiple versions of
video to CDNs
❒ Evolution: UDP à HTTP à DASH
Akamai CDN
❒ Streaming stored video
❒ Three scenarios for transferring
Netflix registration,
accounting servers
2. Bob browses
Netflix video 2
3. Manifest file
returned for
requested video
❍ As
Limelight CDN
3
1
1. Bob manages
Netflix account
4. DASH streaming
Level-3 CDN
HTTP object
web server
❍ From streaming server
❍ From
❒ Compare RTSP to FTP
❒ Content distribution networks
7-29
6