MPP- First version: how we did it
|Our goal||The testbed||Our solution||Why we use Real||The cost||The hardware used||The software used||The process phases and timing|
|Our goal||Our primary goal was to produce a digital video that can be watched by a
classroom (say 30 students) at the same time, on an Intranet network (10 Mbit), allowing
each student to keep his own pace. This would be impossible with only one TV and
videoplayer. Each student would need a TV monitor, the player and a copy of the cassette.
In a multimedia laboratory there are already the facilities required for our purpose: a
server, a network, a PC with a sound card for every student, Internet free software. We
wanted to convert existing educational videotapes.
Our secondary goal was to make these digital videos available over the Internet. While working, the idea of producing a CD with the same video files came over as a highly requested solution.
|The testbed||To test our procedure, we chose the Nettuno courses for University diploma, broadcast by the RAI (Italian TV). The typical lesson is a talking head often showing drawings, pictures and writings. In the original videotape the teacher or the drawing are showed alternately. The voice is always present. The straightforward conversion to MPEG-1 (352*288) would have provided a good video quality but the small drawings would not have been readable. Moreover it would have been impossible to deliver it on a "normal" Internet modem connection (28.8 k).|
|Our solution||After trying different systems we produced a RealVideo file (192x128)1 with embedded hyperlinks (also called "URL flipping"). The video is placed in the left frame. At fixed timemarks the browser opens in the right frame a JPEG image with big still screen shot (560x420)2 of the drawing that the teacher is showing in the video. So the student can easily read the content while listening to the professor. The movement of the teacher's hand or the pointer over the drawing can be roughly followed on the video, comparing it to the big still picture. This process is quite easy to accomplish. We show below all the phases with the time spent in each one.|
|Why we use Real||We decided to use RealVideo because it was the cheapest solution, while having a very good quality. We have tried many other encoders, as you can see in the streaming video comparison chart. In the meanwhile Microsoft Netshow has advanced a lot and has some interesting features, such as bookmarks (called "markers") in the video stream. We are working with NetShow to improve our system.|
|The cost||The total cost for the Real solution (limiting to the software part) is
ZERO. In fact, the server is free for 60 streams (enough for a classroom), the encoder is
free, the other DOS-based tools are free. The player is free.
Therefore, to calculate the global cost of converting a video to this format you have to count the hardware and the man effort.
|The hardware used|
|The software used||
|The process phases and timing for a 45' video||
As the encoding is unattended, we encode the next videotape while working in phase 2 and 3 for the previous one. That leads to a minimum man effort of 50' per 45' of videotape when working on many tapes. To this amount we add the set up of the final web pages for the whole lot of lessons, which takes only a few minutes.
1. The encoding with the Osprey 100 capture card is in real time. If the input is a PAL source, the only sizes allowed are 768x568, 384x284, 192x142. The size of RealVideo files must always be a multiple of 16 with the exception of the allowed 160x120. Therefore the 192x142 can produce only a 192x128. We loose 142-128=14 pixels, at the top and the bottom of the frame. In our videos we never missed anything relevant, with this limitation.
2. We found that the 560x420 size is the optimum, among those supported by the Matrox Rainbow Runner capture board, for filling the 800x600 monitor size, aside of the 192x128 video. The use of this second capture board is for speeding up the procedure: while the Osprey is capturing on one Pentium, the Rainbow can work on another. Moreover, the limitation of the Osprey frame size would have compelled us to resize all the captured frames.
3. Any Pentium II or Pentium MMX 200 would do the job. For wider images or for higher transmission speeds, the more powerful the PC, the highest frame rate you achieve.
4. Any other Pentium would be sufficient.
5. This time depends on the number of still images to be captured. In our video courses it ranges from 10 to 60, which changes the total time. The 45' is an average.
6. This is the moment when we choose how much time before the real showing of the slide in the video we have to start loading the JPEG image. The image size are from 10 to 30 Kb. On a 28.8K connection (20K encoding) they require 15 seconds, because most of the bandwidth is allocated to the streaming video. On the 64 K connection (50K encoding) they require 10 seconds. For the CD version we have only an anticipation of 3 seconds. We have written a very simple program that enables us to automatically produce a shifted timings file (according to the format specified by Real) by the number of seconds required, so that it can be merged with the video file to produce the final synchronized RealVideo file.
7. You can also avoid using the server if you plan very few connections at the same time (say five): you only need to set up Microsoft Internet Information Server 3.0 as described in Real knowledge base.
8. At 20kbps, we used 8.5kbps for audio (4 Khz), 11.5 kbps for video
with "Optimized frame rate: sharpest option", resulting in an average of 4 fps.
At 50kbps, we used 8.5kbps for audio (4 Khz), 41.5 kbps for video with "Optimized frame rate: sharpest option", resulting in an average of 4 fps.