620 likes | 728 Views
CE80N Introduction to Networks & The Internet. Dr. Chane L. Fullmer UCSC Winter 2002. Class Information. Web page tutorial available on-line Web page submission: Email to venkat@cse.ucsc.edu Subject: cmpe080n-assgn4 Final Exam Last class session March 14, 2002.
E N D
CE80NIntroduction to Networks&The Internet Dr. Chane L. Fullmer UCSC Winter 2002
Class Information • Web page tutorial available on-line • Web page submission: • Email to venkat@cse.ucsc.edu • Subject: cmpe080n-assgn4 • Final Exam • Last class session • March 14, 2002 CE80N -- Lecture #16, 2002
Personal Web Page of the Day • A few brave souls…. • Presenting: CE80N -- Lecture #16, 2002
Description of Functionality • Internet audio and video services make it possible to: • Send voice • Send live television images • Broadcast audio or video signals • Allow viewing and editing a document simultaneously CE80N -- Lecture #16, 2002
Audio And Video Require Special Hardware • Live audio or video require high bandwidth. • Requires a computer with: • A microphone • A speaker • A camera • A high-speed processor • Controls all devices electronically CE80N -- Lecture #16, 2002
Our goals: principles: network, application-level support for multimedia different forms of network multimedia, requirements making the best of best effort service mechanisms for providing QoS specific protocols, architectures for QoS Overview: multimedia applications and requirements Audio Video making the best of today’s best effort service Examples RealPlayer ISDN Videoconferencing Multimedia Networking CE80N -- Lecture #16, 2002
Audio: Air pressure converted by microphone to voltage. Magnitude represents loudness or softness Frequency represents pitch, timbre. Sampled: Voltage saved at discrete points in time Quantized: Rounded off to a discrete value (x). Video: Light converted by camera into chemical deposition Magnitude represents brightness Frequency represents edges, contrast Sampled: Values saved at each horizontal/vertical (x,y) position in time Quantized: Rounded off to a discrete value (z) for each point (x,y). Digital Audio and Video CE80N -- Lecture #16, 2002
Sample Size: 16 bit (2 byte) data representation Channels: 2 channels (stereo) Sampling Rate: 44,100 Samples Per Second(CD quality) One Channel: 2 bytes per sample x 44,100 samples per second = 88,200 bytes per second Total Data Rate: 88,200 bytes per second x 2 channels = 176,400 bytes per second Total Bit Rate = 1,411,200 bits per second This is DS1 rate!.. ADSL is typically a 384K downlink Digital Audio numbers CE80N -- Lecture #16, 2002
YCC encoding scheme Luminance = brightness (Y) Chrominance = amount of color Cb = amount of blue Cr = amount of red Images Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
Luminance = brightness (Y) Color Representation in YCC Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
Chrominance Cr = amount of red Color Representation in YCC Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
Chrominance Cb = amount of blue Color Representation in YCC Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
Luminance stored for each pixel Chrominance stored for each 4x4 block of pixels YCCEncoding Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
720 x 486 pixels per frame 29.97 frames per second (Fps) Sample Size - 8 bits per pixel data representation Sampling - 4:2:2 (Every two horizontal pixels = 2 Y : 1 Cr : 1 Cb) Luminance (Y) 720 x 486 x 29.97 x 8 = 83,896,819.2 bits per second Chrominance R (Cr) 360 x 486 x 29.97 x 8 = 41,948,409.6 bits per second Chrominance B (Cb) 360 x 486 x 29.97 x 8 = 41,948,409.6 bits per second Total = ~20 Megabytes per second Phew…… !! Ethernet is only 1.25 Mbyte/s… Digital Video numbers CE80N -- Lecture #16, 2002
Compression: Transmission of the same information in fewer bits. Run-length coding: Encode as symbol followed by number of symbols in a row. “0,0,0,0,0,0,0,0,0 ….0” replaced by “0 256” Huffman coding: (David Huffman, 1952) Builds a tree of symbols, assigning shorter bit codes to the more common symbols Arithmetic coding: Converts input symbols to a single real number Standards Images - JPEG (Joint Picture Experts Group) Video - MPEG (Moving Picture Experts Group) MP3 for audio Compression Coding Methods CE80N -- Lecture #16, 2002
Compression: Transmission of the same information in fewer bits. Audio: Silence is transmitted as blank space in run-length coding. Video: Most objects stay fixed from frame to frame. Differences between frames transmitted. Audio and Video Compression CE80N -- Lecture #16, 2002
Can save a lot of bits! Left-most picture: 24 bits per pixel Right-most picture: 9 bits per pixel Can you tell the difference? Image Compression Source: Peter Bourke http://astronomy.swin.edu.au/pbourke/colour/ycc/ CE80N -- Lecture #16, 2002
Can be lossy Left-most picture: Original Center: 10:1 compression Right-most picture: 45:1 compression Can you tell the difference? Image Compression Source: Steven Smith http://www.dspguide.com/datacomp.htm CE80N -- Lecture #16, 2002
Audio quality and Transmission Rates CE80N -- Lecture #16, 2002
Video quality and Transmission Rates CE80N -- Lecture #16, 2002
Useful chart of transmission rates: http://the-mid-west-web.com/thespeed.htm Transmission Rates CE80N -- Lecture #16, 2002
QoS network provides application with level of performance needed for application to function. Multimedia, Quality of Service: What is it? Multimedia applications: network audio and video Source: http://www-net.cs.umass.edu/cs591/ Professor Jim Kurose Used with permission Slides 18-31, 34-51 CE80N -- Lecture #16, 2002
Multimedia Performance Requirements Requirement: deliver data in “timely” manner • interactive multimedia: short end-end delay • e.g., IP telephony, telecon, virtual worlds • excessive delay impairs human interaction • streaming (non-interactive) multimedia: • data must arrive in time for “smooth” playout • late arriving data introduces gaps in rendered audio/video • reliability: 100% reliability not always required CE80N -- Lecture #16, 2002
Interactive, Real-Time Multimedia • applications: IP telephony, video conference, distributed interactive worlds • end-end delay requirements: • video: < 150 msec acceptable • audio: < 150 msec good, < 400 msec OK • includes application-level (packetization) and network delays • higher delays noticeable, impair interactivity CE80N -- Lecture #16, 2002
Interactive Multimedia: Videoconferencing Introduce Internet Phone by way of an example (note: there is no “standard” yet): • speaker’s audio: alternating talk spurts and silent periods. • pkts generated only during talk spurts • E.g., 20 msec chunks at 8 Kbytes/sec: 160 bytes data • application-layer header added to each chunk. • Chunk+header encapsulated into UDP segment. • application sends UDP segment into the network every 20 msec during talkspurt. CE80N -- Lecture #16, 2002
Internet Phone: Packet Loss and Delay • network loss: IP datagram lost due to network congestion (router buffer overflow) • delay loss: IP datagram arrives too late for playout at receiver • delays: processing, queueing in network; end-system (sender, receiver) delays • typical maximum tolerable delay: 400 ms • loss tolerance: depending on voice encoding, losses can be concealed, packet loss rates between 1% and 10% can be tolerated. CE80N -- Lecture #16, 2002
client reception constant bit rate playout at client variable network delay (jitter) buffered data client playout delay Delay Jitter constant bit rate transmission • Client-side buffering, playout delay compensate for network-added delay, delay jitter Cumulative data time CE80N -- Lecture #16, 2002
Internet Phone: Fixed Playout Delay • Receiver attempts to playout each chunk exactly q msecs after chunk was generated. • chunk has time stamp t: play out chunk at t+q . • chunk arrives after t+q: data arrives too late for playout, data “lost” • Tradeoff for q: • large q: less packet loss • small q: better interactive experience CE80N -- Lecture #16, 2002
Fixed Playout Delay • Sender generates packets every 20 msec during talk spurt. • First packet received at time r • First playout schedule: begins at p • Second playout schedule: begins at p’ CE80N -- Lecture #16, 2002
Recovery From Packet Loss • loss: pkt never arrives or arrives too late • real-time constraints: little (no) time for retransmissions! • What to do? • Forward Error Correction (FEC): add error correction bits (recall parity bits?) • e.g.,: add redundant chunk made up of exclusive OR of n chunks; redundancy is 1/n; can reconstruct if at most one lost chunk • Interleaving: spread loss evenly over received data to minimize impact of loss CE80N -- Lecture #16, 2002
Interleaving • Has no redundancy, but can cause delay in playout beyond Real Time requirements • Divide 20 msec of audio data into smaller units of 5 msec each and interleave • Upon loss, have a set of partially filled chunks CE80N -- Lecture #16, 2002
Piggybacking Lower Quality Stream CE80N -- Lecture #16, 2002
Streaming Multimedia Streaming: • media stored at source • transmitted to client • streaming: client playout begins before all data has arrived • timing constraint for still-to-be transmitted data: in time for playout CE80N -- Lecture #16, 2002
2. video sent 3. video received, played out at client 1. video recorded network delay streaming: at this time, client playing out early part of video, while server still sending later part of video Streaming: what is it? Cumulative data time CE80N -- Lecture #16, 2002
Streaming Multimedia (more) Types of interactivity: • none: like broadcast radio, TV • initial startup delays of < 10 secs OK • VCR-functionality: client can pause, rewind, FF • 1-2 sec until command effect OK • timing constraint for still-to-be transmitted data: in time for playout CE80N -- Lecture #16, 2002
? ? ? ? ? ? ? But you said multimedia apps requires QoS and level of performance to be effective! ? ? ? ? Today’s Internet multimedia applications use application-level techniques to mitigate (as best possible) effects of delay, loss Multimedia Over Today’s Internet TCP/UDP/IP: “best-effort service” • no guarantees on delay, loss CE80N -- Lecture #16, 2002
Streaming Internet Multimedia Application-level streaming techniques for making the best out of best effort service: • what is streaming? • client side buffering • multiple rate encodings of multimedia ….. let’s look at these ….. CE80N -- Lecture #16, 2002
Internet multimedia: simplest approach • audio or video stored in file • files transferred as HTTP object • received in entirety at client • then passed to player audio, video not streamed: • no, “pipelining,” long delays until playout! CE80N -- Lecture #16, 2002
Internet multimedia: streaming approach • browser GETs metafile • browser launches player, passing metafile • player contacts server • server streams audio/video to player CE80N -- Lecture #16, 2002
Downloadable: Download and save Listen later or send to others Standards-based Better quality Bandwidth burden on user Downloading takes time Streaming: Disposable Listen “on-the-fly” live Proprietary Lower quality Bandwidth burden on the developer More resources/time/cost No time lost in downloading Live broadcasting Downloadable vs. Streaming CE80N -- Lecture #16, 2002
client video reception constant bit rate video playout at client variable network delay buffered video client playout delay Streaming Multimedia: Client Buffering constant bit rate video transmission • Client-side buffering, playout delay compensate for network-added delay, delay jitter Cumulative data time CE80N -- Lecture #16, 2002
Streaming Multimedia: Client Buffering • Client-side buffering, playout delay compensate for network-added delay, delay jitter constant drain rate, d variable fill rate, x(t) buffered video CE80N -- Lecture #16, 2002
Streaming Multimedia: client rate(s) 1.5 Mbps encoding 28.8 Kbps encoding Q: how to handle different client receive rate capabilities? • 28.8 Kbps dialup • 100Mbps Ethernet A: server stores, transmits multiple copies of video, encoded at different rates CE80N -- Lecture #16, 2002
User control of streaming multimedia Real Time Streaming Protocol (RTSP): RFC 2326 • user control: rewind, FF, pause, resume, etc… • out-of-band protocol: • one port (544) for control msgs • one port for media stream • TCP or UDP for control msg connection Scenario: • metafile communicated to web browser • browser launches player • player sets up an RTSP control connection, data connection to server CE80N -- Lecture #16, 2002
Metafile Example <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> CE80N -- Lecture #16, 2002
RTSP Operation CE80N -- Lecture #16, 2002
Summary: Internet Multimedia: bag of tricks use UDP to avoid TCP congestion control (delays) for time-sensitive traffic • client-side playout delay: to compensate for network delay/jitter • server side matches stream bandwidth to available client-to-server path bandwidth • chose among pre-encoded stream rates • dynamic server encoding rate • error recovery (on top of UDP) • FEC • retransmissions, time permitting • mask errors: repeat nearby data CE80N -- Lecture #16, 2002
Example: RealPlayer RealNetworks • 1995, first streaming Internet audio (Progressive Networks) • 1997 • RealSystem (RealVideo, RealAudio, and RealFlash) • RealServer (client/server software) • Uses RTSP CE80N -- Lecture #16, 2002
Example: RealPlayer Applications: • Internet server • Wide audience (most complex/expensive) • video commercials/e-commerce capabilities • Intranet server • Internal to business • desk-top training for employees • Commerce Solution • Secure transmissions to small groups • B2B, distance-learning, briefings CE80N -- Lecture #16, 2002