Adopter Highlights

These articles provide experiences of other universities that already introduced Opencast.



University of California Berkeley


The University of California Berkeley has provided a lecture capture service to the campus for many years, locally referred to as the webcast program. In need of an updated system that offered reliability, flexibility, and integration with campus systems, the campus made a decision to adopt Opencast for its lecture capture recording, processing and distribution system. After a successful Spring 2013 semester pilot, Opencast was rolled out to support the entire lecture capture service in the Fall 2013 semester. Supporting automated, “opt in” recording of classes in 49 classrooms, the launch was successful, recording 70 courses with 100% capture success rate. Building on this success, the team at UC Berkeley has continued to make improvements to the system, and is preparing to launch an upgraded system for the Spring 2014 semester with improved administrative capabilities, and a beta of the Paella Engage player.

Project Goals

In Fall 2008, Educational Technology Services (ETS) rolled out an updated infrastructure to our existing lecture capture infrastructure that was based on Podcast Producer as the processing engine, Mac Minis as capture agents, and a custom application layer to manage the “opt in” process and other admin functions. Immediately after launching this system, ETS became involved in the Opencast project, with the vision that Opencast would eventually replace our system.

After participating and contributing to the Opencast community and Opencast project in various capacities since the project’s inception, in Fall 2012, ETS formally launched a project to implement Opencast for the campus. The goal of this project was initially to replace an aging system with one that offered greater flexibility, sustainability and integration capabilities. Building upon Opencast, our longer term vision includes:

  • Increased scale/efficiency
  • Empowering instructors
  • Better experience for students
  • Offering video management tools to campus

About UC Berkeley Webcast Program

UC Berkeley has offered the lecture recording services to the campus in some capacity since 1995. Through a model of publishing recordings publicly, this service has provided the world with a window into the UC Berkeley classroom experience. From Berkeley students to life-long learners around the globe, millions of viewers have tuned in to view the over 16,000 hours of content made available through the webcast program.

Recordings are made available to students through our public YouTube and iTunes U distribution channels. Webcast.berkeley.edu aggregates the recordings from these channels and presents them in a fashion conducive for searching by course. Instructors have an option to make the lecture recordings for a course accessible to “students only”. Traditionally, we have been able to accommodate this through a security-by-obscurity method using iTunes playlists. Beginning with the Spring 2014 semester, we will be able to offer this restricted level of access through offering access view recordings in the Paella Engage player via LTI integration with the campus learning management system (Canvas by Instructure). A limited number of courses (about 9) will be participating in the Paella Engage beta, while we deepen our understanding of how to best offer streaming video service with Opencast.

Berkeley currently has 49 recording-capable classrooms. Forty-six of these classrooms offer audio only or screen+audio recording. The remaining 3 classrooms are large lecture halls, and offer both screen and video recording (prior to Opencast, these rooms only offered video, and no screen option due to limitations with Podcast Producer software). For video recording, students are hired to operate the camera from a control booth in the back of the auditorium (for which we charge the department a portion of the cost).

The webcast program operates on an opt-in basis, in which instructors who are scheduled to hold classes in recording-capable classrooms are invited to sign up to have their class recorded (a process we call “Participation Management”). When signing up, instructors have the option to choose what gets recorded (audio, screen and/or video), where the recordings are distributed (public or students only), and under what license the recordings are distributed (e.g. Creative Commons). In a typical semester, about 70 courses are scheduled for recording, which generates about 3,100 hours of recordings.

One aspect of our service that has lended to its success is the minimal input required on the part of the instructor. Once they sign up and agree to have their course recorded, the only additional requirement going forward is to ensure they turn on and wear the provided lapel microphone during class. Our coursecast administrator handles all review, trim and editing needs for the recordings. The coursecast administrator also monitors each recording as it begins, ensuring that the microphone is on and working. If there is a problem, a “runner” is dispatched to the room to try and correct.

Overview of System

Server Configuration

Our Opencast deployment operates on 6 virtual machines running on 3 PowerEdge M620, each with 16 2.6Ghz Xeon ES-2670 cpus and 192 GB of ram.

