Courses/Computer Science/CPSC 441.W2014/Chapter 7: Multimedia Networking

Navigation

Course Overview	Application Layer	Transport Layer	Network Layer	Datalink Layer	Advanced Topics	Extra
Networking Basics	Chapter 2	Chapter 3	Chapter 4	Chapter 5	Chapter 7	Tutorials
Chapter 1	HTTP Over TCP			Chapter 6		Links
	Quiz Review					Textbook Notes

Introduction

Hello, my name is Carrie Mah and I am currently in my 3rd year of Computer Science with a concentration in Human Computer Interaction. I am also an Executive Officer for the Computer Science Undergraduate Society. If you have any questions (whether it be CPSC-related, events around the city, or an eclectic of random things), please do not hesitate to contact me.

I hope you find my notes useful, and if there are any errors please correct me by clicking "Edit" on the top of the page and making the appropriate changes. You should also "Watch this page" for the CPSC 441 page to check when I upload notes. Just click "Edit" and scroll down to check mark "Watch this page."

You are welcome to use my notes, just credit me when possible. If you have any suggestions or major concerns, please contact me at cmah[at]ucalgary[dot]ca. Thanks in advance for reading!

Chapter 7: Multimedia Networking

• Notes adapted from slides created by JFK/KWR and lectures held by Dr. Carey Williamson
• All material copyright 1996-2012 © J.F Kurose and K.W. Ross, All Rights Reserved

Section 7.1: Multimedia Networking Applications

Multimedia: Audio

• Analog audio signal sampled at constant rate

• Telephone: 8,000 samples/sec
• CD music: 44,100 samples/sec

• Each sample quantized, i.e. rounded

• E.g. 28=256 possible quantized values
• Each quantized value represented by bits, e.g. 8 bits for 256 values

• Example: 8,000 samples/sec, 256 quantized values: 64,000 bps
• Receiver converts bits back to analog signal:

• Some quality reduction

• Example rates

• CD: 1.411 Mbps
• MP3: 96, 128, 160 kbps
• Internet telephony: 5.3 kbps and up

• Content types

• Voice, video, data, etc.
• Voice has low demand on data rate on data sharing
• Video has higher demand

• Audio formats

• Human voice over telephone
• Constant

Multimedia: Video

• Video: sequence of images displayed at constant rate

• E.g. 24 images/sec

• Digital image: array of pixels, spatial redundancy
• Coding: use redundancy within and between images to decrease number of bits used to encode image

• Spatial (within image)

• Instead of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N)
• Each pixel represented by bits
• Similar pixels in video still image can be encoded

• Temporal (from one image to next)

• Instead of sending complete frame at i+1, send only the differences from frame i

• CBR: (constant bit rate): video encoding rate fixed, variable quality to video
• VBR: (variable bit rate): constant quality to video

• Video encoding rate changes as amount of spatial, temporal coding changes
• Fluctuates based on the amount of changes (in motion, details, etc.) in the scene

• Examples:

• MPEG 1 (CD-ROM) 1.5 Mbps
• MPEG2 (DVD) 3-6 Mbps
• MPEG4 (often used in Internet, < 1 Mbps)

• Encoded in more data intensive format
• Higher frame rate: typically 24 fps or 30 fps
• Spatial redundancy

• I.e. similar

Multimedia Networking: Application Types

• Streaming/stored audio, video

• Streaming: can begin playout before downloading entire file
• Stored (at server): can transmit faster than audio/video will be rendered (implies storing/buffering at client)
• E.g. YouTube, Netflix, Hulu

• Conversational voice/video over IP

• Interactive nature of human-to-human conversation limits delay tolerance
• E.g. Skype

• Streaming live audio, video

• E.g. live sporting event (futbol)

Back to Navigation

Section 7.2: Streaming Stored Video

Challenges

• Continuous playout constraint: once client playout begins, playback must match original timing

• But network delays are variable (jitter), so will need client-side buffer to match playout requirements

• Other challenges:

• Client interactivity: pause, fast-forward, rewind, jump through video
• Video packets may be lost, retransmitted

• Client-side buffering and playout delay: compensate for network-added delay, delay jitter
• On server side video is stored (states how many fps)

• When streaming, video needs to be sent at same rate

Client-side Buffering, Playout

(1) Initial fill of buffer until playout begins at t_p

(2) Playout begins at t_p

(3) Buffer fill level varies over time as fill rate x(t) varies and playout rate r is constant

