Unformatted text preview:

1CS519: Computer NetworksLecture 9: May 03, 2004Media over InternetCS519Media over the Internet| Media = Voice and Video| Key characteristic of media:z Realtimez Which we’ve chosen to define in terms of playback, not “latency over the network”| A digitized sample of media must be “played back” at a precise time (relative to the previous sample)CS519Media samples| Media is sampled (and played out) at uniform time period| CD quality audio: 44100 samples per seconds with 16 bits per sample, stereo soundz 44100*16*2 = 1.411 Mbps| Telephone quality voice: 8K samples per second, 8 bits per samplez 8000*8 = 64 KbpsCS519Media samples| Videoz For 320*240 images with 24-bit colorsz 320*240*24 = 230KB/imagez 15 frames/sec: 15*230KB = 3.456MBps = 27.6 Mbps2CS519MPEG “compression”| MP3 audio compressionz Typical rates are 96kbps, 128kbps, 160kbpsz From 1.4Mbps: 14.6x, 10.9x, and 8.75x reduction respectivelyz With very little perceived degradation!| MPEG1 and MPEG2 video compressionz 1.5Mbps – 6Mbpsz From 27.6Mbps: 18.4x – 4.6x reductionCS519What does this compression mean to us?| Compressing periodic, fixed-size samples produces:z non-periodic, variable-size “units”CS519It’s all about receive buffer…| Receiver must reproduce timing of original compressed packetsz Timing was screwed up by the network (jitter and delay)| The more we buffer at the receiver, the more jitter we can toleratez Best case: download entire file before playing any of itz Worst case: conversational voice| We mentioned this in QoS lecture . . .CS519Receive buffer considerations| Conversational voice: we can tolerate maybe 250ms latencyz 150ms or less is betterz After network delay, 150ms – 200ms buffering| “Live” media: a few seconds latency ok| Non-live streaming media: don’t want to wait too long for start of playback3CS519Other realtime considerations| In addition to timing and variable size of compression units| Encoding schemes have different loss tolerancez Can use FEC (Forward Error Correction) to an extent| Some packets better to lose than others| Encoding schemes may be able to slow downz At the expense of qualityCS519Media-related protocolsCS519Real Time Protocol (RTP) RFC 3550| Attempt to provide common transport for many types of media| In addition to already-stated realtimerequirements:z Must run over multicastz Must allow for “mixing” of streams (i.e. for conferencing)z Must be able to combine multiple streams• Multi-media, or layered encoding over multiple multicast groupsCS519RTP design approach| Provide general header with broad capabilities| Provide separate control protocol for managing RTP streamz RTCP: Real Time Control Protocol| Each encoding type individually specifies how to use RTP4CS519Some RTP usage profiles2029 RTP Payload Format of Sun's CellB Video Encoding. 2032 RTP Payload Format for H.261 Video Streams. 2035 RTP Payload Format for JPEG-compressed Video.2038 RTP Payload Format for MPEG1/MPEG2 Video. 2190 RTP Payload Format for H.263 Video Streams.2198 RTP Payload for Redundant Audio Data.2250 RTP Payload Format for MPEG1/MPEG2 Video. 2343 RTP Payload Format for Bundled MPEG.2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 ...2431 RTP Payload Format for BT.656 Video Encoding. CS519More RTP usage profiles2435 RTP Payload Format for JPEG-compressed Video. 2658 RTP Payload Format for PureVoice(tm) Audio. 2733 An RTP Payload Format for Generic Forward Error Correction.2793 RTP Payload for Text Conversation. 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony...3016 RTP Payload Format for MPEG-4 Audio/Visual Streams.3047 RTP Payload Format for ITU-T Recommendation G.722.1.3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. 3189 RTP Payload Format for DV (IEC 61834) Video. 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit...3389 Real-time Transport Protocol (RTP) Payload for Comfort NoiseCS519RTP headerz version (V) CSRC count (CC)z padding (P) marker (M)z extension (X) payload type (PT)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+CS519RTP Header| SSRC identifierz Random 32-bit value assigned by the senderz Per media streamz In multicast, used to distinguish multiple senders• RTCP can be used to detect colliding SSRCsz Also used to synchronize multi-media streams (image and sound)• RTCP announces when SSRCs can be combined5CS519RTP Header| CSRC: Contributing Sourcez Identifies which sources were combined by a mixer| Marker: Defined by profile. z For example, can indicate frame boundary| Payload type: some well-known, some defined by profilez Indicates type of encoding (MPEG2, MPEG3, etc.)| Extension: profiles can define their own extension headersCS519RTP Header: Sequence Number and Timestamp | Timestamp indicates when the media should be played backz Expressed in units of time defined by the profile• e.g., 20 ms block size of 8,000 Hz audio Æ 160 timestamp units per packetz Not absolute time, not “synchronized”z Rather, time since initial timestampz Initial timestamp set randomlyCS519RTP Header: Sequence Number and Timestamp| Sequence number used to indicate loss and ordering| Why not use timestamp for this???CS519Timestamp and talk spurts| Receiver does not have to play out packet at exact timestamp time| In the case of voice (with gaps in between talk spurts)| Start of talk spurt may vary a littlez But within a talk spurt, timing must be rightz Think of a constant C added or subtracted from timestamp during talk spurt| Why would we do this???6CS519Receive buffer and jitter| Because of jitter, receive buffer must delay playback of voice a littlez 10’s of msz More-or-less depending on RTTz and on amount of jitter measure over time| Allows proper playback time even when some packets delayedCS519Receive buffer and jitter|


View Full Document

CORNELL CS 5190 - Lecture Slides

Download Lecture Slides
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Slides and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Slides 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?