Chapter 17 Multimedia Distance Learningread.pudn.com/downloads97/ebook/395992/Multimedia Image and … · Deshpande, Sachin G. et al. “Multimedia Distance Learning” Multimedia

Deshpande, Sachin G. et al. “Multimedia Distance Learning”Multimedia Image and Video ProcessingEd. Ling Guan et al.Boca Raton: CRC Press LLC, 2001

© 2001 CRC Press LLC

Chapter 17

Multimedia Distance Learning

Sachin G. Deshpande, Jenq-Neng Hwang, and Ming-Ting Sun

17.1 Introduction

The ultimate goal of distance learning systems is to provide the remote participant most ofthe capabilities and the experience close to that enjoyed by an in-class participant. In fact, anon-real-time distance learning system can provide features that produce a better environmentthan a live class. There has been rapid progress in digital media compression research. Startingwith MPEG-1 [1], MPEG-2 [2] at the higher bit rate range (Mbps) to H.261 [3] (p×64 Kbps)and H.263(+) [4] (≥ 8 Kbps) at the low-bit-rate range, digital video coding standards canachieve a bit rate and quality suitable for the various network bandwidths in the current het-erogeneous networking environments. The MPEG-4 [5] video coding standard is currentlybeing formalized and aims at providing content-based access along with compression. Indigital audio coding, MPEG, GSM [6], and G.723.1 [7] are among the state-of-the-art codingstandards.

Because of the Internet and the heterogeneous network structure typically in use currently,end users have various network bandwidths. A T1 line can support 1.5 Mbps, whereas a modemuser may have only a 28.8 or 56 Kbps connection. Corporate intranets and campus local areanetworks (LANs) can support bandwidths of several Mbps. Cable modem [9] and asymmetricdigital subscriber line (ADSL) [10] technologies promise to bring high-speed connections tohome users, but they are not ubiquitous yet. Because of this, a scalable encoder and layeredcoding is preferred because a low-bandwidth user can decode only the base layer and clientswith higher bandwidth capability can decode enhancement layer(s) in addition to the baselayer. H.263+ offers a negotiable optional coding mode (Annex O) that supports temporal,signal-to-noise ratio (SNR), and spatial scalability.

There are several distance learning systems available, notably Stanford-online [8, 11], andvarious industry products including those from RealNetworks [12], Microsoft Vxtreme [13],and Microsoft Netshow [14]. The majority of the services and products in this category allow areal-time streaming broadcast of live contents (classes or lecture talks for the distance learningsystems) or on-demand streaming of stored contents. On the other hand, there are variousvideophones, video conferencing, and net meeting software products on the market, includingIntel Video Phone [15], White Pine’s Enhanced CU-SEEME [16], Meeting Point, and Mi-crosoft NetMeeting [17], which support real-time interactive two-way communications. Withaffordable audio–video capture cards and cameras, the progress in low-bit-rate coding, and theso-called x2 technology [18], home users can participate in a video (and audio) conference at56 Kbps or lower. It is thus the next step to combine these two types of services and provide


a virtual distance learning classroom that is interactive [24, 27]. The live class interactionor talk will be streamed (unicast/multicast) to remote sites where students can participate byasking questions in real time, under the control of a central multipoint controller unit (MCU).Another mode allows a student to view on-demand video courses and ask questions during theoffice hours of the instructor or a teaching assistant.

FIGURE 17.1Virtual classroom application characteristics.