• Playout buffering: average fill rate (x), playout rate (r):

• x < r: buffer eventually empties (causing freezing of video playout until buffer again fills)
• x > r: buffer will not empty, provided initial playout delay is large enough to absorb variability in x(t)

• Initial playout delay tradeoff: buffer starvation less likely with larger delay, but larger delay until user begins watching

• When there's a delay in the sending of frames for video over the network

• Needs to be a client side buffering to have proper playback

Streaming Multimedia

Download+Play	Streaming	Real-Time Transfer Protocol (RTP)	RTCP - RTP Control Protocol	Real-Time Streaming PRotocol (RTSP)
Obtain object first (complete copy) Complete control View whenever you want	Start viewing media before it has finished downloading Interactive control (pause, rewind, fast-forward, etc.)	UDP-based streaming 1990s RFC 3550 Simple 12-byte header Key parts Payload type Media unit sequence number Media time stamp (when media sample is recorded - ensures synchronization between video and audio) Delivery of media stream		RFC 2326 Orchestration and session control for media Play, pause, rewind, synchronizes multiple media streams Typically TCP-based Very HTTP-like

UDP vs TCP

• At transport layer
• Early days: all video streaming was UDP (video quality poor)
• Recent trend is TCP based streaming

• To get through firewalls
• Firewall configurations tend to disable UDP

• Other protocols: RTP, RTSP, HTTP, DASH

UDP

• Server sends at rate appropriate for client

• Often: send rate = encoding rate = constant rate
• Transmission rate can be oblivious to congestion levels

• Short playout delay (2-5 seconds) to remove network jitter
• Error recovery: application-level, time permitting
• RTP [RFC 2326]: multimedia payload types
• UDP may not go through firewalls

HTTP

• Multimedia file retrieved via HTTP GET
• Send at maximum possible rate under TCP

• Fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery)
• Larger playout delay: smooth TCP delivery rate
• HTTP/TCP passes more easily through firewalls

• End-to-end control of TCP between sender and receiver buffer
• Media player – application buffer for playout

DASH

• Dynamic, Adaptive Streaming over HTTP
• Server:

• Divides video file into multiple chunks
• Each chunk stored, encoded at different rates
• Manifest file: provides URLs for different chunks

• Client:

• Periodically measures server-to-client bandwidth
• Consulting manifest, requests one chunk 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)

• Video encoded at multiple bit rates
• Dynamically choose between them based on available bandwidth
• Measure delivery rate over network periodically, dynamically choose the piece
• "Intelligence" 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)

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"

• Single point of failure
• Point of network congestion
• Long path to distant clients
• Multiple copies of video sent over outgoing link

• Quite simply: this solution doesn’t scale
• Option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN)

• Enter deep: push CDN servers deep into many access networks

• Close to users
• Used by Akamai, 1700 locations

• Bring home: smaller number (10’s) of larger clusters in POPs near (but not within) access networks

• Used by Limelight

• Used commercially, popular in cloud-based delivery
• Move content closer to clients and get mirrored copies of it delivered to east/west coast/internal destinations, etc.

Example: 'Simple' Content Access Scenario

• Bob (client) requests video http://netcinema.com/6Y7B23V

• Video stored in CDN at http://KingCDN.com/NetC6y&B23V

(3) Cinema redirects Bob

(4)Bob finds out where video is

(6) Movement of video done with KINGCDN server instead of netcinema.com

CDN Cluster Selection Strategy

• Challenge: how does CDN DNS select “good” CDN node to stream to client?

• Pick CDN node geographically closest to client
• Pick CDN node with shortest delay (or minimum number of hops) to client (CDN nodes periodically ping access ISPs, reporting results to CDN DNS)
• IP anycast

• Alternative: let client decide - give client a list of several CDN servers

• Client pings servers, picks 'best'
• Netflix approach

Case Study: Netflix

• 30% downstream US traffic in 2011
• Owns very little infrastructure, uses 3rd party services:

• Own registration, payment servers
• Amazon (3rd party) cloud services:

• Netflix uploads studio master to Amazon cloud
• Create multiple version of movie (different endodings) in cloud
• Upload versions from cloud to CDNs
• Cloud hosts Netflix web pages for user browsing

• Three 3rd party CDNs host/stream Netflix content: Akamai, Limelight, Level-3

• Infrastructure is minimal
• Accounting servers keeps money
• Everything else is farmed out
• Gets all different versions of Amazon cloud and those versions sent to CDNs and dash streaming

Back to Navigation