Download presentation
Presentation is loading. Please wait.
Published bySelina Norden Modified over 9 years ago
1
1 Multimedia Networking An Overview Done by Abdallah Quffa Khaleel Al Najjar Supervised by: Mr. Ashraf Y. MAghari
2
2 MM Networking Applications Fundamental characteristics: Typically delay sensitive Typically delay sensitive end-to-end delayend-to-end delay delay jitterdelay jitter But loss tolerant: infrequent losses cause minor glitches But loss tolerant: infrequent losses cause minor glitches Antithesis of data, which are loss intolerant but delay tolerant. Antithesis of data, which are loss intolerant but delay tolerant. Classes of MM applications: 1) Streaming stored audio and video 2) Streaming live audio and video 3) Real-time interactive audio and video
3
3 Streaming Stored Multimedia (1/2) VCR-like functionality: client can pause, rewind, FF, push slider bar VCR-like functionality: client can pause, rewind, FF, push slider bar 10 sec initial delay OK10 sec initial delay OK 1-2 sec until command effect OK1-2 sec until command effect OK need a separate control protocol?need a separate control protocol? timing constraint for still-to-be transmitted data: in time for playout timing constraint for still-to-be transmitted data: in time for playout
4
4 Streaming Stored Multimedia (2/2) 1. video recorded 2. video sent 3. video received, played out at client Cumulative data streaming: at this time, client playing out early part of video, while server still sending later part of video network delay time
5
5 Streaming Live Multimedia Examples: Internet radio talk show Internet radio talk show Live sporting event Live sporting eventStreaming playback buffer playback buffer playback can lag tens of seconds after transmission playback can lag tens of seconds after transmission still have timing constraint still have timing constraintInteractivity fast forward impossible fast forward impossible rewind, pause possible! rewind, pause possible!
6
6 Interactive, Real-Time Multimedia end-end delay requirements: end-end delay requirements: audio: < 150 msec good, < 400 msec OKaudio: < 150 msec good, < 400 msec OK includes application-level (packetization) and network delays includes application-level (packetization) and network delays higher delays noticeable, impair interactivity higher delays noticeable, impair interactivity session initialization session initialization how does callee advertise its IP address, port number, encoding algorithms?how does callee advertise its IP address, port number, encoding algorithms? applications: IP telephony, video conference, distributed interactive worlds applications: IP telephony, video conference, distributed interactive worlds
7
7 Multimedia Over “Best Effort” Internet UDP/IP: no guarantees on delay, loss UDP/IP: no guarantees on delay, loss Today’s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss But you said multimedia apps requires QoS and level of performance to be effective! ? ? ?? ? ? ? ? ? ? ?
8
8 How to provide better support for Multimedia? Integrated services philosophy: architecture for providing QOS guarantees in IP networks for individual flows architecture for providing QOS guarantees in IP networks for individual flows Fundamental changes in Internet so that apps can reserve end-to-end bandwidth Fundamental changes in Internet so that apps can reserve end-to-end bandwidth Components of this architecture are Components of this architecture are Admission controlAdmission control Reservation protocolReservation protocol Routing protocolRouting protocol Classifier and route selectionClassifier and route selection Packet schedulerPacket scheduler
9
9 How to provide better support for Multimedia? Concerns with Intserv: Scalability: signaling, maintaining per-flow router state difficult with large number of flows Scalability: signaling, maintaining per-flow router state difficult with large number of flows Flexible Service Models: Intserv has only two classes. Desire “ qualitative ” service classes Flexible Service Models: Intserv has only two classes. Desire “ qualitative ” service classes E.g., Courier, xPress, and normal mailE.g., Courier, xPress, and normal mail E.g., First, business, and cattle classE.g., First, business, and cattle class Diffserv approach: simple functions in network core, relatively complex functions at edge routers (or hosts) simple functions in network core, relatively complex functions at edge routers (or hosts) Don ’ t define define service classes, provide functional components to build service classes Don ’ t define define service classes, provide functional components to build service classes
10
10 How to provide better support for Multimedia? Content Distribution Networks (CDNs) Challenging to stream large files (e.g., video) from single origin server in real time Challenging to stream large files (e.g., video) from single origin server in real time Solution: replicate content at hundreds of servers throughout Internet Solution: replicate content at hundreds of servers throughout Internet content downloaded to CDN servers ahead of timecontent downloaded to CDN servers ahead of time placing content “ close ” to user avoids impairments (loss, delay) of sending content over long pathsplacing content “ close ” to user avoids impairments (loss, delay) of sending content over long paths CDN server typically in edge/access networkCDN server typically in edge/access network origin server in North America CDN distribution node CDN server in S. America CDN server in Europe CDN server in Asia
11
11 How to provide better support for Multimedia? R1 R2 R3R4 (a) R1 R2 R3R4 (b) duplicate creation/transmission duplicate Source-duplication versus in-network duplication. (a) source duplication, (b) in-network duplication Multicast/Broadcast
12
12 Internet multimedia: simplest approach audio, video not streamed: no, “ pipelining, ” long delays until playout! no, “ pipelining, ” long delays until playout! audio or video stored in file audio or video stored in file files transferred as HTTP object files transferred as HTTP object received in entirety at clientreceived in entirety at client then passed to playerthen passed to player
13
13 Streaming vs. Download of Stored Multimedia Content Download: Receive entire content before playback begins Download: Receive entire content before playback begins High “ start-up ” delay as media file can be largeHigh “ start-up ” delay as media file can be large ~ 4GB for a 2 hour MPEG II movie~ 4GB for a 2 hour MPEG II movie Streaming: Play the media file while it is being received Streaming: Play the media file while it is being received Reasonable “ start-up ” delays Reasonable “ start-up ” delays Reception Rate >= playback rate. Why?Reception Rate >= playback rate. Why?
14
14 Progressive Download browser GETs metafile browser GETs metafile browser launches player, passing metafile browser launches player, passing metafile player contacts server player contacts server server downloads audio/video to player server downloads audio/video to player
15
15 Streaming from a streaming server This architecture allows for non-HTTP protocol between server and media player This architecture allows for non-HTTP protocol between server and media player Can also use UDP instead of TCP. Can also use UDP instead of TCP.
16
16 constant bit rate video transmission Cumulative data time variable network delay client video reception constant bit rate video playout at client client playout delay buffered video Streaming Multimedia: Client Buffering Client-side buffering, playout delay compensate for network-added delay, delay jitter Client-side buffering, playout delay compensate for network-added delay, delay jitter
17
17 Streaming Multimedia: Client Buffering Client-side buffering, playout delay compensate for network-added delay, delay jitter Client-side buffering, playout delay compensate for network-added delay, delay jitter buffered video variable fill rate, x(t) constant drain rate, d
18
18 Streaming Multimedia: UDP or TCP? UDP server sends at rate appropriate for client (oblivious to network congestion !) server sends at rate appropriate for client (oblivious to network congestion !) often send rate = encoding rate = constant rateoften send rate = encoding rate = constant rate then, fill rate = constant rate - packet lossthen, fill rate = constant rate - packet loss short playout delay (2-5 seconds) to compensate for network delay jitter short playout delay (2-5 seconds) to compensate for network delay jitter error recover: time permitting error recover: time permittingTCP send at maximum possible rate under TCP send at maximum possible rate under TCP fill rate fluctuates due to TCP congestion control fill rate fluctuates due to TCP congestion control larger playout delay: smooth TCP delivery rate larger playout delay: smooth TCP delivery rate HTTP/TCP passes more easily through firewalls HTTP/TCP passes more easily through firewalls
19
19 Real-Time Streaming Protocol (RTSP) HTTP Does not target multimedia content Does not target multimedia content No commands for fast forward, etc. No commands for fast forward, etc. RTSP: RFC 2326 Client-server application layer protocol. Client-server application layer protocol. For user to control display: rewind, fast forward, pause, resume, repositioning, etc … For user to control display: rewind, fast forward, pause, resume, repositioning, etc … What it doesn ’ t do: does not define how audio/video is encapsulated for streaming over network does not define how audio/video is encapsulated for streaming over network does not restrict how streamed media is transported; it can be transported over UDP or TCP does not restrict how streamed media is transported; it can be transported over UDP or TCP does not specify how the media player buffers audio/video does not specify how the media player buffers audio/video
20
20 RTSP Example Scenario: metafile communicated to web browser metafile communicated to web browser browser launches player browser launches player player sets up an RTSP control connection, data connection to streaming server player sets up an RTSP control connection, data connection to streaming server
21
21 Metafile Example <title>Twister</title><session> <track type=audio <track type=audio e="PCMU/8000/1" e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> src="rtsp://audio.example.com/twister/audio.en/hifi"> <track type="video/jpeg" <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> src="rtsp://video.example.com/twister/video"> </session>
22
22 RTSP Operation
23
23 RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK S: RTSP/1.0 200 1 OK Session 4231 Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Session: 4231 Range: npt=0- Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Session: 4231 Range: npt=37 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Session: 4231 S: 200 3 OK S: 200 3 OK
24
24 Packet Loss network loss: IP datagram lost due to network congestion (router buffer overflow) network loss: IP datagram lost due to network congestion (router buffer overflow) delay loss: IP datagram arrives too late for playout at receiver delay loss: IP datagram arrives too late for playout at receiver delays: processing, queueing in network; end-system (sender, receiver) delaysdelays: processing, queueing in network; end-system (sender, receiver) delays Tolerable delay depends on the applicationTolerable delay depends on the application How can packet loss be handled? How can packet loss be handled? We will discuss this next …We will discuss this next …
25
25 Receiver-based Packet Loss Recovery Generate replacement packet Generate replacement packet Packet repetitionPacket repetition InterpolationInterpolation Other sophisticated schemesOther sophisticated schemes Works when audio/video stream exhibits short-term self-similarity Works when audio/video stream exhibits short-term self-similarity Works for relatively low loss rates (e.g., < 5%) Works for relatively low loss rates (e.g., < 5%) Typically, breaks down on “ bursty ” losses Typically, breaks down on “ bursty ” losses
26
26 Forward Error Correction (FEC) for every group of n packets generate k redundant packets for every group of n packets generate k redundant packets send out n+k packets, increasing the bandwidth by factor k/n. send out n+k packets, increasing the bandwidth by factor k/n. can reconstruct the original n packets provided at most k packets are lost from the group can reconstruct the original n packets provided at most k packets are lost from the group Works well at high loss rate (for a proper choice of k) Works well at high loss rate (for a proper choice of k) Handles “ bursty ” packet losses Handles “ bursty ” packet losses Cost: increase in transmission cost (bandwidth) Cost: increase in transmission cost (bandwidth)
27
27 Another FEC Example “piggyback lower quality stream” Example: send lower resolution audio stream as the redundant information Whenever there is non-consecutive loss, the receiver can conceal the loss. Can also append (n-1)st and (n-2)nd low-bit rate chunk
28
28 Interleaving: Recovery from packet loss Interleaving Re-sequence packets before transmission Re-sequence packets before transmission Better handling of “ burst ” losses Better handling of “ burst ” losses Results in increased playout delay Results in increased playout delay
29
29 Summary: Internet Multimedia: bag of tricks use UDP to avoid TCP congestion control (delays) for time-sensitive traffic use UDP to avoid TCP congestion control (delays) for time-sensitive traffic client-side adaptive playout delay: to compensate for delay client-side adaptive playout delay: to compensate for delay server side matches stream bandwidth to available client-to-server path bandwidth server side matches stream bandwidth to available client-to-server path bandwidth chose among pre-encoded stream rateschose among pre-encoded stream rates dynamic server encoding ratedynamic server encoding rate error recovery (on top of UDP) error recovery (on top of UDP) FEC, interleavingFEC, interleaving retransmissions, time permittingretransmissions, time permitting conceal errors: repeat nearby dataconceal errors: repeat nearby data
30
30 What will we study in this course? Empirical measurements Empirical measurements Multicast support Multicast support IP Multicast, Application layer multicastIP Multicast, Application layer multicast Content Distribution Content Distribution Scalable streaming, CDNsScalable streaming, CDNs Rate Control Rate Control TCP overview, TCP Vegas, unicast and multicast rate control protocolTCP overview, TCP Vegas, unicast and multicast rate control protocol Quality of Service Quality of Service Integrated/differentiated services, AQMIntegrated/differentiated services, AQM Packet loss recovery Packet loss recovery
31
31 Example: Streaming Popular Content Consider a popular media file Consider a popular media file Playback rate: 1 MbpsPlayback rate: 1 Mbps Duration: 90 minutesDuration: 90 minutes Request rate: once every minuteRequest rate: once every minute Can a video server handle such high loads? Can a video server handle such high loads? Approach 1: Start a new “ stream ” for each requestApproach 1: Start a new “ stream ” for each request Allocate server and disk I/O bandwidth for each requestAllocate server and disk I/O bandwidth for each request Bandwidth required at server= 1 Mbps x 90Bandwidth required at server= 1 Mbps x 90 How to improve efficiency?How to improve efficiency?
32
32 Streaming Popular Content using Batching Approach 2: Leverage the multipoint delivery capability of modern networks Approach 2: Leverage the multipoint delivery capability of modern networks Playback rate = 1 Mbps, duration = 90 minutes Playback rate = 1 Mbps, duration = 90 minutes Group requests in non-overlapping intervals of 30 minutes: Group requests in non-overlapping intervals of 30 minutes: Max. start-up delay = 30 minutesMax. start-up delay = 30 minutes Bandwidth required = 3 channels = 3 MbpsBandwidth required = 3 channels = 3 Mbps 03030 6090120150180210240 Time (minutes) Channel 1 Channel 2 Channel 3
33
33 Batching Issues Bandwidth increases linearly with decrease in start-up delays Bandwidth increases linearly with decrease in start-up delays Can we reduce or eliminate “ start-up ” delays? Can we reduce or eliminate “ start-up ” delays? Periodic Broadcast ProtocolsPeriodic Broadcast Protocols Stream Merging ProtocolsStream Merging Protocols CDNsCDNs
34
34 Another Example: Streaming Live Multimedia How to stream to large numbers of clients? How to stream to large numbers of clients? Example: A popular sporting eventExample: A popular sporting event Use multicast/broadcastUse multicast/broadcast What about client heterogeneity? What about client heterogeneity? E.g., clients might have different available b/wE.g., clients might have different available b/w Use layered/scalable videoUse layered/scalable video Internet Video Server ADSL Dial-up High-speed Access
35
35 Multimedia Networking Exciting, industry relevant research topic Exciting, industry relevant research topic Multimedia is everywhere Multimedia is everywhere Tons of open problems Tons of open problems Questions? Questions?
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.