The work that resulted in the AutoAuditorium System started in the mid-1980s and was based on exactly that observation, namely it was very difficult to which talks or presentations would be seen as the most improtant ones. Moreover their importance sometimes took time to become apparent.

The AutoAuditorium System was designed to reduce the marginal overhead of making the next telecast and recording just the cost of the medium. Capturing the event was often putting a tape or DVD in a recorder and pressing the AutoAuditorium System START button.

For example, IBM Watson Research in downstate New York has had 3 AutoAud Systems for more than 5 years now, and in each of the past several years they have made AutoAud programs more that 230 times. That is just shy of one program every business day. Clearly lmost of those programs are not “hits”. But they do have recordings of the ones that are.

Congratulations for the new site!

“Simplicity is beauty”.

Bill

Regarding capturing and webcasting lectures, my guess is that eventually people will settle for (1) usual DV capture with a webcam (iSight) or camcorder; (2) H.264 encoding with Quicktime; (3) upload to a service provider such as the iTunes podcast repository or youtube-like services. They will not bother with the actual problems in backward compatibility until they break, at which time they will be recoded from DV sources (hopefully still on miniDV tapes). This is certainly an amateur way of doing this, but given a lot of storage (I now have 1.5TB in my desktop), multi-core CPUs (I have 4 CPUs), and the Moore’s law, it may work quite well.

I think you are right about some things in this comment, but you will quickly find out that operational issues and costs are important and that users demand better quality. Setting up a camera with a wireless mic for a speaker is not too complicated, but you will run into a couple of problems:

You will need someone to operate the camera or you will have limited quality images

Whiteboard and computer projected material may be unreadable

Audience questions will not be heard unless the speaker repeats them which they frequently do not

Set-up time is limited which makes fixing problems difficult

Your comment about recording to tape is right on. The Berkeley system records all webcasts to video tape while producing a live webcast at the same time. Originally, it was to guarantee that we captured a lecture even if the webcasting system crashed. Folks at UMinn even used two capture machines (i.e., one for the live webcast and one to record to disk) because they figured out that the live webcast link was what failed.

Two problems with tapes: cost of the media (e.g., $100-$200 per 15 week class) and storage space (i.e., think about storing 35 tapes per day). Nevertheless, I have several boxes of VHS tapes in my garage that contain material from lectures and projects.

My view is that permanently installed equipment operated remotely by intelligent software offers the best solution for reliable, low cost production. Permanent installation means set-up/tear-down between classes is eliminated and operational reliability is much higher since changes are avoided.

As for production, I thought we needed four video feeds from a lecture hall (e.g., wide-angle stage view, speaker close-up view, audience view, and presentation material view). Most webcasts at Berkeley only have 2-3 feeds (e.g., wide-angle, speaker, and presentation) that a director uses to produce a single video stream (e.g., using a production switcher with PiP and transitions). Some departments pay for extra cameras and operators to provide close-ups of experiments and audience views.

Several research and commercial groups have done work on automated production where software makes shot selection decisions either on-line or off-line (e.g., see auto auditorium, MS iCam system, Berkeley director’s console, and UWisc virtual videography). But, equipment and people/software costs money. Depending on what you do, it costs $5K-$20K to outfit a classroom for webcasting. Someone has to run the server and webpages that provide access to the material. And, you have to pay for on-going operations. Berkeley educational technology service charges $3,000 to webcast a class assuming it is being offered in a video enabled classroom. Podcasts are free because they are fully automated, and the room only needs an audio system (required by hearing impaired legislation) and a $500 network capture/streaming device. So, you can see that it takes vision and investment to make this stuff work.

Returning to Baochun’s comment, I completely agree that capture on a local disk for downloading works well — particularly when you learn that 99% of the accesses to the lecture material by students is on-demand when studying for exams. A few students watch the material rather than attend the class, but the vast majority who watch the material do it before midterms or finals. And, they often only look at a small fraction of the material. For example, I did an analysis of an introductory chemistry class and learned that only 10% of the plays watched the entire tape and roughly 50% of the plays watched less that 10 minutes of a 50 minute lecture. Further investigation shows that students are using the material in place of taking notes — they remember something they want to review and go find it and watch it. That’s why work on search and indexing is so important. But, that’s another subject.

