Recording¶
The aim of recording a lecture is to get one camera’s video file and one slide’s video file. If you are new to the concept of slide-video-file, please read carefully this section of the documentation.
Note
The recording process is one of the most tricky part of the project. The quality of the final result is strongly dependent on the hardware used to record the lecture.
Recording the speaker¶
All you need is a camera to record the spoken person and eventually the room. You can use any kind of camera which you are able to connect and install in the recording pc. The quality of the encoded video can be non-HD, HD or FullHD. Yes, of course, there are some limitations: encoding a video file is a high consuming cpu process, so the resolution, frame per second and the bit rate depend on your recording machine. Currently, at CERN, we are using several kinds of camera, connected to the recording pc by Osprey video and audio acquisition cards. We are encoding the video file with a resolution of 640x460, bit rate 800kb/s and frame per second 25fps.
Recording the slides¶
How can you catch when the speaker comes back with the slides during the lecture? And if the speaker skips 2 slides? What about if you don’t have the original .pdf or .ppt?
The idea is to record the slides as a video file which lets you to:
- record backward/forward slides jump;
- record .ppt with animation;
- get the slides from any kinf of presentation format;
- have an audio backup (it is very useful);
The pc or laptop, used to display slides, is connected to the room projector using a VGA or DVI cable: with a VGA/DVI splitter, we take this source directly from the pc and use it as input to encode a new video file, recording whatever is done during the presentation.
From the VGA/DVI, it is possible to use VGA2USB or DVI2USB hardware devices: currently, at CERN, we are using Epiphan devices especially testing the card VGA2PCI which promises better performances. The entry-level device captures only a couple of frames per second at high resolution, but for now we are only capturing 1 fps anyway. The USB device is particulary indicated for the mobile recording platforms which is built around a laptop and carried to not equipped rooms.
The resolution can be higher than the speaker’s video, because the result is to have only some screeshots of the video. The quality of this recording is crucial: whne you gain quality in the video encoding, more stable and no degradation of the image, then you get better slides images. The consequence is to speed up also the processing after the recording, and less effort for the operator to check the final results.
At CERN, we are currently encoding the slides video at 1024x768, 650kbp/s and max 10fps.
N.B.: The VGA2USB device has an annoying problem that has been around for years, and does not seem to be getting fixed. Sometimes the captured image becomes blurry and then resolves over and over. Our analysis software thinks that the slides are changing on purpose, and generates many extra chapters, which must be deleted by hand. This doesn’t happen constantly, but often enough to be annoying. We would like to move to a higher quality PCI card. It seems that using better and more expensive VGA2USB devices the quality is higher: with the latest version of micala, we were able to record, process and publish more than 60 web lectures in 4 days: the screen analyzer has generated no extra slides.
Recording hardware and software¶
- Digital camera + Osprey card, for the speaker
- PC or laptop to display slides (and projector) + VGA splitter + VGA2USB/DVI2USB,
- Recording PC, enough powerful
- Recording software
The recording software is available for Windows, Mac OS X and Linux. For Windows, it is possible to use any encoder software. At CERN, we are currently using Adobe Flash Media Live Encoder because it meets our requirements. It is also available for Mac OS X. For Linux, the encoder is part of micala code, and it was used in production. Currently, at CERN, is not used anymore and it is not mainted in the project.
1. Linux-based recording system The Linux system runs either on a laptop (using Firewire to capture the audio/video feed) or on a PC (using an Osprey 100 capture card). The Osprey 100 capture card is old but is one of the few capture cards that work with Linux. We were using Ubuntu 9.10. The recording interface consists of PHP pages running on an Apache web server, so recordings can be started/stopped locally or remotely through the web interface. This system creates “raw” lecture objects, consisting of a master.avi file and one JPG slide image per second, which must then be uploaded to the processing server and turned into finished lecture objects.
2. Windows-based recording system The Windows system requires Adobe Flash Media Live Encoder (FMLE), which is free. Recordings can be started and stopped through a simple web page interface similar to the Linux system, so recordings can be administered remotely (see. We are currently using it with an Osprey 240e card to capture audio/video and VGA2USB to capture slides, and we are using the same machine to stream live streams for a webcast. Both camera and slides streams are captured as full-motion video as f4v files, which unfortunately must be “flattened” using the f4vpp.exe utility before they can be viewed or transcoded. This system generates two f4v files per lecture, which must be flattened, converted to raw lecture objects and processed to become finished lecture objects.
All together¶
Putting all together, we have two input in the recording pc, encoded simultaneously by the encoder software. The output are 2 video files, camera.f4v and slides.f4v, to be flattened.
Remote recording¶
N.B. The recording module is under development, providing new features and easier setup and utilization. The description you will find below are related to the current version in production.
To be possible to have remote recording/webcasting operation, micala includes a recording web interface software: it is written in Python served by a web server (you can choose the one you prefer). In this way, it is possible to connect to this website from another location and operate remotely.
N.B. From here, the documentation will explain how to control remotely Adobe Flash Media Live Encoder FMLE.
FMLE provides a command line binary, called FMLEcmd.exe, to control the encoding operations. Calling the binary with the parameter /s, it is possible to check the status or stop an encoding passed as argument. With the parameter /p and the filepath of a profile, a new encoding starts.
The encoding profile is a XML file containing the settings for the Video and Audio devices: refer to the Adobe documentation to have more information.
The web interface simply uses these commands to start/stop/status encodings: it needs a general XML files called recorder.xml which lets to abstract this profile commands, and presents to the operator the available programs.
A program has a name and status, running or stopped: each program can have more encodings. For example, the program Test shows a preview in streaming for the speaker camera and the slides. The Recording program starts 2 encodings to save the camera.f4v and slides.f4v files in one click.
What happen when you press the button Play on the Recording program?
The website checks in the recorder.xml which encodings are associated to the Recording program, and executes:
FMLEcmd.exe /p recording_camera.xml
FMLEcmd.exe /p recording_slides.xml
Micala is informed of the new recording, which will appear in the monitoring list with the status RUNNING for the recording task. When you reload the page, the website check the status with the command:
FMLEcmd.exe /s
and it returnd all the running encodings (not the XML profiles!) If you stop the Recording program, the website executes:
FMLEcmd.exe /s running_encoding_camera
FMLEcmd.exe /s running_encoding_slides
The web interface it is also connected throw web services to micala server to have information about the current recording: this is very useful for mobile recordings to be sure the connection between the interface and micala server is correctly set-up.
Refer to the configuration file comments in encoder_conf.py to have more info.