• Draft Product Plan (December 2010 Snapshot)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Product Concept

Phased release, with an initial version as follows:

  • Target library-owned video, extending to 3rd-party licensed or other content over time
  • Focus on access concerns while allowing preservation to be addressed
  • Support both browser and mobile access
  • Support flexible access control
  • Support accessibility, transcripts and captioning
  • Player should provide fine-grained, responsive direct navigation and navigation by chapter/section
  • Player should support embedding
  • Content should be separable and recombinable, e.g., transcripts can be accessed by themselves, without the video (?)

Target Customer

  • Institutions with sufficient technical chops to install, configure, and integrate a complex system
  • Third-party service providers who want to support less-technically-capable institutions

Architectural Directions

  • Media Access Security - Initially, use the lease model, with a view toward adding a user/ip protection on the media server later on. DRAM extensions to the Darwin Streaming server is an existing solution.
  • Authentication - Needs to address single sign on.
  • Authorization - Would like to support CMS groups; LDAP and ADS groups; Shibboleth IdP attributes; locally defined ad hoc groups, across multiple apps or just in Variations; IP ranges. Possible roles include Administrator, Digitizer, Cataloger.
  • Repository - At least need discovery for management if not end users; considering Hydra and Fedora
  • Transcoding & Video Store - Could use Kaltura or Matterhorn, but we lean towards using Matterhorn for ingest/transcoding but preservation management will have to be done separately.
  • Metadata - stored in the repository
    • standards-based identification metadata and then import richer descriptive metadata from MARC or EAD finding aid
    • structural metadata for navigation, which would have to be fairly generic to accommodate a wide range of media content types
    • support transcripts and captioning, with multilingual support, but we would not necessarily support transcript creation in phase 1
    • rights
    • digital provenance
    • technical metadata
  • Player - investigating Open Video Player, open Kaltura player, JWplayer, Matterhorn's Engage UI
  • Delivery technologies - we will need to work with a variety of these, including proprietary and open systems, desktop and mobile. The main ones we are paying attention to are listed below.
    • media server - investigating Apache, Wowza, Red5, ...
    • protocol - rtmp, http progressive download, http livestream, ...
    • content format - H.264, WebM, ...
    • client api - Flash, Apple Objective C (iOS), HTML5 video tag

We are exploring various modular architectures. Here is one possibility.