The majority of the current products mentioned above need a plug-in to be able to accessthe synchronized media on the Internet using a Web browser. Sun Microsystems’ Java MediaFrameWork (JMF) [19] is aimed at providing a framework that will make synchronized mul-timedia possible in the future without special plug-ins. However, Java has typically been slowfor real-time multimedia decoding. The Just In Time (JIT) compiler and native methods offera somewhat acceptable solution to this. However, JMF 1.0 does not support capturing andrecording of media. This is planned to be a feature of JMF 2.0. Real media architecture [20]is also similar to JMF. For networking, real-time transport protocol (RTP) [21] (and real-timetransport control protocol — RTCP) on top of user datagram protocol (UDP) is preferred forlow-overhead media delivery of real-time data. Real-time streaming protocol (RTSP) [22] isthe application-level protocol that allows control over the delivery of real-time media and isoften described as “network remote control.” The International Telecommunication Union(ITU-T) recommendation H.323 [23] is a standard for packet-based (including Internet) multi-media communication systems. A majority of the videophone and video conferencing productsare H.323 compliant. This standardization helps in their interoperability.

For non-real-time (on-demand) distance learning applications, it is important to add multime-dia features that will enrich the user experience. Multimedia features such as hypervideo linkscross-referencing the course materials and video, and synchronized and automatic databasequeries listing the additional references or course notes in addition to the synchronized video,audio, text captions, and slides are useful and effective [25, 26]. Non-real-time multimediadistance learning applications need special tools that help the instructor embed multimediafeatures and synchronize various media. Automating this content creation as much as pos-sible is important. As an example, a speech recognition system can automatically create thetext captions for a talk. Thus, manual typing or text extraction (from electronic notes) of thecaptions is avoided.

In Section 17.2 we present the design and the development of a real-time virtual classroomdistance learning system. A crucial component of the virtual classroom is the way electronicand handwritten slides are handled. This is discussed in Subsections 17.2.1 and 17.2.2, respec-tively. Section 17.3 describes various multimedia features useful for a non-real-time distancelearning system. Section 17.4 various issues are raised. Section 17.5 provides a summary anda conclusion.


17.2 Interactive Virtual Classroom Distance Learning Environment

A virtual classroom environment aims at simulating a real classroom for remote participants.Thus, the remote participant can receive a live class feed and is also able to interact and partic-ipate in the class by asking questions. Since there are possibly multiple remote participants, acentralized MCU handles the question requests from the remote sites. Figure 17.2 shows anexample of a virtual classroom distance learning environment.

FIGURE 17.2Virtual classroom interactive distance learning environment.

All the participating terminals can passively receive the live class broadcast and activelycommunicate in a point-to-point fashion with the MCU. Remote users send a request for aquestion they want to ask to the instructor. The MCU puts this request on a waiting queue ofquestion requests. Under the control of the instructor and based on a fairness policy, the MCUresponds to let the remote participant start streaming his video and audio and ask a question.The participants transmit their audio, video, and/or datastreams to the MCU. The MCU consistsof [23] a multipoint controller (MC), which controls the remote participants’ question requests,and a multipoint processor (MP), which switches between the media streams from the class andthe remote terminals under the control of the MC. The MC is also responsible for streamingthis media to all the remote terminals. After finishing the question the particular remote userrelinquishes control (or the MC timeout for a user occurs) and the instructor responds to thequestion or is ready to take further questions and to continue the talk. Figures 17.3 and 17.4show a typical virtual classroom session with the live class server and the remote participantclient during the instructor’s video and during the question time.

The remote participants are classified, based on their transmission capabilities, into thefollowing categories:

• Users with both audio and video transmission capability

• Users with audio-only transmission capability

• Users with no transmission capability.


FIGURE 17.3Virtual classroom live class server. (a) Instructor’s video; (b) remote student’s videoduring question time.

This selection is done during the initial capabilities exchange between the remote participantsand the MC. The users who do not have any transmission capability can join the virtualclassroom as passive recipients. Similarly, it is also possible to allow a remote participant withonly audio transmission capability to use it to transmit his or her question. In this case theMC will transmit the audio for their question along with the video of the live class during theirquestion time. It is also possible to maintain a central database of currently registered remoteparticipant students for the class and display their picture during the time their audio is beingtransmitted. For remote participants who have frequently asked questions (FAQs) and are notwilling to ask them in public, an interface allows them to send these queries to the MCU,which will automatically handle them by querying a precompiled database or handbook. Onlythe student who initiated this query will get the results. The MCU also handles the job ofrecording the live interactive session, so that it is immediately available after the live class, asa stored on-demand system.

