We recently attended a Moodle Moot conference in Kochi Prefecture on the island of Shikoku in Japan. There we presented PoodLL’s video displaying and recording functions.
This was followed by a discussion led by Don Hinkelman of Sapporo Gakuin University on how we can best bring video recording capabilities to Moodle, Moodle 2.0 to be specific. Unfortunately we could not bring this discussion to any sort of conclusion in the time that we had. So I am going to write up my thoughts on the topic.
There are four main directions to consider when thinking about a standard moodle approach to video recording.
Using Flash / Red5
The PoodLL system uses a Red5 server (a Java based open source equivalent of the Flash Media Server) to handle the recording the on the server and to store the resultant video files in a Moodle friendly way. On the client side, ie the student’s browser, a custom flash widget captures video/audio and streams them to the Red 5 Server. This means that in addition to Moodle, on the server, Java, Red 5 and our PoodLL Red5 application are required. The PoodLL Moodle plugins are also needed. On the client, Adobe Flash (version 9) is required as well as a web camera.
For those with the ability to set it up this is a good way for students to record video in the classroom. It integrates well with Moodle, and the creation / evaluation of recording activities is straighforward. Students enjoy it.
The chief problem with this approach is the complexity of setting the whole system up. It requires a powerful server and some technical ability.
In a paid service model, the need to set up a Java/Red5/Red5 application stack on the server could be eliminated if the video recording was offered as an ASP service. Similarly it might also be possible to provide standalone recording servers to schools that wish to use it.
Recording Offline.
Another way we might record video is to allow students to record the video offline, and then upload those videos to Moodle. Media focused Moodle modules could be used to “capture” the video from the file upload rather than a webcam. The actual module, be it video forums, or video assignment, would not need to be aware of how the video was captured. The method of capture could be using mobile phones, video cameras, or even web cameras with third party capture software.
A major benefit of this approach is that it also allows for greater flexibility in how and when the video is captured. For example, a moodle course teaching architecture could have students record videos of buildings and describe their features. Something all but impossible with a webcam focused solution.
There are downsides to this approach however. It requires that students have a phone/device capable of taking videos. In universities in first world countries, this may be conceivable. However in high schools and lower level educational institutions access to such devices may be restricted by internal rules. Or students simply may not have the devices at all. In developing nations, similarly, we may not be able to rely on the students to possess such devices.
A second downside is that the videos will arrive in Moodle in a hotchpotch of formats, sizes and qualities. This will cause problems when trying to playback the video in a unified way. An solution to mitigate this problem, and the problem of device access, might be for the school to provide sets of devices that are loaned to the students.
Using a Java Applet
A third way we might provide video recording in Moodle is using a java applet, to capture video from a webcam. The video would not be streamed to the server. It would be stored locally as a file and then uploaded in it’s entirety to the moodle server via special Moodle modules. The Java applet process would be very similar to that of audio recording modules that currently use the java applet , nanogong, to record audio for moodle. Example’s of these modules are Paul Daniel’s voiceboard and voiceshadow modules. These rely on Java being installed on the client computer.
This would be a pretty good solution, avoiding the complexity of the Flash/Red5 method, and the device access and format problems of offline recording. To date though there is only one video recording Java applet that I am aware of. It is available at vimas.com though it is not open source, and there is a charge to use it.
Harnessing Inbuilt Browser Functionality
The fourth way to capture video for use in Moodle, is not fully available yet. The HTML5 specification has already seen the audio and video playback tags implemented in modern mainstream browsers. There is also a specification for media capture. The details can be seen at http://www.w3.org/TR/html-media-capture
How long we have to wait for this to result in something usable is hard to gauge, and there are issues that need to be resolved. But Mozilla has already released a media recording plugin for its firefox browser that could fill the gap until html 5 can develop far enough. The plug in is still only in alpha stage and available only on mac. It is called Mozilla Rainbow.
Conclusion
And what do I think? Ironically, for me, it is hard to see the Flash/Red5 solution as the Moodle solution to video recording because of the need to put Java on the server and install a big fat Red 5 server. Though here at PoodLL it works well, we are moving beyond the PHP/MySQL skill set of most moodlers.
Though the other 3 methods all have their drawbacks they share one thing in common, which is the method of record first, upload second. I think the best way would be for moodle to provide video enabled modules, similar to the PoodLL Online Assignment (video/audio recording) and video forums. But Moodle would not get involved in the capture process at all. These video enabled modules would provide an upload API, that a new type of plugin, say a “Media Capture Plugin” would implement. A list of installed media capture plugins would be available in the video assignment editing area to be selected. Any of the 3 methods above that have an upload phase could have an associated media capture plugin. Perhaps Moodle could also provide a default plugin that provides a simple interface for a user to upload a file, but which would also serve as reference for media capture plugin developers.
Comments on all of this are welcome.