e0262 - multimedia communications anandi giridharan electrical communication engineering, indian...

21
E0262 - Multimedia Communications Anandi Giridharan Electrical Communication Engineering, Indian Institute of Science, Bangalore – 560012, India Multimedia Communications

Upload: oswin-francis

Post on 26-Dec-2015

222 views

Category:

Documents


1 download

TRANSCRIPT

E0262 - Multimedia Communications

Anandi GiridharanElectrical Communication Engineering,

Indian Institute of Science, Bangalore – 560012, India

Multimedia Communications

E0262 - Multimedia Communications

Reflection on Multimedia Communication● High-Density File Transfers: This traffic can include everything

from low- resolution, cartoon-like images up to full-color, high-resolution photographs, as well as recorded streams of audio and/or video signals.

● High-density file transfers include three categories: graphics, audio, and video transfers.

● They share common network performance requirements: guaranteed integrity of packetized data upon delivery, without regard for the sequence or timing of that delivery. In fact, failure to retransmit damaged or dropped packets will likely result in noticeable degradation of files.

● They require the transport protocol to provide error detection and correction, as well as resequencing of the received packets. Once this is accomplished, the transport protocol hands the packets to the appropriate application for storage.

E0262 - Multimedia Communications

Graphics File Transfers●Graphics files vary in size based upon the compression algorithm used, that is, the file's format, physical size, and pixel and color density. ●Graphics have become a readily accepted form of computing since the advent of graphical user interfaces. This integration has been so successful that most users do not consider graphics to be "multimedia." ● Graphics file transmissions do not require timeliness of delivery. Damaged packets can be retransmitted and resequenced without adversely affecting the application.

E0262 - Multimedia Communications

this could be the World Wide Web (WWW). Web pages are a notorious example

of the quantitative challenge of adding a new, bandwidth-intensive, multimedia

application to an existing network.

This type of traffic is likely to contain in-line graphics embedded in text files, and

users are likely to be waiting for the graphics to be delivered. Large, complex

graphics and/or animation may require multiple retransmissions before being

successfully reassembled by the user's browser. This may take more time than the

user is willing to wait. Though not technically a time-sensitive application, this

example demonstrates the difficulty of constructing categories to define a

spectrum of uses. Fortunately, this type of multimedia communication is readily

abetted by carefully selecting graphics formats for their effectiveness in

compressing the file.

E0262 - Multimedia Communications

Audio File TransfersPre-recorded audio files can be encoded in several different formats and contain speech,

music, sounds, and so on. A transferred file can be stored either on disk or in memory.

Once received in its entirety, the file can be played back.

Audio transfers, by virtue of having been pre-recorded, can effectively utilize transmission

error detection and correction mechanisms. Temporarily storing them to disk or memory

upon receipt provides the user with a more error-free file and smoother sound quality than

is possible if the file were played back immediately upon receipt.

This temporary storage provides the time needed for damaged or dropped packets to be

identified, and re-sent. This implies that this method can create a greater volume of overall

network traffic than a streaming audio transmission would.

E0262 - Multimedia Communications

Video File Transfers

Recorded video files can also be encoded in a variety of formats. They may or may not

contain supplemental audio tracks. Those with accompanying audio will be marginally

larger than a similarly sized and same duration video-only file, but they require

synchronization of audio and video. Any errors in the received file will be more obvious

due to the temporary disruption in the continuity between image and sound.

Prerecorded video files, like their audio-only counterparts, can take advantage of

transmission error detection and correction mechanisms. Storing them to disk (memory is

probably not a viable storage option, given the likely sizes of even "small" video files)

upon receipt provides the user with a more accurate replication of the original file than

would have been possible if the file were being viewed immediately.

Temporarily storing, or buffering, the file provides the time needed for damaged or

dropped packets to be re-sent and resequenced.

E0262 - Multimedia Communications

Audio Communication

Audio communication can take three distinct forms, each with a slightly different set of network performance requirements. Specific application categories include: computer-based telephony, audio conferencing, and audio transmission.

E0262 - Multimedia Communications

Computer-Based Telephony

Computer-based telephony uses PCs and LANs/WANs to integrate voice

telephony into a data network. The client PC buffers inbound transmissions

and plays them using its sound card and speakers. This buffering can "smooth

out" the sound quality of the transmission somewhat, despite its having

traversed contention-based LANs using error-correcting protocols.

Audio communication is not bandwidth intensive. Audio can be delivered

over dialup facilities as slow as 14.4Kbps. This form of communication,

however, is extremely susceptible to corruption from packets delivered late or

out of sequence. Any such packets are discarded because, by the time a

successful retransmission can be made, the stream being played back will

likely have progressed beyond the point at which that packet was needed.

Thus, re-inserting it late creates a second disturbance that is readily

detectable by the user.

E0262 - Multimedia Communications

Computer-Based Audio ConferencingAudio conferencing differs from computer-based telephony only in that it is used in

other than point-to-point sessions. Conferences tend to be multipoint-to-multipoint in