In a situation where participants have the capability and network bandwidth to receive twolive feeds simultaneously, the MCU can transmit a separate class feed and remote participantsfeed. In this case the remote participants feed consists of the question requests and during theidle time when there are no questions in the queue, the MCU polls the remote sites according tosome fair algorithm and streams the media from all the remote participants (one at a time) with atransmit capability. In this scenario it is also possible to do segmentation and create a compositevideo at the MCU. The composed video will consist of video object planes (VOPs) [5] whereonly one VOP has the currently active remote participant and all the other VOPs are static andhave the previously segmented frames of the other remote participants. The MCU can alsohandle the job of transcoding the compressed audio–video data. The transcoding could bedone either in the pixel domain or in the compressed domain. The transcoding can be useful


FIGURE 17.4Virtual classroom client. (a) Instructor’s video; (b) remote student’s video during ques-tion time.

in a variety of scenarios (e.g., for bit rate conversion, compression formats, inter conversion,etc.).

Figure 17.5 shows the protocol used between the MCU and the live class server. Table 17.1gives a brief description of each message exchanged between the two. A reliable communica-tion mechanism (e.g., TCP/IP) is used for all the control (CTRL) signaling. UDP is used forall the real-time media (video, audio) data (DATA) because of its low overhead. Figure 17.6and Table 17.2 similarly show the protocol used between the MCU and a client with both audioand video transmission capability. The MCU is connected to one live class server and multipleclients at any given time.

We now discuss various methods to improve a remote participant’s experience in a virtualclassroom.

17.2.1 Handling the Electronic Slide Presentation

Many instructors use electronic presentation material in their classes. During the courseof the lecture the instructor flips these slides according to the flow of his or her narrative.The flipping times are not known a priori. The low-bit-rate video encoding standards are noteffective in encoding the slides used in a typical classroom.

Figure 17.7 shows a display at the remote client side of the slide data which was encodedusing the conventional video coding standard. This video was taken from the University of


FIGURE 17.5Interaction between the MCU and the live class server.

FIGURE 17.6Interaction between the MCU and a remote participant client with audio and videotransmission capability.


Table 17.1 Messages Exchanged Between the MCU and the LiveClass Server

Message Type Description

LCServer_Connect Control Live class server initiates a connectionand registers with the MCU; this is thestart of a virtual classroom session

LCServer_Connect_Ack Control MCU acknowledges live class serverconnection

Send_Media Control Live class server notifies MCU that it isready to send media data

Send_Media_Ack Control MCU acknowledges and asks the liveclass server to start streaming the media(video, audio) data

Send_Class_Video Data Live class server begins streaming thecompressed video data to the MCU

Send_Class_Audio Data Live class server begins streaming thecompressed audio data to the MCU

Recv_Media Control Live class server request to the MCU toreceive the virtual classroom media data

Recv_Media_Ack Control MCU acknowledges the receive mediarequest

Recv_Video Data MCU starts streaming the virtual class-room video data to the live class server;this allows the instructor to receive re-mote student question video during thequestion time

Recv_Audio Data MCU starts streaming the virtual class-room audio data to the live class server;this allows the instructor to receive re-mote student question audio during thequestion time

Disconnect_LCServer Control The live class server disconnects from theMCU; this is the end of the virtual class-room session

Washington’s Televised Instructions in Engineering (TIE) class. As is obvious from the figure,the display is too small and the resolution is low. This impairs the effectiveness of the virtualclassroom. Also, the instructor typically pans or zooms on the slide to give the students a betterview. This results in a lot of wasted bits when the video sequence is encoded. The solution tothis is to send the original electronic slide to the client machine only once.