Each VM is running Centos 6.5 x86_64 and is configured as follows:

  • 1 admin server – 4 cores, 48 GB of ram
  • 2 worker servers – 12 cores, 64 GB of ram
  • 1 engage server – 4 cores, 48 GB of ram
  • 2 streaming servers – 7 cores, 64 GB of ram

Each machine contains 2 virtual nics. One is public and runs at 1 Gb/s and the other is private and runs at 10 Gb/s.

Centralized storage is via NFS exported from the admin server over the private network. Ten TB of storage are allocated to the NFS share. All storage is via a campus provided SAN service.

We use a campus hosted PostgreSQL v9.2 instance for the backend datastore.

Capture Agents

Led by Kevin Chan and Jonathan Felder, the ETS Technical Operations team conducted extensive research and testing of various vendor and custom configurations during our Fall 2012 (internal testing period) and Spring 2013 (pilot) semesters to determine the capture agent that best fit with the UC Berkeley webcast program. In general, we were looking for a low cost solution that worked with our existing audio/visual infrastructure in our general assignment classrooms. Over the summer break of 2013, the old Mac Mini capture agents (used with the previous Podcast Producer system) were replaced with Opencast style capture agents.

All of our Opencast agents run ubuntu 12.04 LTS, and there are two main types:

  • 46 – Screen agents – dell optiplex 9010 USFF – 2.9 GHZ i5-3470S, 4GB of ram, 300 GB of disk space. Capture is accomplished via external epiphan vga2usb devices and pulse audio.
  • 3 – Video agents – dell optiplex 9010 MT – 3.4 GHz i7-3770, 8 GB of ram, 1 TB of diskspace. Capture is accomplished via blackmagic intensity pro cards for hdmi, blackmagic decklink mini recorders for sdi, and pulse audio.

We also are experimenting with epiphan dvi2usb solo devices for hd capture. In addition, due to a small of amount of instability in the video agents (opencast crashes 2-3 times a semester) we are trying out an HP Z420 workstation in one of the video capture rooms. The screen agents are not affected. They have run flawlessly.

System Enhancements

The application development and operations teams at UC Berkeley implemented several enhancements and extensions in order to meet our needs. Following are highlights of that work that may be of interest to the community.

Capture Agent Monitoring

A key responsibility of the coursecast administrator is monitoring capture agents and ensuring that recordings are being captured adequately. The existing capture agent confidence monitoring tool in Opencast was not sufficient for our needs, so our Technical Operations team developed their own version of a capture agent monitoring dashboard. Using Opencast’s APIs and incorporating a calendar library, this dashboard gives coursecast administrators the ability to:

  • Quickly see which capture agents are currently recording
  • See the schedule for each capture agent
  • Determine the audio level for each agent
  • Listen in to any recording, to ensure the microphone is turned on and working properly
Participation Management

Participant management at UC Berkeley refers to a workflow that at its simplest, includes the following steps:

  1. Identify courses that are scheduled in recording-capable classrooms for the upcoming semester
  2. Send to the instructor(s) of each course an invitation to “sign up” to have their course recorded
  3. “Sign up” includes:
    • Choice of what is recorded (audio, screen and/or video)
    • Choice of distribution (public vs students only)
    • Choice of licensing (Creative Commons or no distribution rights)
    • When recordings should be published (immediately or delayed)
    • Agreement from each instructor to have the class recorded and published
  4. After all instructors for the course have indicated agreement and made selections, schedule the course for recording

See below for a sample sign up form for instructors.

Though this workflow appears straightforward at first glance, the various permutations and conditions that may exist result in a complicated set of workflows required to manage the participation management workflow.

After reviewing the workflows needed, the development team selected Salesforce as a solution to handling many of the activities involved. ETS had been using Salesforce for other services for the past 2 years, and already held records for all of the classroom spaces and many of the instructors. Salesforce offered a number of features that rendered it suitable to incorporate into a participation management solution:

  • Highly customizable and extensible data objects that could be used to hold and manage data
  • Customizable workflows that could be triggered by dates and changes in field values, and could be used to execute field updates, automated emails, and task creation
  • Email templating engine that could be easily edited by webcast staff
  • Powerful reporting tools
  • Extensive APIs

