Abstract

As tools like Opencast Matterhorn continue to reduce the barriers to entry for capturing and distributing lectures, it is important to recognize that the availability of video alone is not sufficient to improve educational outcomes. Since January 2012, Entwine has collaborated with SWITCH on the Annotating Academic Video (AAV) project with the goal of creating a standardized, open and flexible tool/framework to enable Swiss University faculty, staff and students to annotate video across a mix of platforms including players, video management and learning management systems.

This post provides a first look at the features, architecture and our progress to date with the AAV project.

Why we need annotations in video management systems?

For the past decade, higher education institutions have been adopting lecture capture technologies to improve the academic experience. Although these technologies are proficient at capturing and distributing media to learners, they perpetuate an outdated and passive learning experience by not providing tools for students to enrich, enhance and share media with classmates.

The most common method for teachers and learners to interact with video is via note taking and discussions. The majority of education based video services do not take advantage of the annotations tools that YouTube delivered to the masses a few years ago. Taking into account that today learners and teachers are becoming less and less physically connected, this void is particularly painful as it means that there is not a simple method to comment on educational videos, such as lecture recordings. Simple interaction between learners and teachers through comments is not the only pedagogical benefit of an annotations tool. Most students take private notes during a lecture. The ability to annotate a video lecture has the potential to enrich notes by adding object and timing references to them. Sharing enhanced notes will help other learners and improve relevant information about search results.  AAV can also be used for assessment. For example, instructors can evaluate the annotations produced by a student to gauge concept mastery.

Continue Reading…

Many institutions have captured lecture recordings with varying levels of audio in their Opencast Matterhorn system. A common request is the for the ability to review audio levels on the server side and adjust the levels so they more closely match. Unfortunately, this isn’t possible with currently installed ffmpeg and we couldn’t just expand the composer service to do audio normalization. Recently the University of Cape Town contracted with Entwine to create a new service for audio leveling. Because they already had experience with SoX, a free command-line multi-track audio editor/processor, a new audio analysis and leveling service has been implemented based on Sox, along with an audio normalization and analysis workflow operation.

Once the service implementation and documentation have passed the community review, the new functionality will be added to the next version of Matterhorn 1.4.x.

Continue Reading…

I added a page on the Opencast wiki describing Matterhorn + Apache SSL Configuration.

In SSL configuration, a way is described to configure Matterhorn to listen for and answer HTTPS requests. Instead of having to set up Matterhorn with SSL certificates, there is also the option of keeping it on HTTP and put Apache (or any other HTTP server) in front of it, handling the HTTPS requests and passing them on to Matterhorn through HTTP.

Configuring Apache Httpd

There is plenty of documentation available on how to set up Apache HTTPd with support for HTTPS. Enabling Apache as a frontend to Matterhorn is achieved by installing an SSL certificate and properly configuring HTTPS using these certificates, as well as enabling request forwarding with a little twist, as detailed in the two sections below:

Enabling Support for SSL

Again, enough has been written on this topic so it should be easy enough to find documentation on how to do this on your platform. Using the search engine of your choice, look for “Apache Httpd” and “mod_ssl” to get started. It eventually comes down to installing mod_ssl, creating a certificate request, having that request be signed by a certification authority (or create a self-signed certificate) and adding the certificate, the private key used to create it as well as the signer’s root certificate into the proper locations in the Apache HTTPd configuration file.

Then, after some tweaking and testing, Apache will be listening on port 443, which is used for https:// urls. For the rest of this document, we assume that a virtual host is being used to gather the requests for Matterhorn under the url http(s)://matterhorn.institution.edu.

Read more here.

As a follow up to our first post, Podcast Producer to Opencast Matterhorn Migration, Entwine has decided to write a series of articles related to migrating from Podcast Producer (PcP) to Opencast Matterhorn (MH). The posts will address questions/issues from the perspective of an organization running Podcast Producer and investigating Matterhorn as a potential replacement.  We will also explore possible migration paths for those who have made the transition decision and are looking for ideas and/or next steps. The series topics will include nomenclature (current post), technical comparisons and migration strategies (hardware and software). If you have other topics you would like us to cover, please add your ideas to the comments section.

Continue Reading…

Entwine partnered with UNINETT, an organization in Norway providing IT infrastructure services for Norwegian universities, to deploy a centralized Opencast Matterhorn lecture capture system prototype. Entwine’s development work for Uninett resulted in a significant contribution to the Matterhorn platform. Much of the work has been merged back to the community and will be part of the much anticipated Matterhorn 1.4 release. A big thank you to UNINETT for their generous support of the Matterhorn project.

Contributed Features

  • User groups
    Users can be grouped and groups can have access rights.
  • Access control list management
    • ACL scheduling
      Apply ACLs in a time based manner.
    • ACL management
      Predefine ACLs per organization and give them names.
    • ACLs on a per episode basis
      ACLs can now be set on the episode level in addition to the series level to provide fine grained access control.
  • Ingest from CloudStor service
    Service is a cloud file store. Matterhorn polls this service and ingests any uploaded media packages.
  • Integration with Shibboleth authentication and authorization service
  • RPM based deployment on a distributed setup
  • Archive metrics (1.4)
    Monitor free and total space via JMX.
  • Graylog2 integration
    Graylog2 is a tool for centralized logging.
  • Branding for Engage based on the tenant
  • Browse Engage by series

Contributed Fixes

  • Several fixes for distributed and multi-tenant MH setups (everything 1.4)
    • Event handler synchronization
      Several concurrency issues caused handlers to interfere with services and each other.
    • Digest authentication
    • Media inspection property setting
      Properties in class CommonMetadata could not be set.
    • Workspace lock file synchronization
    • SearchServiceRemoteImpl forwarded only a small subset of query parameters
    • User propagation between stub and remote service
    • RemoteBase fix
      Could not handle 404 from series service.
    • Tenant config
      To support multi-tenant setups some config keys have been moved from the global config.properties to the organization config.
  • Miscellaneous fixes
    • Tiff encoding of ffmpeg caused tesseract issues (1.4)
    • Default workflow did not archive metadata catalogs (1.4)

Feel free to contact us if you have questions about our work with Uninett or the new Matterhorn 1.4 features.