We have designed and developed a real-time interactive Web-based presentation system toovercome the above drawback. This Web-based client–server system is called “slidecast.”Currently, a few Web presentation systems (e.g., Contigo’s Itinerary Web Presenter 2.1 [28])exist. However, they are restrictive and lack the features required for a distance learningenvironment. In our system the instructor selects an appropriate slide URL at the server whenhe wants to flip the next slide. The remote participant’s client (a Java applet in a Web browser)automatically flips the slide to the new one every time it is flipped by the instructor. Theinstructor can also draw, mark, or point on the slides in real time, and the same drawings,markings, or pointers will appear on the client’s slides. The markings are retained so that the


Table 17.2 Messages Exchanged Between the MCU and a Remote Participant Client

Message Type Description

Client_Connect Control A remote client initiates a connection and registers with theMCU; this is the start of a virtual classroom session for theclient

Client_Connect_Ack Control MCU acknowledges client connectionRecv_Media Control Client request to the MCU to receive the virtual classroom

media dataRecv_Media_Ack Control MCU acknowledges the receive media request

Recv_Video Data MCU starts streaming the virtual classroom video data to theclient; the client receives the instructor’s video or a remotestudent video (during the question time)

Recv_Audio Data MCU starts streaming the virtual classroom audio data to thelive class server; the client receives the instructor’s audio orthe remote student audio (during the question time)

Question_Request Control This client notifies the MCU that it is interested in asking theinstructor a question; this is similar to raising the hand bya student in a real classroom

Question_Request_Ack Control The MCU acknowledges the question request and puts therequest in a queue of possibly pending questions; this allowsthe instructor to answer the questions at a suitable time

Start_Question Control The MCU allows and asks the remote client to start its ques-tion; this happens after the instructor permits the questionrequest

Send_Client_Video Data Client starts streaming the compressed video data to the MCUSend_Client_Audio Data Client starts streaming the compressed audio data to the MCU

End_Question Control Client notifies the MCU that it has finished its questionQuestion_Timeout Control The MCU can end the remote participant’s question after a

fixed timeout interval; this is provided so that the MCU hasthe total control of the session

Disconnect_Client Control The client disconnects from the MCU; this is the end of thevirtual classroom session for this client

instructor can go back and forth between the slides. Markings can also be cleared at any time.The system also allows the instructor to send text instructions to the remote student’s clients.Similarly, students can ask questions in real time but do not bother the instructor, as wouldhappen in a real classroom setting, by sending text to the instructor in real time. A private chatbetween the students is also possible. The system is also be capable of handling late arrivals(i.e., those remote participants who join the session in the middle will get all the slides alongwith the markings and text that has already been sent in the session). It is also possible to usethe slide presenter server as a whiteboard controlled by the instructor.

Figure 17.8 shows the slide presenter server which the instructor can use for presentations.The figure shows a list of slide URLs with navigation controls, connected remote participants,the slide presentation area, the drawing and marking tools, and a text chat area. Figure 17.9shows the client’s view of the presentation. This includes the slides along with the markings,text chat, a list of URLs, and a list of remote participants.

Security and privacy of the remote participants is an important issue in the design of the Web-based presentation system. In general, (untrusted) applets loaded over the net are preventedfrom reading and writing files on the client file system and from making network connections


FIGURE 17.7Display of the video-encoded slides at the remote client site.

except to the originating host. This is a very useful security feature. However, this leads totwo possible architectures for our slide presentation system. Figures 17.10a and b show thepossible architectures.

In the first architecture (Figure 17.10a), the slide server and the Web server run on the samehost. Thus, the remote participant (using the applet downloaded from this Web server) canopen a network connection with the slide server. In the second architecture (Figure 17.10b),the Web server and slide MCU are on the same host. The slide presentation server and all theremote slide clients carry out their data and control traffic through the slide MCU.

17.2.2 Handling Handwritten Text