Developing the integration between Salesforce and Opencast primarily revolved around 2 modules, both of which were built within the Opencast framework – CourseDataMover and the Sign Up Form. A walkthrough of our participation management process and the integration work is available at https://opencast.jira.com/wiki/display/MHDOC/Participation+Management+with+Salesforce.

Paella Engage for students

As part of the Spring 2014 semester release, we are offering, to a subset of the webcast courses, access for students to use the Paella Engage player. In our process of implementing the Paella player, we found and resolved a number of issues in regards to accessibility for a user using a keyboard or screen reader. We also identified a number of usability enhancements. These accessibility fixes and enhancements will be contributed to the Paella project for consideration of inclusion.

Streaming media to Paella Engage

We are using Wowza to stream video to the students participating in the Paella Engage beta this semester. In our configuration, Wowza Media Server streams media files to the Paella Engage player. Opencast’s workflows are customized to compress source recordings to 500 Kbps H264 video and 64 Kbps mp3 audio:

profile.hd.stream.ffmpeg.command = -i #{in.video.path} -threads 0 -vcodec libx264 -profile:v high -preset superfast -b:v 500k -vf scale='trunc(oh*a/2)*2\:720' -acodec libmp3lame -ar 44100 -ab 64k #{out.dir}/#{out.name}#{out.suffix}

The administrative Opencast node (video.berkeley.edu) hosts the central nfs file store and is exported via 10Gbit private subnet to two streaming edge nodes, streaming01 and streaming02. streaming.berkeley.edu is a round robin DNS assignment that distributes requests to streaming01 and streaming02 each of which has a dedicated Gigabit link to the campus network.

There are two parameters that tell Opencast where to store the streams and the root url of where to play streams from:

org.opencastproject.streaming.directory=/export/mh_data/opencast/shared/streams
org.opencastproject.streaming.url=rtmp://streaming.berkeley.edu/matterhorn

streaming01 and streaming02 are configured to stream Opencast via the StorageDir variable in /usr/local/WowzaMediaServer/conf/matterhorn/Application.xml:

<StorageDir>/export/streams</StorageDir>

Where /export/streams is a symlink to the nfs mounted file share video.berkeley.edu:/export/mh_data/opencast/shared/streams.

Wowza has a test suite which allows you to load a streaming server. This is what a single streaming server looks like while continuously streaming 600 simultaneous 1.5 hour 500Kbps video/64Kbps audio files from an 8 core vm with 16GB ram:



For the beta semester, we will enforce a limit of a maximum 1000 connections to each streaming server and set a timeout of 10 minutes of inactivity to disconnect idle clients. Our goal is collect utilization data that will help us determine the needs in order to roll out the Paella Engage experience for all students.

Canvas LMS LTI Integration

For students to access the recordings, we are using LTI to integrate Opencast recordings with our LMS – Canvas by Instructure. Canvas provides an easy method for adding an “External Tool” to a course through a few methods based on the LTI specification. Opencast is already configured as an LTI “producer”, so we just had to figure out the protocol to incorporate the recordings listing page for a given series as an LTI tool.

For the first semester, we will manually add the LTI tool in the Canvas course for all courses participating in the webcast program. To facilitate this, we added a REST call to Opencast’s Series service to generate the cartridge XML necessary to add the tool to a course.

In the future, we hope to automate this process, wherein a Opencast series will have an identifier that allows the LMS to recognize and associate the series with a course in the LMS. Once that recognition is made, using the Canvas APIs the LTI tool will automatically be added to the relevant courses.

Admin UI Improvements

During the first semester running Opencast in full production, the operations team identified a number of places in the admin UI where additional data about the jobs being processed would be helpful. For example:

An new “Ignored” tab to find recordings that have been “ignored”
On the Processing tab show the capture agent and date/time the current operation started
On the On Hold tab show the capture agent and date/time the recording reached the “hold” status
On the Finished tab show the capture agent and date/time a recording finished processing
On the All tab, show the capture agent

