introducing the vcr project

Thu, Sep 13, 2007

This is an internal UHI project to put a user interface onto the Codian MCU 4200 kit that we use for recording video conferences.

It has an XML-RPC interface that takes a struct of parameters so I’ve done a quick test application to query it using Apache XML-RPC, which is very nice indeed. For the UI I’m tempted to use the Google Web Toolkit. I’ll wait and see what comes out of the initial requirements meeting tomorrow. It’ll be a high level overview of what’s needed by those who intend to use it.

I think there will be some overlap with the CTREP project in that the Codian UI could hook into Fedora for cataloguing the saved video conferences. The Fedora interfaces are all full web services which now have generated Axis2 + XMLBeans clients thanks to my work on CTREP.

At the moment it doesn’t seem to be possible to download recordings via the XML-RPC interface. I seem to remember it may be necessary to mount the server and extract them that way. However, the problems don’t end there as the recordings are stored in native .codian format and the only way to convert them to MPEG for external viewing is to use the Codian MPEG Converter (PDF), which only runs on Windows. Having said that, it also seems to be possible to FTP to the codian and download a .mpg that way. Not sure where the .mpg came from as the docs say that recordings are stored as .codian files. There seems to be a .mpg for each .codian but this might not be universal. Also, FTPing very large recordings is not feasible. It’s just too long to wait.

I think a large part of the project will be how to minimise the delay when archiving a recording. I seriously think this will have to be an asynchronous process. i.e. Choose the recording to archive/catalogue then the system will take care of extracting/converting/uploading to the repository in its own time. Users will have to understand that the process is just that, a process, rather than a one-time operation. When they choose a recording, they can catalogue it there and then and the system will send them an email when the process of uploading to the repository is complete. Just a thought.

To support the asynchronous proposal, here is a quick benchmark test I did:

687Mb recording took 40 minutes to download via FTP from the codian server. I downloaded the .mpg file that was next to the .codian version of the recording.

The .mpg is an MPEG-1 file so the quality might not be acceptable.

A way to reduce the processing time may be by chaining the web services using BPEL. So rather than a central application downloading the .mpg and sending it off to the repository, instead, download the .mpg direct to the repository.

comments powered by Disqus