Another popular form of presentation is for the instructor to write notes during the classeither on a whiteboard or on a piece of paper. In the University of Washington’s TIE classes,an instructor typically writes on a piece of paper. A video of this writing, compressed at lowbit rates using the current low-bit-rate video coding techniques, results in a decoded video inwhich the written material is not very legible. This can be seen in Figure 17.11. We haveproposed a new video coding scheme suitable for coding the handwritten text in a much moreefficient and robust way utilizing and extending the well-known still image coding algorithms.We use the JBIG [29, 30] standard for bilevel image encoding to compress the handwrittentext. The video of the handwritten text typically need not be sent at a very high frame rate.


FIGURE 17.8Slide presenter server.

This is because the speed at which an instructor writes is restricted. This will also result ina lower required bit rate. This also allows us to use a higher spatial resolution (CIF) for thetext video. The overall scheme also results in a bit rate savings. It is also possible for thoseremote participants with a very low connection speed to receive only the audio and the slides(electronic and handwritten).

Figure 17.12a shows the original video frame with handwritten text material. Figure 17.12bshows the output after using the JBIG compression. The difficulties involved in this schemeinclude the threshold determination and avoiding and/or tracking the hand movements.

17.3 Multimedia Features for On-Demand Distance LearningEnvironment

Course-on-demand distance learning systems use non-real-time encoding. Thus, it is pos-sible to add multimedia features and annotations to these media. This is typically done by theinstructor, teaching assistant, or trained staff member. The challenge in this type of system


FIGURE 17.9Slide flipper client Java applet in a browser.

FIGURE 17.10Slide presentation system, possible architectures.

is to automate most of the feature creation. Also, user-friendly content creation and editingtools help the instructor easily add such features. The created contents are then uploaded toa media server which can serve multiple clients by streaming the stored contents. There aremany advantages to using a separate media server as opposed to the Web server to stream thecontents. HTTP used by the Web server is not designed with the goal of streaming media toclients with heterogeneous network bandwidths. A media server can use various application-


FIGURE 17.11Client-side display of handwritten material in a live class.

FIGURE 17.12(a) Uncompressed video frame of handwritten material in a live class; (b) JBIG com-pressed video frame.


level protocols (e.g., RTSP [22]) to control and initiate the media streaming. Similarly, RTPand RTCP [21] have been designed to handle data with real-time properties.

It is important to add multimedia features to the video and audio streams. For distancelearning systems, we have developed and found useful the following features [25, 26]:

• Hypervideo links: These are similar in concept to hypertext. Many instructors makeuse of a whiteboard during their classes. Thus, there could be various hyperregionson a video frame. These regions would be bounding boxes for something importantwritten on the whiteboard. Clicking on this hyperregion would allow the user to jumpto another class (perhaps a previous sequence class) that gives details about the materialin the hyperregion. As an example, in a graduate-level class on digital video coding, theinstructor mentions DCT as a popular transform coding method. Then the video frameregion where the DCT equation is written on the whiteboard could be hyperlinked with avideo frame of an undergraduate-level class on transform coding. The transform codingclass similarly could have cross-linking with, say, a basic class on Fourier theory.

• Database queries: Associated with each hyperregion will also be an automatic databasequery. Thus, students interested in more reference material or papers could get suchmaterial either from precompiled course notes or other databases. It is also possible tolink this to the university library search, which can list relevant papers or texts availableon the subject. Continuing the same example as above, the DCT hyperregion will havean automatic query for the keyword dct.

• Text captions: The instructor’s talk will appear as text captions which are synchronizedwith the video and audio. It is thus possible for students with various needs includinghearing problems to read the text if they find it difficult to follow the instructor’s accentor speed. These text captions can also be downloaded and saved during the progressionof the class.

• Slides: Apart from using the whiteboard, instructors also make use of electronic slidesduring their lectures. These slides are usually available in an electronic form. It is thuspossible to have a synchronized presentation with the video, audio, text captions, andslides. All these media together can give the student a feeling similar to that of a liveclass.

• Random access and keyword jumps: The standard VCR trick modes are provided for theclass media. Also, there are various keywords that correspond to the topics covered inthe class. Clicking on these keywords would allow students to jump to the appropriateposition in the media. Thus, advanced-level students can skip the material they arefamiliar with and only go through the new material.

