Moodle 1.9 Multimedia – Book Review

I've used Moodle for about four years, and in that time I've found it to be an exceptionally useful, high-functioning and user-friendly learning management system (LMS). In my view, the one deficiency in its suite of resources is that it is less than intuitive in the way it enables administrators, teachers, and learners to create, integrate, manage, and deliver images, audio, video, animations and other media types.

Enter Packt Publishing's Moodle 1.9 Multimedia by João Pedro Soares Fernandes.

I opened my copy of the text with a high expectation that it would be an informative and practical reference text. Why? Packt Publishing have been providing Moodle reference books for some time now, and their texts are usually either very good or excellent.

Now read on...

Using open source software can be a daunting experience, regardless of your technical or business experience, and this text's purpose is to shorten Moodle users' path to competency in designing, developing and delivering multimedia on the platform. Broadly speaking, the text covers seven Moodle-related media-based activities:

1. Evolution of Multimedia
2. Using Images
3. Sound and Music
4. Video
5. Web 2.0 and other multimedia forms
6. Multimedia and Assessments
7. Synchronous Communication and Interaction

The author assumes previous knowledge of Moodle, but not prior experience of multimedia development. Appropriately for a book about Moodle, Fernandes uses a Constructivist approach to instruction, and the content is structured so that the reader learns experientially – you learn by doing. This is a very good idea indeed: for newcomers this goes some way to providing an understanding of why multimedia in Moodle 1.9 looks and works the way it does, it acts as a pertinent reminder for experienced Moodlers, and sets the context for the content creation chapters in the book.

The book is designed in a logical and linear fashion: the author aims to guide you through the basics of content creation in each featured media type. For example, in Chapter 2: Picture This you find out about using the open source image editing called GIMP to capture and enhance images, integrate images into Moodle, create comic strips using the free-to-use Strip Generator, export PowerPoint create slideshows, and use online resources like SlideShare.

Given the assumption of little or no technical background in multimedia development, the author spends a goodly proportion of his time - in detail and very effectively - spelling out the advantages, and disadvantages of various media types, as well a processes, "how-to's" and "gotchas" of using digital media in Moodle. With nearly 12 years experience as an learning professional specializing in e-learning, I would consider that I have a pretty comprehensive knowledge of digital media tools, technologies, and services. I'm delighted to say that Moodle 1.9 Multimedia introduced me to a range of resources that I had not encountered before. This is great: any resource that enables me to deliver content to learners in a more engaging and immersive fashion is a winner with me, and this book fits comfortably into that category.

As I mentioned at the beginning of this review, I think that Moodle 1.9 Multimedia would be an invaluable companion for those new to using media on the Moodle platform. As an experienced Moodle user (and media expert), I will use the book very much as a "just enough, just in time" resource rather than as an end-to-end guide through image, sound, and video development, though I would suggest that the text would work very well if used in this fashion.

Some other positive aspects of my "user experience" of the text included the author's accessible and direct writing style, and the availability of a sample Moodle course for learners to access and "have a play with." In my view this text is a straightforward and reliable companion for those who seek to find out more about - and use - multimedia in Moodle 1.9.

Click here to navigate to Packt Publishing’s Moodle 1.9 Multimedia web page.

Click here to download a sample chapter of the text (2MB PDF).
--

Without Les Paul I wouldn’t be an E-Learning Professional

Les Paul, inventor, guitar legend and sound engineering genius died yesterday.

While most of the tributes to this most rounded of individuals rightly focus on his contribution to music, both through his virtuosity on the guitar and his invention of his eponymous Gibson instrument. I'd like you to consider this: if you work in e-learning or digital media content development you probably wouldn't have a job without Les Paul’s influence and inventions.

Why?

He invented multitrack sound recording.

Multitrack recording (also known as multitracking for short) is a method of sound recording that allows for separate recording of multiple sound sources to create a cohesive whole. Today, this is the most common method of recording popular music, radio documentaries, and podcasts. Back in the day, I learned to record sound to magnetic tape (including the black art of editing sound by physically splicing bits of tape together), before moving to DAT, mini-disc, and finally recording and editing audio in a purely digital environment about 10 years ago.

Today, I use multitracked audio to create podcasts for distribution on the web and via iTunes, demos, simulations, training videos, and a host of other learning applications.

All of these developments occurred because of Les Paul's innovations in multitracking 60 years ago. He was so influential that modern digital audio editors (and digital media editing tools like Adobe Premiere and Techsmith Camtasia) still use the multi-channel / multi-track timeline user interface paradigm, and still sport controls for cutting, splicing, and cross-fading the content stream, same as in the physical magnetic tape editing I used to do many years ago.

