University Media Rich e-Learning Course Needs Gbytes

The question of how much bandwidth is needed for a media rich e-leaning course was raised in the EDUCAUSE Instructional Technologies Constituent Group (Bandwidth demands of media-rich online/hybrid courses, Jarret Cummings, 12 Oct 2011). My estimate for one semester course using video is between 5 and 20 Gbytes (a full time student, doing four courses would require four times this). This is about 100 times the data needed for an e-leanring course which does not use video.

My students do still experience problems with on-line access in some developing nations, even without video. The solution to this, I suggest, is to provide the non-interactive parts of the course as an eBook, which can be obtained at the beginning of the course (downloaded at a cyber cafe or sent on DVD) and the just do the interactive parts live. However, this requires courses to be carefully prepared. My "ICT Sustainability eBook" shows one way to do this (I estimate this courses requires 85 Mbytes of data over 12 weeks).

Apart from the amount of data, keep in mind the applications used may also cause problems. At the "Digital Culture Public Sphere" in Sydney recently, some of the delegates from government agencies pointed out that they are blocked from using certain applications by corporate policy (this also applies in some corporations). They have to go home and use their private Internet services to use these

Estimating Data Requirements for a Media Rich Unviersity Course

Low estimate:

1. Lectures: 3.5 Mbytes per minute for video x 20 minutes per "lecture" x 3 lectures per week x 12 weeks = 2520 Mbytes.
2. Tutorials: 28 Mbytes per hour x 14 hours = 392 Mbytes Total: 2812 Mbytes (then double it for contingencies and round to the nearest multiple of 5).

High estimate:

1. Lectures: 3.5 Mbytes per minute for video x 60 minutes per "lecture" x 3 lectures per week x 12 weeks = 7560 Mbytes.
2. Tutorials: 3.5 Mbytes per minute x 60 minutes x 14 hours = 2940 Mbytes Total: 10,500 Mbytes (then double it for contingencies and round to the nearest multiple of 5).

Where the figures come from:

The hours of lectures and tutorials are from ANU course COMP6341.

The Australian National Unviersity "Digital Lecture Delivery" System (DLD) produces podcasts in three formats for the student to choose from:

1. Audio: MP3 Mono 16,000Hz 0.2 Mbytes per minute
2. iPod: MP4 432 x 320 Pixel 5 Frames Per second Video 1 Mbytes per minute
   
3. Computer: MP4 1024 x 768 Pixels 2 Frames per second Video 3.5 Mbytes per minute

What is a media rich course?

I only use the live lecture recording as a supplement for face-to-face courses, not for blended or e-learning courses, which require materials which have been specially prepared for that more of delivery. You can't just record lectures and call it e-learning.

When prepared for e-learning, the equivalent of a one hour lecture reduces to about 20 minutes of audio/visual material. The student spends the rest of the hour doing interactive work without video. My colleagues in ANU Engineering have used this format successfully with their "Hubs and Spokes" project. They use what are effectively slides with audio.

For the purposes of estimation, I have assumed a course needs the 3.5 Mbytes per minute video and either 20 minutes for the low estimate or the full 60 minutes for the high estimate of a one hour lecture. But techniques such as audio and animation can be used, which use much less bandwidth and are much easier for the student to understand (especially where second languages and cross cultural matters are an issue)

On-line tutorials/Webinars

I avoid using real time video (or audio) for tutorials. This is because of the logistical problems in arranging a suitable time, with students in different time zones who have work and family commitments. But I have used the Elluminate Live!, web conferencing program successfully at 48 kbps. At this rate you get telephone quality audio and postage stamp size slow rate video of the participants, with documents and slides at full resolution: For the purposes of estimation, I have used 64 kbps (6 kbytes per second) for the low end and 3.5 Mbytes per second for the high end.