the case of a collaborative conference of peers, or point-to-multipoint for broadcasts of

major events.

Given the half-duplex nature of this technology set, point-to-multipoint unidirectional

broadcasts may be the best use of this technology. The network must have some

mechanism for this form of multicasting. Multicasting is the transmission of a single

stream of packetized data with an address that is recognized by more than one

workstation. This is far more bandwidth- efficient than transmitting multiple

simultaneous streams, each destined for a single, specific end-point. End-points that

belong to a multicast group "listen" for both their unique Internet address, and the

address of their group.

E0262 - Multimedia Communications

Streaming AudioStreaming audio transmissions are unidirectional transmissions of a stream of audio data.

It uses a host that either records audio in real-time, or uses prerecorded audio media. In

either case, packets stream out onto the network as soon as they are generated.

Recipients listen to them as they arrive, generally without buffering them. Dropped or

damaged packets are usually left out of the playback session; some of the newer

streaming audio products on the market, however, offer the opportunity to attempt a

retransmission.

Streaming audio, like most audio-only multimedia applications, is relatively easy to

support in a LAN/WAN environment. It is low bandwidth, and benefits from but does

not require low network latency. Perhaps the most important attribute of streaming audio

technology is that it does not pretend to be a bi-directional audio transmission

technology. Therefore, its practical applications are much more readily determined.

Streaming audio can be used to distribute, on demand, either a feed from a live speech or

copies of recorded speeches, Question and Answer sessions, or even the latest disk from

your favorite group.

E0262 - Multimedia Communications

Video Communication

Video communication is the acid test of any IT platform. It requires a fairly high-

powered computer and can also be extremely bandwidth intensive. It also

benefits greatly from low-latency network components. At a minimum, it should

use network protocols that can reserve bandwidth at the time of call setup.

Video communication can occur at surprisingly low levels of throughput, given

the right compromise of picture size, quality, and refresh rate. The ideal rate of

refresh is 30 frames per second. At this rate, known as "full motion," the picture

appears smooth, and movement is smooth, not jerky. Unfortunately, even using a

small picture size, like 288 pixels by 352 pixels, the uncompressed stream is

approximately 500Kbps! This represents a generous portion of a T-1's available

bandwidth. It is also a sizeable portion of the useable bandwidth on most LANs.

E0262 - Multimedia Communications

Dropping the refresh rate to 15 frames per second dramatically reduces bandwidth

consumption, but only marginally degrades perceivable performance. The use of

sophisticated video engines, like those that offer compression "on-the-fly," can further

reduce the bandwidth consumption, albeit at an increase in CPU cycle consumption.

Decreasing the number of colors recognized can also greatly reduce the size of the

transmission stream. Similarly, reducing the size of the picture, as measured either in

inches, pixels, or fractions of a screen (for example, full-screen, quarter-screen, eighth-

screen, and so on) can also greatly reduce the transmission stream.

Unfortunately, compromises in refresh rate, color density, pixel density, and so on,

effectively translate into degraded video picture quality. An overly aggressive bandwidth

conservation effort can easily result in a jerky, tiny, ``talking head" of a video image. This

defeats the very purpose of video conferencing by failing to capture the body language and

other subtle non-verbal communication that can be gleaned from face-to-face interactions.

The trick is to understand the limitations of the networking that will support the video

transmissions, and strive for an optimal combination of tunable parameters that doesn't

have adverse affects on the network.

E0262 - Multimedia Communications

Video ConferencingReal-time, bi-directional transmissions between two or more points is known as video conferencing.

The accompanying audio can be handled "in-band" or "out-of-band." In-band audio transmissions

bundle the audio signals with the video signals in the same bit stream. This requires the video

conferencing system to have its own speakers and microphone or to interface with those already

installed in the computer.

Out-of-band audio relieves software from having to capture and play back the audio signals. It also

means the video conferencing system doesn't have to synchronize the audio and video. Rather, the

video conferencing system ignores the audio signals and requires conferees to establish a second

communication link over conventional telephony.

Because a video conference entails a bi-directional transmission, the network interconnecting the

conferenced end-points must be capable of supporting two separate video streams. If both conferees

opt for full-screen, full-motion video and use 17-inch monitors set for 1024 x 768 dots per inch (dpi)

resolution, most networks will be extremely hard pressed to deliver the desired level of service.

E0262 - Multimedia Communications

Because a video conference entails a bi-directional transmission, the network

interconnecting the conferenced end-points must be capable of supporting two separate

video streams. If both conferees opt for full-screen, full-motion video and use 17-inch

monitors set for 1024 x 768 dots per inch (dpi) resolution, most networks will be extremely

hard pressed to deliver the desired level of service.

Proprietary video conferencing hardware and software bundles have been available for

quite some time. Numerous transmission technologies are supported by these bundles,

including ISDN at 128Kbps. Ostensibly, the controlling software is smart enough to

understand the limits of the selected network, and throttles maximum quality settings

accordingly.

E0262 - Multimedia Communications

Streaming Video