We have developed a media browser that supports these features. A screen shot of thebrowser is shown in Figure 17.13. Figure 17.14 shows the concept of hypervideo links andautomatic database queries between two different class videos.

17.3.1 Hypervideo Editor Tool

Creating the above-mentioned features and synchronizing various media require a multime-dia authoring tool [25, 26]. The hypervideo editor tool allows marking of various hyperregionson the video frames. We have developed this tool to assist the instructor in the creation of thehypervideo links. The user interface and a typical session of this tool is shown in Figure 17.15.

The instructor can mark rectangular regions on the frames as shown in the figure. Thehypervideo entries for each region can be edited by using a form associated with the marked


FIGURE 17.13Screen shot of distance learning media browser.

FIGURE 17.14Hyperlinking between different class videos.


FIGURE 17.15Display of a typical session of interactive hyperlink creation using the hypervideo editortool.

regions. The figure shows arrows which indicate a typical scenario in which the hyperlinksfor different courses are created, cross-referencing each other. The arrows indicate that theinstructor wants the course material for the top-left video associated by a hyperlink with themarked course material in the top-right video. Similarly, the instructor is editing anotherhyperlink between the appropriate frames of the top-right video and the bottom-left video.The instructor can navigate the video using Next, Prev buttons, which allow traveling oneframe at a time in the forward and backward directions. In the distance learning application,typically the video data frames are available at rates ranging from 10 to 30 frames per second.In this case there may not be significant change in adjacent frames and typically the userwill set up the hyperlinks after every several frames. In such a case a fast-forward and fast-backward random access is useful, which allows the user to edit only those frames. Fast>>and Fast<< buttons allow this functionality. In addition, a slider bar is provided which allowsusers to randomly jump to any frame of the sequence for editing. The Movie option allowsusers to watch all the frames of the sequence as a movie.

We are currently working on a tool that automates the hyperlink content creation. This isexplained in the next subsection.


17.3.2 Automating the Multimedia Features Creation for On-Demand System

It was observed that a considerable effort is necessary to cross-link between the various classvideo sequences. Thus, automation of this process is highly desirable. We are developing atool that allows the instructor to mark hyperregions on the slides and/or video frames and typein a keyword for the region. The authoring tool will automatically search a database for thiskeyword and assist the instructor with a list of possible hyperlinks to videos and slides of similartype. The authored material will then be used in a video-on-demand system. The architectureis shown in Figure 17.16. The Web server will host the electronic slides. The client applet willalso be downloaded from this host. The media server will host the compressed media (videoand audio). The database server will have a database of all the slides and associated links. Thepresentation server will handle the client requests for additional information.

FIGURE 17.16On-demand system architecture.

17.4 Issues in the Development of Multimedia Distance Learning

The issues involved in the design of multimedia distance learning systems can be classifiedat two levels. At one level we have to look at technology and at the other level the effectivenessof the system for students and for the instructors. It is important that a state-of-the-art distancelearning system is ultimately useful and allows a natural flow of the class sequence withoutfeeling awkward or requiring extra effort. It is also important to remember that a live class hasa different set of characteristics than a video conference or a video broadcast. In the real-timevirtual classroom, the MCU should be able to totally control the session flow and the instructorshould be able to override the MCU in case of any unforeseen situation. The security of thevirtual classroom session and authentication of the remote users is also an important aspect.The MCU is responsible for handling these issues.

The major research aspects of the distance learning system are related to media compressionand media delivery. Network delivery of the compressed media, synchronization of differentmedia streams, error mitigation schemes to handle lost packets, handling packet delay, and


multicast routing of the media data are active research aspects. For the encoder, developingscalable, fast, high-quality software-only compression is the main research area. We will verybriefly look at some of the issues that concern a multimedia distance learning system.

17.4.1 Error Recovery, Synchronization, and Delay Handling

