Micala v0.4 documentation

CERN specific implementation

«  Development practices   ::   Contents

CERN specific implementation

The idea of micala is to abstract from a specific environment implementation. This is now not easy because micala is born in University of Michigan and CERN, and the software was created according to the infrastructures present there.

The future development will move to separate this implementation, to have an abstract chain of processing from which each environment can then inherit and create a specific implementation.

Note

Currently, some modifications need to be done to use micala in a different environment than CERN.

Re-encoding using Episode

Thanks to Mac cluster servers present at CERN, we can use the software Episode to transcode f4v to mp4 very fast: our measurement says that it is 5 times faster than using ffmpeg in one machine.

The script webcast2lectureobject_episode_mac.py is a modification of the normal webcast2lectureobject.py, where ffmpeg is replace with Episode. Episode software can be run passing a XML file with all the data about input, processing way and output expected. The script generates this XML, copies it to Mac server using scp and execute the transcoding throw ssh. After generating one PNG per second as slides from the main video, it tests every 10 secs the status of the transcoding process: when finished, it takes the new master.mp4 and uses it as main master for all the future processing.

Publishing policies

Because of CERN security policies and software implementation, the following part is specific for only micala installation at CERN.

Currently, the software to publish lectures used at CERN is Invenio. This means that we don’t have to take care of the lecture’s publication in the web page because it is done automatically. The important step is to process the lecture creating the video formats we need, and then inform somehow Invenio that everything is ready to be published.

The script lecture_publish.py does this. It is controlled by the daemon and it is responsible to call the script to publish flash and podcast formats.

As first step, it ask to Invenio to have metadata information about this lecture which has to be published: using a web service, the result is a XML file with restriction policies to be set. If it is completely public, there are no restriction actions. Once it has this information, it creates the publishing folder setting eventually the folder permissions. Then it runs the scripts to publish.

After this, it informs Invenio that the lecture is ready to be published in the website. Finally set again the folder permissions.

To have more information about these interactions, please refer to this restricted documentation

«  Development practices   ::   Contents