The bottom line is that I too want all conference presentations captured even though I suspect few will be watched, just like most conference/journal papers are probably read less than 10 times. The reason is clear — some papers and presentations are very important!

First, I completely agree with his comment about Henning’s work on RTP, RTSP, and SIP. While Henning richly deserves credit, several other people were instrumental in the adoption of RTP and RTSP by the IETF community. Steve Casner was chair of the avt and mmusic committees that oversaw the development of the standards. Steve’s role was very important. Van Jacobson and Steve McCanne were instrumental in implementing the first RTP compliant tool, which was the Mbone audio tool vat. And, several others in the community supported the development of the remaining IETF compliant Mbone webcasting tools (e.g., sdr, nv, vic, etc.). I am less familiar with RTSP, but I know that folks at Netscape, Precept Software, and Real Networks were strong supporters and advocates of establishing a standard for on-demand replay control. Apple deserves credit for adopting the IETF standards and using them in an open way.

Second, Baochun’s comment about my discussion of the problems with the image quality in the 1200Kbs NOSSDAV ‘05 lecture material need to be understood in context. The problem is not the bit rate - 1200Kbs is more than adequate to produce excellent images from a compressed stream. The issue is the quality of the source images. We captured the original material at 1500Kbs in either SVGA or XGA size. I decided, after experimentation that 512×384 images at 1200Kbs would be best given the problems with the need for network bandwidth and CPU decoding resources with the orginal source material. Unfortunately, image scaling caused problems with the source images (e.g., chunky text ) and the capture encoder introduced some ringing around the text. Here’s my guess about what happened. Most presenters used SXGA (1280×1024) or XGA (1024×768). We captured these images as XGA - which does not preserve the aspect ratio (i.e., SXGA is 1.25 and XGA is 1.33). Then we scaled it to 512×384, which preserved the XGA aspect ratio. Scaling this image to the 600Kbs stream size was not aspect ratio preserving. All in all, scaling and compression caused the problems. I also have to investigate the scaling algorithm used in the capture device. I am not sure they are using the best algorithm, which I am told is bi-linear interpolation.

Third, widespread use of lecture webcasting is already a reality in both university and industry settings. U.C. Berkeley, among others, already webcasts lectures. The Berkeley system I developed is still in use on the campus (see http://webcast.berkeley.edu). They webcast roughly 35 hours of lectures (15 classes) a week, that are viewed by roughly 600K people per month. Last year they added a podcasting component that allows them to produce more classes - installing and operating audio capture devices in a classroom is much cheaper than audio and video. They deliver podcasts through Google and an RSS feed for both the webcast and podcast classes. Although the data is anecdotal, the podcasts are hugely popular. It appears that webcast viewing is declining as students shift to podcasts. Several companies have already instituted extensive webcasting services for internal communications and lectures (e.g., HP, IBM, Microsoft, and Sun). I am sure many more are doing it.

I have published some internal reports and given several talks that discuss the Berkeley webcasting system and the research we conducted in support of such activities - see

http://www.bmrc.berkeley.edu/pubs/bibs-report.html

The NOSSDAV ‘05 experiment was one in a series of experiments to capture conference presentations. Some conferences are captured, but most are not due to the cost. This experiment tried some technology that we hoped would work and be less expensive. I think it was successful, but as with all experiments, you learn what you will do better next time as well as what suceeded.

I gave a talk last spring at Portland State that discussed the lecture webcasting system and the NOSSDAV ‘05 experiment. Those slides are available at

http://bmrc.berkeley.edu/people/larry/talks/06ConfCaptureReport/

That talk covers much of the important facts we learned operating the Berkeley webcasting system.

Many researchers have worked on problems relating to webcast production. In fact, there are two papers that will appear in future issues of TOMCCAP that describe research on lecture capture systems. One is by Michael Gleicher and his students at UWisc discussing the use of virtual videography which uses image processing to create alternative views of a lecture from one camera at the back of the room. The other is by Cha Zhang and colleagues at MS Research that describes the system they have deployed and are using to capture research and training presentations.

Lastly, there are many issues that require further research - I’m trying to write a survey about past work and future research needs. More on that later. I agree completely with Baochun that often academic research on transport services and codecs is irrelevant to the problems faced by someone who wants to deploy and use this technology.