The recovery of lost packets, synchronization of different media streams, and end-to-enddelay minimization are three interrelated aspects. For an interactive system, the end-to-enddelay tolerable is about 250 to 400 ms. Because of the use of RTP/UDP for real-time transport ofmedia streams, the packets could be lost, get duplicated, or arrive out of order. Because of highdelay sensitivity of the interactive virtual classroom, a very late arriving packet is in fact treatedas a lost packet. The lost packets are typically detected using missing RTP sequence numbers.There exist various approaches to handle lost packets. The schemes could be classified based onthe amount of extra processing requirements at the server or client side [31]. For an interactiveapplication, the delay induced by forward error correction (FEC) [32] or interleaving-basedschemes [33] may not be acceptable. Similarly, the retransmission-based schemes [33] arealso infeasible because of the delay considerations. Thus, the most popular method is for theencoder to add some media-dependent redundant information in the bitstream, and for thedecoder to use this information along with error concealment methods. The delay jitter ishandled by buffering at the receiver end. The RTP time stamp is used for determining theplayout times for the packets. The synchronization between various media streams is handledby the time stamp information for the individual streams. Typically, one stream is used as aso-called master stream.

17.4.2 Fast Encoding and Rate Control

The single most computationally intensive component of a typical video encoder is motionestimation. Thus, fast and robust motion estimation methods [34] are used for improving thespeed of encoding. However, with the currently available computing power, even on a personalcomputer, the main bottleneck for high-quality encoding is largely due to the low bandwidthconnections at the client sites. Thus, a layered encoding approach with a good rate controlmechanism is very important.

17.4.3 Multicasting

With a large number of concurrent connections to the server or MCU, the bandwidth require-ment at the server end for unicast sessions would be huge and would not scale well. Unicasttransmission requires sending the same datagram packet to each connected user separately.This results in an inefficient use of network bandwidth. Multicasting [35] attempts to solvethis problem and avoids the delivery of the same media data multiple times on the same links.In multicasting, a packet is transmitted just one time to multiple users. The packet will beduplicated only at a router when the paths diverge.

17.4.4 Human Factors

Human factors play a significant role in the effectiveness and success of a multimediadistance learning system. From the instructor’s perspective, he or she should not be distractedfrom the real classroom and should not have to make any clumsy effort. In addition, theinstructor should have ultimate control over the virtual classroom session. From the remote


participating client’s point of view, he or she should get an experience close to or even betterthan that in a live classroom.

17.5 Summary and Conclusion

In this chapter we discussed two forms of distance learning systems:

• Live, interactive

• On demand.

The design of the interactive virtual classroom is aimed at giving the instructor total control ofthe entire session. We also proposed useful multimedia features aimed at enriching the userexperience. A majority of the research topics related to media compression and multimedianetworking are directly related to the multimedia distance learning system. Human factors alsoplay a significant role in the widespread and successful use of multimedia distance learning.

References

[1] ISO/IEC 11172-2: Information technology — Coding of moving pictures and associatedaudio for digital storage media at up to about 1.5 Mbit/s — Part 2: Video, 1993.

[2] ISO/IEC 13818-2: Information technology — Generic coding of moving pictures andassociated audio information: Video, 1996.

[3] ITU-T Video codec for audiovisual services at p x 64 kbit/s, Recommendation H.261,March 1993.

[4] ITU-T Video coding for low bit rate communication, Draft H.263, January 1998.

[5] ISO/IEC 14496-2: Information technology — Coding of audio visual objects: Visual,Committee Draft, November 1997.

[6] S.M. Redl, M.K. Weber, and M.W. Oliphant, An Introduction to GSM, Artech House,Boston, 1995.

[7] ITU-T Recommendation G.723.1, Speech coders: Dual rate speech coder for multimediacommunications transmitting at 5.3 and 6.3 kbit/s, 1996.

[8] Stanford-online Web site, http://stanford-online.stanford.edu.

[9] C.R. Lewart, The Ultimate Modem Handbook: Your Guide to Selection, Installation,Troubleshooting, and Optimization, Prentice-Hall, Englewood Cliffs, NJ, 1997.