Source audio for a podcast in a digital multitrack editor

"Big deal" I hear you say, "if he hadn't done it, someone else would have."

Maybe, but he did it. And it was his musical artistry and fame as a recording artist (with his then-wife Mary Ford) that popularized the technology in a way no 'man in a white coat' could ever have.

So thanks for the music, Les, and the guitar.

And the career. Requiescat in pace.

Les Paul (1915-2009)

--

Streaming Digital Media for E-Learning 4: Delivering Content via HTTP Tunneling

The topic of today's post was preempted in a comment I received on Friday 10th July. In it, Digital Chalk's Tony McCune wrote:

...I think that the technology decision has to include consideration of the client capabilities of the audience you are serving as well as the network you will ultimately be streaming into and their openness to the ports and protocols. Most enterprise networks close the streaming ports.

Communications and collaboration using streaming media platforms only work if the client side has the facility to access the content. If you or your organization has a requirement to deliver content (on-demand courseware or a pre-sales demo, for example ) to a customer, you are probably familiar with the refrain " I can't see the content" from the prospective attendee or viewer. There are many reasons why this may occur, but all other things being equal, the probability is that the client cannot access the content because their firewall is blocking the data delivery.

According to Wikipedia, a firewall is

a part of a computer system or network that is designed to block unauthorized access while permitting authorized communications. It is a device or set of devices configured to permit, deny, encrypt, decrypt, or proxy all (in and out) computer traffic between different security domains based upon a set of rules and other criteria.

To control the flow of data, numbered ports in the firewall are either opened or closed to specific types of packets. The firewall reviews two pieces of information in each arriving or departing packet: the protocol through which the packet is being delivered and the port number to which it is being sent. If the firewall is configured to accept the specified protocol through the targeted port, the packet is allowed through. The most commonly-known example of this process is probably Port 80, the access point for TCP, UDP, and the Hypertext Transfer Protocol (HTTP).

Firewall policy management is beyond the remit of this blog, but suffice it to say that most organizations are understandably cautious about providing 'open house' access to their networks. The downside of this caution is that when a legitimate need arises to provide access via a rarely-used port, most organizations' IT departments have reservations (to say the least) about granting access.

Table 1 describes all of the ports needed to facilitate the delivery of unicast streaming via Microsoft Media Server 9.

Table 1 Delivering a Unicast Stream via MS Media Serve 9

Application Protocol	Protocol	Port	Description
RTSP	TCP	554 (In/Out)	Used for accepting incoming RTSP client connections and for delivering data packets to clients that are streaming by using RTSPT.
RTSP	UDP	5004 (Out)	Used for delivering data packets to clients that are streaming by using RTSPU.
RTSP	UDP	5005 (In/Out)	Used for receiving packet loss information from clients and providing synchronization information to clients that are streaming by using RTSPU.
MMS	TCP	1755 (In/Out)	Used for accepting incoming MMS client connections and for delivering data packets to clients that are streaming by using MMST.
MMS	UDP	1755 (In/Out)	Used for receiving packet loss information from clients and providing synchronization information to clients that are streaming by using MMSU.
MMS	UDP	1024-5000 (Out)	Used for delivering data packets to clients that are streaming by using MMSU. Open only the necessary number of ports.
HTTP	TCP	80 (In/Out)	Used for accepting incoming HTTP client connections and for delivering data packets to clients that are streaming by using HTTP.

Table 1 only represents a small portion of Windows Media Server 9’s requirements, the platform has separate port access requirements for:

• Delivering a multicast stream
• Streaming from an encoder
• Distributing content
• Administering the server remotely

Apple, on the other hand, provides proxy server software to get around firewalls, by the IT department maintaining the firewall must install the proxy software.

The Flash Streaming Server platform uses what Michael Topic (2002) calls a "drastic solution" to negotiate this problem: HTTP tunneling

Where [Real Time Protocol] RTP packets are wrapped inside ordinary HTTP packets so that they can pass through the firewall.

(p.99)

"Unfortunately" he notes, this approach adds "significant overhead to the stream" taking up more bandwidth. Adobe Systems solution to this issue (and the one implemented by Digital Chalk, as well as a broad range of e-learning vendors and other enterprises and institutions) is to implement the proprietary Real-Time Messaging Protocol for streaming audio, video and data over the Internet, between a Flash player and a server..

According to Adobe

The Real-Time Messaging Protocol (RTMP) was designed for high-performance transmission of audio, video, and data between Adobe Flash Platform technologies, including Adobe Flash Player and Adobe AIR. RTMP is now available as an open specification to create products and technology that enable delivery of video, audio, and data in the open AMF, SWF, FLV, and F4V formats compatible with Adobe Flash Player.