We have implemented these improvements and plan to contribute these to the project (https://opencast.jira.com/browse/MH-10039).

Automated Lecture Titles by Date

Another enhancement that was aimed at improving the administrator experience, was to change the format for automated lecture titles when a group of recordings is scheduled. By default, Opencast appends a number to each recording, e.g. “Biology 1a 1,” “Biology 1A 2,” “Biology 1A 3.” We found this approach to be problematic when, for example, a recording within that group is cancelled due to holiday or exams. The numbering is then out of synch with the course syllabus, and each recording has to be individually corrected.

Our solution was to append the recording title with a date instead of a number when scheduling a group of recordings (e.g. “Biology 1A – 2013-10-28”). This solved the problem of numbering being out of synch, and is expected to reduce the amount of time an administrator spends editing lecture titles. We plan to contribute this to the project as well, as a configurable option.

YouTube API v3 Upgrade

During the Fall 2013 semester, we noted a number of processing failures due to YouTube service issues. As a measure to reduce the occurrence of these failures, we have retooled Opencast’s YouTube service to use the current API v3 (currently Opencast uses YouTube API v1, which is no longer supported).

Publish Delay

This feature existed in our previous system, and is popular among our instructors who feel that by delaying publication of the recording, they can reduce the likelihood that students will skip class. Publish delay is offered to instructors during the opt in process, where they can specify the number of days after the recording date when the recording should be published.

The selected publish delay is stored in Salesforce, and when the recordings are scheduled in Opencast, the publish date is stored as a new data point in the metadata for each recording. The publish date is editable by an admin, so the delay can be adjusted for individual recordings as needed.

After the recording is reviewed/trimmed, the recording will finish all processing steps in the workflow, and then move to a new “hold” step, where it awaits the specified publish date.

A new “Delayed” tab in the Admin UI allows an admin to quickly find recordings that are on delay, and a new action “Cancel Publish Delay” is available for the admin skip the publish delay and publish the recording.

The publish delay feature relies on an operation that runs each day in the morning, and checks for recordings that are on delay and scheduled to be published that day. Any that are found are sent on for publication and distribution.

We hope to submit this feature to the project in the near future.

Next Steps

In the Spring 2014, we will begin the next phase of design and development work, which has not yet been scoped. We look forward to sharing our plans with the community as they evolve.

Why did you choose Opencast?

While our first phase goals were to replace an aging system, the decision to use Opencast is in support of the larger vision for our webcast program. Our goals are to:

Build for scale/efficiency

With Opencast, we have the ability to scale the program to more classrooms and capture more courses, without any additional licensing costs. Additionally, the architecture supports a scalable server infrastructure, enabling us to easily ramp up the processing environment to meet demand.

Empower instructors

Our instructors are exploring innovative ways to use video in instruction, with lecture capture only meeting a small part of their needs. They want to publish video for instructional purposes to multiple places – YouTube, the LMS (Learning Management System), and other custom destinations. Opencast gives us the ability to build powerful workflows for our instructors that will allow them to publish once, everywhere.

Better experience for students

We believe the tools powered by Opencast and exposed through Engage tools – segmentation, in-video search, and bookmarking and annotation, will provide students with tools that improve the efficiency with which they use video to support their learning.

Offer video management tools to campus

Opencast will initially be used for instructional video, but we have a need on campus to provide tools to other video producers that allow them to distribute their recordings to our public channels. Opencast allows us to build workflows for other departments that empower them to manage distribution of their videos independently.

Contributions to the Opencast Project

All of our code is publicly available to anyone who is interested in viewing as a reference for their own implementation. Visit the UC Berkeley Opencast repository on BitBucket https://bitbucket.org/opencast-community/matterhorn-berkeley-fork.

Now that our Spring 2014 release is out the door, we are currently preparing code contributions for as many of the above features as we can, with the intention to contribute these back to the core project. We look forward to submitting our contributions for committer review in the coming months.

Contact information

For more information about the UC Berkeley webcast program or the development efforts, please feel free to contact any member of our team. You will find our contact information at https://ets.berkeley.edu/ets-staff.

Judy Stern, Webcast Service Lead and User Experience Specialist
Michelle Ziegmann, Project Manager
John Crossman, Developer
Fernando Alvarez, Developer
Eric Odell, Technical Operations
Kevin Chan, Technical Operations
Jonathan Felder, Technical Operations
Paul Farestveit, Quality Assurance Manager
Ben Hubbard, Production Services Manager