[10] W.J.Goralski, ADSL (Computer Communications), McGraw-Hill, New York, 1998.

[11] D. Harris and A. DiPaolo, “Advancing Asynchronous Distance Education Using High-Speed Networks,” IEEE Trans. on Education, vol. 39, no. 3, pp. 444–449, August 1996.

[12] Real Networks Web site, http://www.real.com.

[13] Microsoft’s Vxtreme Web site,http://www.microsoft.com/netshow/vxtreme.


[14] Microsoft’s NetShow Web site, http://www.microsoft.com/netshow.

[15] Intel Video Phone Web site,http://www.intel.com/proshare/videophone/.

[16] White Pine’s CU-SeeMe Web site, http://www.cuseeme.com.

[17] Microsoft’s NetMeeting Web site, http://www.microsoft.com/netmeeting.

[18] 3com and US Robotics x2 technology Web site, http://x2.usr.com.

[19] Sun Microsystem’s Java Media Framework Web site,http://java.sun.com/products/java-media/jmf/.

[20] Real Media Architecture Web site, http://www.real.com/realmedia.

[21] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A Transport Protocolfor Real-Time Applications, Internet Draft, Internet Engineering Task Force (IETF),August 1998.

[22] H. Schulzrinne, A. Rao, and R. Lanphier, Real Time Streaming Protocol (RTSP), InternetDraft, Internet Engineering Task Force (IETF), January 1998.

[23] ITU-T Recommendation H.323, Packet based multimedia communications systems,1998.

[24] J.-N. Hwang, S.G. Deshpande, and M.-T. Sun, “A Virtual Classroom for Real-TimeInteractive Distance Learning,” ISCAS, vol. 3, pp. 611–614, June 1998.

[25] J.-N. Hwang, S.G. Deshpande, and M.-T. Sun, “Multimedia Features for Course-on-Demand in Distance Learning,” IEEE Signal Processing Society, 1st Workshop on Mul-timedia Signal Processing, pp. 513–518, Princeton, NJ, June 1997.

[26] J.-N. Hwang, J. Youn, S. Deshpande, and M.-T. Sun, “Video Browsing for Course-on-Demand in Distance Learning,” International Conference on Image Processing, vol. II,pp. 530–533, Santa Barbara, CA, October 1997.

[27] S.G. Deshpande and J.-N. Hwang, “A Real-Time Interactive Multimedia Distance Learn-ing System,” ISMIP 98, (to appear).

[28] Contigo’s Itinerary Web Presenter 2.1, http://www.contigo.com.

[29] ITU-T T.82, Information technology — Coded representation of picture and audio in-formation — Progressive bi-level image compression, 1993.

[30] ISO/IEC JTC1 SC29 Working Group 1, WD14492, JBIG-2, Working Draft, Au-gust 1998, Johns Hopkins University Press, Baltimore, 1989.

[31] Y. Wang and Q.-F. Zhu, “Error Control and Concealment for Video Communication: AReview,” Proc. of IEEE, vol. 86, no. 5, pp. 974–997, May 1998.

[32] J. Rosenberg and H. Schulzrinne, An RTP Payload Format for Generic Forward ErrorCorrection, Internet Engineering Task Force, Internet Draft, 30 July 1998.

[33] C. Perkins, Options for Repair of Streaming Media, Internet Engineering Task Force,Internet Draft, 13 March 1998, (expired).

[34] F. Dufaux and F. Moscheni, “Motion Estimation Techniques for Digital TV: A Reviewand a New Contribution,” Proc. IEEE, vol. 83, no. 6, pp. 858–876, June 1995.

[35] V. Kumar, MBone: Interactive Multimedia on the Internet, Macmillan, New York, 1995.

Documents

Chapter 17 Multimedia Distance Learningread.pudn.com/downloads97/ebook/395992/Multimedia Image and … · Deshpande, Sachin G. et al. “Multimedia Distance Learning” Multimedia