Child pages
  • Technology Choices -- Notes

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Technology Choices we'll need to make with Variations on Video

Notes taken at the Variations on Video meeting Wed. Oct 6, 2010--second day.

Technology areas for discussion

Video encoding/transcoding

Streaming/delivery

There needs to be an abstraction between media storage and delivery.

Streaming (i.e. RTSP, RTMP, etc.) vs. segmented HTTP (i.e. Apple HTTP Live Streaming) vs. HTTP progressive download

How to enforce access controls on HTTP-delivered content?

Role of Comprehensive solutions (i.e., Kaltura)

Kaltura can be hosted or local, and is open source. Kaltura may address workflow piece, and possibly authentication as well. And may provide abstraction between storage and delivery. Duraspace is also working with Kaltura to have it work with Fedora.

Concerns with Kaltura: while it's open source, it's one company that's developing it. It's not a community-supported open source project. Possible business viability question--though since it's open source it could become community-supported.

Possible architecture: Variations can be a set of services that connects to Kaltura (or other systems) as part of components. Would still need to address authentication with streaming system.

Access Control

Identification/authorization

Authentication on streaming technologies--most institutions currently simlinking/copying video file to a random string of characters to ensure the video is restricted. NYU does referrer and cookie checking, but would like to connect to Grouper for more fine-grained access. Variations currently does restrictions but it needs to do a data load of information for access.

Having access control very close to content storage would be nice, however, it conflicts with the out-of-the-box idea.

Support for Metadata

Metadata management

Annotations -- could be provided as a service. Clip or bookmark is assigned as an identifier that be referenced. This is a more modular approach as the different components of the system can key off of the identifier to modify/display content.

Digital Repository Systems (and management of digital assets)

Should all content and metadata be stored in Fedora? Can content be streamed directly out of Fedora? Fedora is looking right now at more complex backend storage, and in the future streaming media (but we can't plan on this right now). However, it might be able to be provisioned by Fedora for access control purposes.

Loading metadata/content from outside systems: Subscriptions, other connections to already existing content. Question: where does the metadata/content live (inside/outside of Variations?). A possible solution (not that it's necessarily the best way to go): have the data live outside, proxy the data using Fedora so the repository just points to it. Outside content providers would need to adhere to standards.

Build framework/components/one large system

Identifiers

Transcoding

Automated ffmpeg - possible issues w/ quality, licensing

Hands-on desktop apps - manual control

Probably need to support both approaches

Cloud transcoding? - Zen Encoder

"Out of the box" core functionality

(Minimal technology stack that would be needed)

  1. Streaming server
  2. Ingest/transcoding
  3. Basic player interface
  4. Simple metadata storage and management search
  5. Access Control (with or without rights), with authentication piece
  6. Ability to import metadata from other systems
  7. Annotation tool
  8. Ability to expose content and metadata to other systems
  9. End-user search
  10. Workflow (for human request-tracking) -- this may be non-core, phase 2 functionality, there was some argument this wasn't entirely necessary to start. Perhaps outside systems can handle the workflow.

There is a trade-off between having an out-of-the-box solution vs. future-proofing for other technology solutions.