by Dr David Wong
The workflow provides for an end-to-end solution where users submit their audio / video file on a university web page, and after a few minutes receive an email containining instruction on how to link the transcoded media file on their web page.
The systems components consist of:
Workflow server (Ubuntu), provdes a platform for NSSDropbox 2 (from University of Delaware).
A modified version of NSSDropbox 2 using LDAP security, provides upload facility (2.0GB limit per file). Each submission causes an email sent to a designated email account
Script (Perl) in workflow server scans email account for new message, extracts uploaded file out of NSSDropbox’s internal storage, writes it to a designated directory, emails administrator a notification of the upload, and emails the user instruction on how to link the transcoded files from their web page
Mac OS XServe, running Episode Engine, scans the designated directory regularly for new files, does transcoding, and writes transcoded files to an output directory
The output directory is mounted on a web server, making the files available on the web
Templates in University CMS, and VLE (Blackboard), enable end users to link the transcoded files from their web page
JW Player
File formats:
Audio: accept mp3, wav and wma, and output to mp3
Video: accept mpg, mp4, avi, and output to mp4 h264 AVC (Levels 1.2 and 3), and AAC audio encoding. Some success with other input formats wmv, tod, mod etc.
Advantages
Episode Engine’s preset formats and workflows transcode files that conform to h264 standards.
JW Player provides for a large number of platforms.
Very low load on servers.
Apart from staff costs, main expenditures are XServe and Episode Engine.
Multiple workflows based on media type or requirements (e.g. teaching and learning, audio only, video).
Issues
Episode Engine is not easy to use, nor flexible; its warning and error messages can be confusing and far from instructional. In cases where it is stuck with a job that’s difficult to transcode, it could hang and requires intervention by aborting the job. It’s possible to modify / create workflows which requires root access, and I didn’t pursue that.
Episode Engine strips out metadata contained in file.
Workflow server (running NSSDropbox 2) is inside the firewall to minimise security issues. Off-campus users can upload if they log in using VPN.
Not really an issue, but for people new to Perl and scripting (or those thinking about implementing NSSDropbox 2), we did spend a lot of time (weeks) modifying NSSDropbox 2 code, adding extra bits (and removing/disabling others), and hours of testing. And time spent learning Perl.
Migration test case
Two years ago, most of the univeristy video files were hosted externally. With Episode Engine and Helix, we began hosting the assets in-house. By mid September 2011, we have about 700 AV files stored on a disk attached to the Helix streaming server (a majority of these originally migrated from another project dedicated to teaching and learning). Most of these files are in mp4 (video) or mp3 (audio) formats as for about 1.5 year we stop transcoding file in Real format and also ceased streaming, giving preference to wider standards. This paves the way for a relatively easy introduction of the “AV Dropbox” scheme (easy in the sense that we didn’t have to re-transcode the files)
Migration consists of requirements analysis with stakeholders, and commissioning of servers (workflow & upload using NSSDropbox, and web) and storage areas (Netapp, one for upload and one for transcoded files). Other issues came into play including the use of a “friendly URL” (we decided on avcontent.reading.ac.uk), and proxying the workflow (or not, being the motion at the moment), and re-transcoding a small number of old files to mp4 / mp3.
Going live was an event that demanded some added attention as updating the CMS and Blackboard templates (to point to new server URLs) meant currently available AV files needed to continue to work with the new URL. A great deal of checking went in to ensure going forward does not result in going back swiftly! Apart from some templates that were non-standard, the go-live went unnoticed and was a quiet success.
Next step
JW Player remains an attractive asset. With HTML5 (and mobile platforms) becoming mainstream, we are looking at what’s possible. There is significant requirements from the corporate office to provide for these outlets. A bought-in solution is unlikely, nor something that potentially gives security concerns. Cloud solution maybe possible, so long uploaded files are not stored on remote servers.
Zend.to appears to be attractive with regard to workflow.
Dr David Wong Multimedia: Corporate Information Systems Support IT Services, University of Reading
Permalink
| Leave a comment »
