Berkeley Bits

September 25, 2008

REPLAY –> Opencast update

Filed under: What I'm Up To — Tags: , — jholtzman @ 4:33 pm

Quick progress update…

I’ve managed to get the REPLAY manager webapp to run individual jobs, return the ID of the job, and then return the status of the job.  This proof-of-concept (based on replay v0.4) just executes an indexing job on a pre-defined media bundle.  More work will obviously be needed to make this fully functional.

This is no big deal, really, but it does mean that REPLAY can fulfill the “media processing manager” component, as described in the opencast draft architecture document.

September 14, 2008

Replay requires Perian

Filed under: Hard-Won Wisdom, What I'm Up To — jholtzman @ 9:05 am

I spent a lot of time last week trying to get replay to encode, OCR, and index some video files that were captured and encoded for webcast.berkeley.edu.  It was productive to go through the source code, looking for the reason I couldn’t get anything to index.  After a couple of hours help from Tobias, we tracked down the problem: there is an undocumented dependency on the Perian toolkit on OS X.  Now that perian is installed, mp4s, dv files, and the like are properly encoded, OCR’d, and indexed.

September 9, 2008

Webcast integration with REPLAY

Filed under: Hard-Won Wisdom — jholtzman @ 12:08 pm

The Opencast project’s first deliverable will be a version 0.1 integration of UCB’s Webcast system and ETH Zurich’s REPLAY (possibly also including Bjoern’s ‘channel syndication’ work).  The primary barrier to the integration is the mismatch between REPLAY’s statically defined workflows (defined as ant scripts) and Webcast’s task based finite state machine (stored in the DB and loaded into memory at startup).

Tobias and I have thrown some ideas around for overcoming this mismatch, including:

  1. Colocate Webcast and REPLAY in the same JVM (or package the custom ant tasks and scripts in a jar, deployed to both systems), where the commands executed on state transitions call the ant tasks directly
  2. Call REPLAY’s internal SOAP interfaces
  3. Iterate through the “success” transitions in the state machine to generate a “directives” file for REPLAY to execute
  4. Generate a REPLAY directives file from the front-end, avoiding the state machine for everything but status reporting
  5. Colocate Webcast and REPLAY in the same JVM and call the REPLAY Java APIs from Webcast’s transition commands
  6. Integrate with Webcast’s ical based task reporting.  This would involve:
  • Adding discrete, atomic workflows to REPLAY
  • Deploy an adapter to REPLAY’s manager component to consume Webcast’s ical tasks and execute the relevant workflow
  • Update Webcast’s ical feed to include all relevant recording metadata so the adapter can re-create the bundle if necessary

I’d like to go with option #6, but I need to do some more digging in REPLAY to see if it’s possible to either reuse existing media bundles from past workflows or less desirably, whether we can create new bundles by reusing an existing media file.

Powered by WordPress