Streaming video differs from video conferencing in that it is not bi-directional. Nor does it

have to be live. The streams can be either live or prerecorded, but are transmitted,

multicast, or broadcast uni-directionally.

As is the case with streaming audio, streaming video does not benefit from a network

protocol's ability to detect and correct errors, or resequence received packets. Rather, the

packets are played back immediately upon receipt. Compared to video conferencing

systems, streaming video transmission systems are fairly crude.

Although it lacks the functionality and sophistication of a video conferencing system,

streaming video may be even more useful just by virtue of being more useable. Video

libraries can be maintained of public events, speeches, meetings, and so on, and played

back on demand. Assuming the picture size and quality were carefully managed, the

streams can be supported on as little as 128Kbps, although a vastly superior video would

result from connections of 384Kbps or higher.

E0262 - Multimedia Communications

It is inevitable that the currently separate, and redundant, voice, data, and video communication infrastructure will

eventually integrate into a single, broadband, multimedia communication infrastructure, with a common user

interface and vehicle. This integration is only just beginning, and will take years to complete. It is already clear

that the LAN is capable of incrementally growing into the role of multimedia communication network. In the

interim, it is being used to support fledgling attempts at this degree of integration: today's multimedia applications.

Some of these applications require levels of performance that are difficult to achieve in a conventional

LAN/WAN environment. For example, any of the live, interactive applications like computer and video telephony,

or video conferencing, require that packets be delivered on time, in sequence, and intact! Packets that are damaged

are simply discarded without generating a request to the sender for a retransmission. Similarly, packets that are

delivered intact, but are delivered late or out of sequence are also discarded without requesting retransmission.

Today's LANs, WANs, and their protocols, are not well suited to transporting the time-sensitive data of many

multimedia communication technologies. Contemporary networks and protocols are better suited to the transport

of traditional data. They can guarantee the integrity of each packet's payload upon delivery, and are more efficient

at transporting bulk data than they are at guaranteeing timeliness of delivery.

E0262 - Multimedia Communications

Even if the LANs have been engineered to support high-bandwidth and/or low-latency

applications, WAN links can be the kiss of death. They use high-latency routers, which

function at the relatively slow Layer 3 and in conjunction with relatively low-bandwidth

transmission facilities (DS 1 or less). This can be a vexing problem as it is widely accepted

that the business value of multimedia applications, like video conferencing, is directly

proportional to the geographic distances separating the end-points. In other words, today's

networks are least capable of delivering time-sensitive applications in their highest-value

scenarios.

Similar evolution of application software and hardware will complete this evolution. Until

true multiple-media communication technologies are available, remember the benefits of

open standards. They apply universally throughout the information technologies.

Proprietary, single-function "multimedia" products, regardless of how well they perform,

are likely to impede interoperability of multimedia applications.

E0262 - Multimedia Communications

One possible exception to this could be the World Wide Web (WWW). Web pages are a

notorious example of the quantitative challenge of adding a new, bandwidth-intensive,

multimedia application to an existing network.

This type of traffic is likely to contain in-line graphics embedded in text files, and users

are likely to be waiting for the graphics to be delivered. Large, complex graphics and/or

animation may require multiple retransmissions before being successfully reassembled

by the user's browser. This may take more time than the user is willing to wait. Though not technically a time-sensitive application, this example demonstrates the difficulty of

constructing categories to define a spectrum of uses. Fortunately, this type of multimedia

communication is readily abetted by

E0262 - Multimedia Communications

RTP Sessions

●An RTP session consists of a number of applications communicating with RTP, and is identified by a network address and two ports. ●One port is used for media data and the other for RTCP (real time transfer control protocol) control data.● Session participants can send, receive, or do both. ●Each media type is transmitted in a separate session, enabling participants to choose which media types they want to receive. ●For example, a user may just want the audio portion of a streaming music video.

E0262 - Multimedia Communications

●RTP enables identification of the type of data being transmitted, and

using sequence numbers, what order the packets should be presented

in. ●Since correct packet order is not guaranteed in transmission, it is

important for the receiver to be able to order packets and detect packet

losses.● Timestamping allows synchronization of media streams from

different sources, and smooths out possible jitter and noise when real

time applications place received packets into a playback buffer. ●RTP is paired with RTCP (Real Time Transport Control Protocol)

which examines the quality of the connection and sends feedback to

the sender and receiver, allowing both to negotiate the best

transmission scheme. RTCP also provides control and identification

mechanisms for RTP transmissions.

E0262 - Multimedia Communications

RTP Application Example: A

Videoconference●In a video conference, both ends of the link need to act as RTP clients and RTP servers.● On the client end, the conferencing application needs to receive the media stream from an RTP session, order the packets, and render it onto the console. ●A conference with both audio and video would require two RTP sessions, one to handle each media type. ●On the server end, a media stream might need to be captured with a video camera, and the audio and video components would each be transmitted on a RTP session. ●If the video needed to be encoded in multiple formats for different receiver applications, several RTP sessions might be used.