In fall 1999 KTH/IT was going to have a few courses over the SSVLNet which later would be assessed by the Stanford Learninglab (SLL). We had done these sorts of things before, internally within the project, by recording incoming and outgoing video and audio, as well as a separate view of the old conference room using an old VHS recorder and a lot of swapping of tapes. This was a quite clumsy recording strategy and we didn't want to repeat it, so I was asked to investigate the possibility to record the sessions automatically. Since I didn't have enough time to dedicate for this at that moment, Iyad was commanded to do the work with some help from me. It turned out that he knew so little of these things that it meant more work to teach him the basics of Unix, IP multicast, RTP a.s.o. than to do it myself. We aggreed that I should do the practical work and try to teach him at the same time, and then he would do the documentation and take care of the administration.
The work I did included:
And, finally, I include some general experiences that I have got from this project.
From the
MultiMedia Server Survey work that I did for the MERCI project
I already had some knowledge of the issues involved, and the applications
already available for this purpose.
The applications that I have looked at so far are:
Preferably, the recording as well as the streaming should be possible to manage with the same application and the same user interface(UI). The UI should also be accessible from all of the nodes in SSVLNet. Maybe it's a good idea to use a resource booking interface for recording instead of relying on session participants to remember to start the recording manually. Preferably equipped with a "Record Now" (read "PANIC!!!") button for immediate recording, since experience has shown that planning ahead more than 12 hours are an extreme exception in this business. Remote recording also raises a lot of security issues that is hard to solve in a comfortable and usable way. The worst case imaginable would be to demand from the participants to start the recording remotely via a kerberised telnet connection.
I was quite familiar with the rtptools from the implementation of a minimal streaming server based on Henning Schulzrinnes rtptools for the Internet Multicast module of the Specialization Course (finger course) in Telesystems. For this evaluation I wrote two small shell scripts that took care of all the messy details and Iyad recorded a session (called GLC1). At playback, the audio experienced a strange unexplained packet loss making the recording almost inaudible. It might be because the machine we used for recording wasn't patched and not reliably networked at the time, although I doubt that this would affect the loopback interface. I also tested different versions of rat but got the same loss.
The mMOD system was written by Peter Parnes in 1997. It is written completely in Java 1.1. Recording and streaming is handled by an application called mVCR. There is a webbased UI for playback taken care of by a minimal WWW-server, an applet called VCRApplet and some config-files describing the recorded sessions. There's also a possibility to use mVCR directly via a command-line interface to play back material as well as recording new sessions. Unfortunately it's only possible to record material via the command-line interface, and we don't have the source code to VCRApplet to correct it.
For this evaluation I, again, wrote two small shell scripts that took care of all the messy details and Iyad recorded a few sessions (called GLC2, GLC3 and GLC4). The quality at playback was very good, although we discovered the problem with different audio levels.
The MVoD Project at Universität Mannheim has continued development of the old MBone VCR tool and produced an impressive set of Java applications based on Java IDL and CORBA. The part that does the real performance critical job - streaming - is implemented in C++ ofcourse. A nice thing about MVoD is that it includes a rudimentary password-based authentication mechanism to prevent anyone from starting recording or playback.
According to the MVoD project page, the client application could be run as
an applet as well, but I haven't tride that yet.
When trying this tool, I found out that it couldn't record sessions that
were not announced using SAP, which we are not currently doing.
The IMJ, written by Kevin C. Almeroth, is based on Henning Schulzrinnes rtptools (see above) and works as an ordinary jukebox. The number of sessions that can be streamed at a given moment is limited and additional requests are queued for later playback. There is no way to control the streamed session or record other sessions. It has a simple FORM-based WWW UI.
The IMJ shows just how simple it is to implement a limited streaming server with a nice WWW interface using no unnecessarily complicated technologies and it was an inspiration for me when I implemented the minimal streaming server for the Specialization Course (finger course) in Telesystems mentioned above.
The Real Networks has a family of products, called G2, using RTSP and thus is able to stream RTP/UDP/IP content to multicast addresses. I browsed through the manuals found at the RealNetworks Documentation Library as well as the SDKs at the DevZone, but couldn't find any way to record MBone content using their products. Since all the other Media servers presented in this report records in their own formats, it is not possible to convert material recorded with those into G2 content. Unless we use the SDKs and the descriptions of the file formats used to develop a converter ourselves.
The MMCR system consists of two parts; the server was written by Stuart Clayman in 1995 during the MICE project, and the development was continued by Lambros Lambrinos during the MERCI project where a Java-based client was implemented. I tried this solution during the MultiMedia Server Survey work and found it quite buggy at the time. Therefore I decided to wait with the evaluation of this candidate until the other ones were tested.
Starting from scratch I saw the opportunity to do things right from the beginng (for a change), although the time frame and competitive work load was high at the moment. The first thing to consider was where to put the server in the network to minimize the impact on the rest of the system. The video generates a lot of traffic and you don't want to route it to parts of the network intended for other activities. I decided to put the server on the same physical and logical network as the receiving SGI in the Videoconferencing Room at the KTH/IT Node since that's where most of the audio-video traffic ends up usually.
The second phase was to find a suitable machine. It needed to be reasonably fast, equipped with a Fast Ethernet NIC, and have a huge disk with reasonable spin. I had a such machine, although it needed a disk upgrade, OS upgrade and patching. Which I did. I moved it to the intended network, only to find out that the SSVLNet usually goes up and down like a Yo-yo. In combination with a tight time-schedule that's not good working conditions so I installed another network card and hooked it up to the department's network and got everything working at a good pace.
The third phase was to do a storage strategy. I measured the duration
of a recording using the UNIX time command (see manual section 1),
and the size of the recorded material using ls -l. This way I
found out that the recorded traffic was on average a little more than
1.3 Mbit/seconds and site, i.e. about 162.5 Kbytes/second and site, so
for a one hour session with only one sender we need about 585 Mbytes.
The T1 link to U.S. limits the amount of traffic to 1.544 Mbits/sec full
duplex, and usually the sessions include overseas sites, so I decided
to dimension the storage accordingly. About 1.4 Gbyte per hour and an
average session duration between 1.5 and 3 hours gives a need for a
maximum 4.2 Gbytes per session. Since I think that overdimensioning is
the only working resource allocation mechanism I decided to use a
18 Gbyte hard disk.
Even 18 Gbyte won't last forever, so we planned to use a CD recorder
and tape backup for final storage.
Recording a MBone session including two senders means that you also record the sending sites absolute audio settings. At the receiving sites the absolute audio settings can be adjusted by altering the playout settings locally. When playing back a recorded session you don't have this flexibility, which means that the contributions from the different will be played back with the sending site's original audio settings, possibly resulting in a very unbalanced audio level. The same phenomenon appears when introducing a third participating site, but at least they have the privilege to be able to ask the other sites to adjust their audio levels to a more balanced level (according to their own settings ofcourse). Therefore it is advisable to run an audio check including the recording machine as a third party before starting the session to be recorded.
Maintained by Tobias Öbrink