The protocol works by a client (such as the Flash Player) communicating with a Flash Communication Server (for example via a corporate Adobe Connect solution) using RTMP protocol over port 1935. If that fails, it will try again over ports 443 and 80 in an attempt to get around firewall policies within an organization, which prevent TCP/IP connections over non-standard ports.

According to Adobe this approach allows "approximately 96% of all users to access publicly accessible Flash Communication servers."

More…
___________

References:

Adobe DevNet (2009). Real-Time Messaging Protocol (RTMP) specification. [Internet] Available from: http://www.adobe.com/devnet/rtmp/ Accessed 11th July 2009

Adobe TechNote (2009). HTTP Tunneling protocols [Internet] Available from: http://kb2.adobe.com/cps/166/tn_16631.html Accessed 11th July 2009

Nelson, D. (2007) Firewall Information for Windows Media Services 9 Series. [Internet] Available from: http://www.microsoft.com/windows/windowsmedia/forpros/serve/firewall.aspx Accessed 11th July 2009

Topic, M. (2002) Streaming Media Demystified. McGraw-Hill Professional. eBook, United States.

Wikipedia (2009) Firewall. [Internet] Available from: http://en.wikipedia.org/wiki/Firewall Accessed 11th July 2009

--

Streaming Digital Media for E-Learning 3: Using a Dedicated Media Server

According to Adobe, organizations use streaming media for corporate communications, electronic learning, and sales & marketing.

In a learning context, streaming media technology is a central component of

• Delivering remote presentations to employees, customers, and partners
• Delivering asynchronous (on-demand) just-in-time training
  Providing delta training to upskill workers
• Enhancing professional development via VLEs/PLEs and mentoring programs
• Capturing tacit knowledge from experts for distribution to their colleagues
• Conducting pre-sales demos
• Providing customer service

According to the eLearning Guild (Marks, 2002) e-learning using streaming media can save you money, increase learner participation, and improve motivation and focus (p.2).

So let's take a closer look at content delivery via a streaming media server. When using a streaming media server approach, the initial production, post-production, and content encoding steps are undertaken in the same manner as for progressive downloading and HTTP streaming. However, at the distribution stage, the compressed media file is placed on a specialized streaming media server. A Web page with a reference to the media file is placed on a regular HTTP server 'front end' web page .

The rest of the streaming media server delivery process differs significantly from the web server approach. In contrast to the HTTP/TCP methodology used in web server streaming, the digital media file data is actively and intelligently sent to the client. This means that the media server delivers the content at the data rate associated with the compressed audio and video streams. The server and the client communicated during the content delivery process, and the streaming media server can respond to any feedback from the client (see Figure 1).

Figure 1 UDP and RTP/RTSP protocols

While streaming media servers can use the HTTP/TCP protocols used by Web servers, they can also use specialized protocols such as the User Datagram Protocol (UDP) and Real Time Streaming Protocol (RTSP) to greatly enhance the quality of the streamed content and ultimately the users' media access experience.

UDP is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages called datagrams to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths.

Unlike TCP, UDP is a fast, lightweight protocol. This makes UDP an ideal protocol for transmitting real-time digital media data, which can tolerate some lost packets. Instead of the blind retransmission scheme employed by TCP, streaming media servers' resend feature ensures that the server only retransmits lost packets that can be sent to the client in time to get played.

Like UDP, the Real Time Streaming Protocol (RTSP) takes advantage of streaming by breaking data into many packets, sized according to the bandwidth available between client and server. When enough packets have been received by the client, the user's software can begin viewing the content: typically one packet is played, while subsequent packets are decompressed and downloaded. The advantage of RTSP is that it enables the user to start viewing multimedia content almost immediately. Both live data feeds and stored clips can be used as the sources of the content. The transmission of streaming data itself is not a task of the RTSP protocol; most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, though some vendors implement proprietary transport protocols. The RTSP server from adobe Systems, for example, also features their proprietary RTMP stream transport protocol.

RTSP has been called a "network remote control" for multimedia servers, in that the user can typically play, pause, rewind, scrub through (rewind and fast-forward), record, and stop playback via client interactions with the streaming server. Examples of media server products using this approach include:

• Flash Media Server family
• Microsoft Windows Media Services
• Apple Darwin Streaming Server
• RealMedia Helix Server

In a sense, RTSP is more of a framework than a protocol. It's meant to control multiple delivery sessions, provide a way to choose delivery channels such as UDP, TCP and IP-multicast. The delivery mechanisms are based solely on RTP. RTSP has been designed sit on top of RTP to facilitate both control and synchronous delivery of content.
___________

References:

Adobe Dynamics Group (2001). A Streaming Media Primer. [Internet] Available from: http://www.adobe.com/products/aftereffects/pdfs/AdobeStr.pdf Accessed 4 July 2009

Marks, R.B. (2002). Learning Styles and Streaming Media. The eLearning Developers Journal, October. [Internet] Available from: http://www.elearningguild.com/articles/abstracts/index.cfm?id=43&action=viewonly [Subscription Required). Accessed 3 July 2009.

--

Streaming Digital Media for E-Learning 2: Delivering Content via a Web Server

Deploying streaming media content with the web server approach is very similar to the download-and-play model I described in yesterday's post: it's a pull technology.

Using this paradigm, the initial request for data originates from the client, and then is responded to by the server. When using digital media, uncompressed audio and video is first compressed into a single, muxed (multiplexed) media file for delivery over the Internet or a network at a specific bit rate. The media file is then placed on a regular web server. A web page containing the media file's URL is also created and placed on the same web server. When the link on the web page is clicked on, a client-side player (such a Windows Media Player or QuickTime Player) downloads and plays the requested media file.

In the context of e-learning, it's pretty standard for a video demo (for example) to be stored and progressively streamed from a Moodle LMS running on an Apache such as Apache server (see Figure 1)

Figure 1. Demonstration: Uploading a WMV file to Moodle, and playback via HTTP streaming in Windows Media Player
[Click to play the demo]

From a user's perspective, this process looks and feels identical a download-and-play case use case. From a technical point of view, the difference lies in how the client functions.

Unlike the download-and-play model, the client player starts actually starts playing the streamed digital media file while it's being downloaded. This is possible because the content is cached: a process of collecting the first part of a media file before playing. This small 'buffer' of information allows the content to continue playing even during periods of high network congestion. With this delivery method, the client retrieves data as fast as the Web server, network and client will allow, regardless of the quality of the compressed stream. Only certain media file formats support this type of progressive playback including Microsoft's Windows Media format (WMV) and Apple's QuickTime (MOV).

Web server streaming uses the Hyper Text Transport Protocol (HTTP), the standard Web protocol used by all Web servers and Web browsers for communication between the server and the client. HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers.

It's useful to remember that HTTP/TCP is optimized for asynchronous, static applications, such as displaying static Web pages, and file transfer; this can affect the distribution and delivery of motion-based, asynchronous ('on-demand') content. Users may experience interruptions, 'glitches,' and temporary loss of playback because to the limitations of the HTTP and TCP protocols when handling multimedia content.

More...

--

Streaming Media for E-Learning: A Primer

I'm preparing a series of blog articles on the topic E-Learning Using Collaboration Platforms. In the series I will discuss:

• Collaboration Platform Technology
• Synchronous Delivery
• Asynchronous Delivery
  
• Overview of Products on the Market
  
• Production Considerations
  
• What works (and what doesn't work)
  
• The Online Instructor
  
• Mentoring
• Integrating Collaboration Solutions and Other E-Learning Channels

This is an area of technology in education that I'm especially interested in, so I'm really looking forward to bringing this set of blog posts to you here on the E-Learning Curve Blog. As the series is still under development, there's an opportunity to request an article on an aspect of this topic that you might like to see covered: let me know and I'll see what I can do.

In the meantime, I thought I'd give you a 'heads up' by discussing some of the fundamentals surrounding using collaboration solutions: streaming media.

Until about five years ago, Web-based audio and video - or digital - media was primarily a download-and-play technology. Users had to download an entire media file before it could be played back. If you're over 30, you'll remember those postage stamp-sized video clips (usually in ASF or MOV format) that took forever to load over your dial-up connection (and were hardly worth the wait). Because digital media files are usually very large and take a long time to download, the only content found on the Web was short, low motion clips. Even these files could take 20 minutes or longer to download.

How video used to look and sound – Marc J. Rosenberg discusses personalized learning
[Click to play video]

With the increasing availability of high-speed internet access, streaming digital media has become more prevalent. In the consumer market, this has led to the rise in popularity of services like YouTube, and the current emergence of video-on-demand (VOD) solutions like Hulu, as well as ustream and for lifecasting and live video streaming of events online.

Streaming media works almost instantaneously: other than a short delay before the requested file starts to play, you don't have to wait to start watching, no matter if the file lasts thirty seconds or thirty minutes in duration.

Broadly speaking, there are two way of delivering streaming digital media content over the Web. The first method uses a standard HTTP Web server to deliver the audio and video data to a media player. The second approach uses a separate streaming media server designed specifically to stream digital media. Using a streaming server is more efficient and flexible, provides a better user experience, and is more secure than HTTP streaming.

Both approaches have their advantages and disadvantages, and I will begin to look at these tomorrow.

--