Variations on Video: The Avalon Media System
Download as PPTX, PDF0 likes1,710 views
The Avalon Media System project, a partnership between Indiana University and Northwestern University, aims to create an open-source system for libraries and archives to manage and deliver audio and video collections. Funded by a national leadership grant, the project's first release is expected in February 2013, focusing on installation support and functionality for various media types. The project encourages community participation and outlines plans for ongoing development and improvements beyond the initial release.
Variations on Video: The Avalon Media System
- 1. Variations on Video: The Avalon Media System Jon Dunn, Indiana University Michael Klein, Northwestern University Digital Library Federation Forum November 4, 2012
- 2. DLF 2012 11/4/2012 About Us • Jon Dunn – Interim Assistant Dean for Library Technologies and Digital Libraries, Indiana University – Project Director, Avalon • Michael Klein – Senior Software Developer, Enterprise Systems, Northwestern University Libraries 2
- 3. DLF 2012 11/4/2012 Agenda • Project overview and status • Demo • Release 1 • Technical and metadata architectures • Plans beyond Release 1 • How to participate 3
- 4. DLF 2012 11/4/2012 Project Overview • Funded in part by a National Leadership Grant from the Institute of Museum and Library Services • Original name: Variations on Video • Planning grant: – August 2010 – July 2011 • Implementation grant: – September 2011 – October 2014 • Partnership between libraries at Indiana University and Northwestern University 4
- 5. DLF 2012 11/4/2012 Project Partners and Collaborators 5
- 6. DLF 2012 11/4/2012 Project Objectives Goal: Create an open source system to enable libraries and archives to provide online access to video and audio collections • Digital audio/video management and delivery system, focused on needs of libraries and archives • Follow an agile, open source development model • Leverage existing technologies, where feasible • Communicate and market the project broadly to increase awareness and grow the community of users and developers 6
- 7. DLF 2012 11/4/2012 What needs are we trying to serve? • Libraries and archives (and museums?) • Wide variety of audio/video collections, uses, and access needs – Licensed educational video collections – Video/audio e-reserves – Archival collections – Open access collections • Research and teaching & learning use • Long-term management and access • Tie-in with preservation
- 8. DLF 2012 11/4/2012 Existing Solutions Insufficient • Institutional and digital library repositories – DSpace, Fedora, Digital Commons, ContentDM • Web video services – YouTube, Vimeo • Streaming servers – Flash Media Server, Real Helix, Wowza, Red5 • Classroom lecture capture – Echo360, Mediasite, Opencast Matterhorn • Digital asset management systems – OpenText, NetXposure • Online video environments – Kaltura, Brightcove
- 9. DLF 2012 11/4/2012 Project Progress • Most of development team hired • Trained on agile development (Scrum) • Community demo releases: – Release 0, July 2012 – Release 0.5, October 2012 • New name • Active participation in Hydra and Matterhorn communities 9
- 10. DLF 2012 11/4/2012 Current Activities • Northwestern hiring one more developer • Website design • Marketing and communication planning • Release 1 development • Metadata and object modeling 10
- 11. DLF 2012 11/4/2012 Development Team Northwestern University • Stu Baker, project director • Steve DiDomenico, scrum master • Stefan Elnabli, metadata/preservation specialist • Michael Klein, lead developer • Karen Miller, metadata analyst • Julie Rudder, product owner • Claire Stewart, product owner/director • Andrea Zielke, project assistant Indiana University • Jon Dunn, project director • Chris Colvard, lead developer • Phuong Dinh, developer • Julie Hardesty, metadata analyst • Brianna Marshall, project assistant • Mark Notess, product owner/manager • Nathan Rogers, developer 11
- 13. DLF 2012 11/4/2012 Release 1 • Expected in February 2013 • Goal is to support installation and piloting by partners • Functionality • File upload, transcoding & descriptive metadata: manual or batch • Batch loading via dropbox and tabular data file • Authentication and authorization – optional integration would require use of LDAP or some minor programming • Red5 and Adobe Flash media server support • Discovery via Blacklight faceted search & browse • Playback on desktop browsers & mobile devices (iOS & Android) • Basic monitoring & troubleshooting 13
- 14. DLF 2012 11/4/2012 Release 1 Pilot Support • Distribution packages • Both source distribution and some form of preconfigured package, e.g. VM image • Installation & configuration documentation • Email support • Advice on hardware & software requirements by Jan 1 • Goal: Small pilots/tests can be run on one server or VM; larger scale use may require distributing functions across multiple machines • Content & metadata from pilots can be migrated forward to future versions 14
- 15. DLF 2012 11/4/2012 R1 Architecture Avalon Media System Archival Storage Solution AuthN LMS, websites ILS Hydrant Rails App Hydra Head Black- light Ruby- horn Media Player (Matterhorn Engage) Fedora Solr Matterhorn Media Server (Red5, Flash) All Desktop, Mobile Browser, Drop box Search, browse, view media Ingest (batch or manual): video, audio, metadata Integrations Users Collection Manager Can- Can Omni- Auth AuthZ after R1 Avalon code 15
- 16. DLF 2012 11/4/2012 Authentication • OmniAuth • Multi-provider authentication middleware for Rails applications • Providers are known as “strategies” • Dozens of turnkey “provider strategies” including Google/Google Apps, Facebook, Twitter • Easily customizable “developer strategies” exist for CAS, LDAP, Shibboleth, OAuth/OAuth2, OpenID, Kerberos, and many others • As long as the provider returns an email address, Avalon will identify the user
- 17. DLF 2012 11/4/2012 Metadata for R1 • Descriptive metadata • MODS • Structural/content metadata • METS • Technical metadata • Will be a focus after R1 • Still looking at PBCore, for technical metadata and/or as an export format 17
- 18. DLF 2012 11/4/2012 Beyond R1 • Releases every three months • Workflow & batch loading improvements • Authorization improvements • Structural metadata for navigation • Playlists and clip making • Easy player embedding • Transcripts • Publishing out to other systems • More optimization for mobile • Focused accessibility work • We want to know what your priorities are! 18
- 19. DLF 2012 11/4/2012 Help with Requirements • Survey: – Media server – Authentication methods – Metadata – Media formats – Distribution packages – Importance of VM image Take the survey: http://tinyurl.com/AvalonWebinarSurvey 19
- 20. DLF 2012 11/4/2012 Participation • Try out release 0.5 http://pawpaw.dlib.indiana.edu/ • Try out release 1 in February 2013 • See what we’re up to via the project wiki: http://avalonmediasystem.org/ • Watch bi-weekly demos: https://wiki.dlib.indiana.edu/x/NxKKHg • Browse user stories, tasks & bugs in Jira: https://bugs.dlib.indiana.edu/browse/VOV 20
- 21. DLF 2012 11/4/2012 For more information • http://avalonmediasystem.org/ • IRC: chat.freenode.net #projectvov • Avalon e-mail list: E-mail avalon-l-subscribe@indiana.edu to subscribe @avalonmediasys facebook.com/avalonmediasys • Jon Dunn: jwd@iu.edu • Michael Klein: michael.klein@northwestern.edu 21
Editor's Notes
- #18: From F2F notes on the wiki (https://wiki.dlib.indiana.edu/display/VarVideo/Metadata+Decision+for+R1):Decision - MODS will be used for R1 for descriptive metadataBased on the following:Comparison between PBCore and MODS is fairly even for expected descriptive metadata elements in the system, but there is a difference in subject, where MODS allows for more explicitly-faceted subjects than PBCoreExample:pbcoreSubject = Silent films -- France -- 20th centuryVSmods:subject mods:topic = Silent films mods:geographic = France mods:temporal = 20th centuryMETS is being used for structural/content metadata, for R1, which means PBCore would not have instantiations, only descriptive metadataPBCore without instantiation is kind of pointless MODS is still recognizable and usableMODS can definitely happen for R1PBCore is something that can be created and added to the system later and is not necessary for the system we're building (at least in R1)Gives us more time to work in PBCore for technical metadata purposesOther metadata besides PBCore might be better for technical metadata - talk to partners about that; AES standards have better audio technical metadata but not necessarily video - requires investigationMODS allows for a language to be associated with an intellectual objectPBCore only allows a language to be associated with the instantiation so the intellectual object in PBCore would not be able to have any language(s) associated