Read our blog
(Last week we noticed that the Duke Digital Media Community featured Avalon in a blog post. Though they don't plan to implement Avalon at this time, we were very happy that they took the time to write about how they made this decision. Since our response might help other potential adopters of Avalon, we wanted to post it on our site.)
The Avalon Team is happy to see you take notice of our work! You are quite right that we are not targeting the YouTube-style end-user upload use cases, and Kaltura-killing is not on our to-do list. Nor are we trying to compete with MAM/DAM systems, where the focus is on managing content for internal use by media-generating organizations.
The needs we are squarely focusing on are those of libraries and archives, whose needs are not well met by any of the open source solutions available today. Neither are they well met by more than one or two expensive commercial systems. It has been a major activity of our work to explain to IT organizations why library and archive needs are not addressed by the kinds of media solutions initially adopted by campuses. In what ways are these needs not well met?
- Metadata for the long haul. Although we are planning to rework our content ingest process to provide a better manual workflow, part of the reason all the steps are there is that library content, unlike the latest video from a cell phone, needs to be discoverable and accessible for a long time. Most course lectures and assignments tend to be ephemeral in nature rather than needing to be reliably found and viewed ten years hence. Of course some user-generated content does merit long-term preservation and access, but when it does, the content ends up having metadata requirements similar to any other curated library content.
- Metadata for navigation. Most of the generic streaming media players simply provide a scrubber for navigation, on the assumption that most content is short. This doesn't work well for longer items such as operas, ballets, plays, or feature films. Adding structural metadata for chapters or tracks helps considerably.
- Flexible access control. Academic libraries and archives provide content under a wide variety of access control schemes. Rights differ across materials. Rationale and risk assessments differ across institutions.
- Security. Most streaming media systems either have no security or security by obscurity. Avalon is being designed to support delivery of highly sensitive content, whether for reasons of intellectual property protection, cultural sensitivity, human subjects protection, or other privacy concerns.
- Integration. Avalon aims to integrate with pre-exisiting digital object repositories (such as Duraspace's Fedora) and enterprise media servers (such as Adobe's). Although many systems do integrate with institutional authentication and authorization, other integrations, such as with library catalogs for automatic import of descriptive metadata, or support for course reserves, are found only in systems that grow up within library environments.
So these are some of the distinctive needs Avalon aims to address with a freely available open source system. That said, we know Avalon will be used for scenarios beyond those we are intentionally addressing, and Avalon will likely be useful in ways we do not currently imagine. The Duke evaluation raises some good points and also identifies information gaps we can address here.
- The manual upload sequence of pages is indeed clunky, though we find people are able to be successful with it. We are planning to revise it, with the aim of making simple things simple and hiding optional complexity. But it is also worth mentioning that we expect most Avalon content will not be uploaded manually. We have a batch upload capability we expect to be the primary means of adding content: collection managers will put the master (or mezzanine) files on the server, along with a descriptive spreadsheet. Avalon then automatically ingests and processes the items and can even auto-publish them. Of course, this feature is more helpful for libraries and archives than for an individual submitting an assignment or example.
- Many institutions, like Duke, are looking for hosted solutions. For that reason, we are being careful to avoid licensing encumbrances (such as GPL) that would deter third-parties from picking up Avalon and offering it as a service. We expect one or more third-party providers to provide application hosting and related services, but it's a little early to start recruiting them.
- Player embedding is on our list of development priorities for early next year.
- Regarding Shibboleth, Avalon uses a Ruby gem called OmniAuth for authentication, and therefore supports several dozen authentication strategies with a minimum of implementation and configuration required to set them up. The difference between the default "identity" strategy and full integration with Northwestern's LDAP directory, for example, consists of 8 lines of code and a 10-line configuration file. IU's CAS integration is slightly longer at 23 lines of code and 10 lines of configuration, but only because it has to do a secondary LDAP email lookup after login. There is a third party, well-documented Shibboleth strategy available for OmniAuth, and it looks just as simple to configure as the ones mentioned above, with the addition of one stanza of Apache auth configuration.
- Thanks for pointing out we missed listing wmv in our supported formats. We’ve now updated that document to be current. We use HTTP live streaming to support iOS devices.
- We haven't yet tried or prioritized Wowza integration.
- The Engage player can be slow to start up. For this and other reasons we are investigating switching to mediaelement.js as our player of choice.
- The test site upload limit is due to disk space on the test server. We have been testing the system with files 50GB and larger, though not, of course, through the web browser. That's what the Avalon dropbox is for.
- We are currently implementing "collections", which will provide something equivalent for "my media", enabling collection managers to view their own collections (and preventing them from modifying collections for which they do not have editing privileges. Even in the existing system, "collection" is a facet you can filter on.
Finally, we’d like to point out that we have only recently release version 1.0 of Avalon. We have releases scheduled roughly every three months, so we are early in the development process and welcome input and evaluation such as this as Avalon makes progress.
Thanks again for the helpful review!
The Avalon Team
This week the team worked on adding new functionality to Avalon. We introduced the concept of units to Avalon Media System. The term "unit" refers to an Administrative Unit, which can be made up of many collections and items. We also added some snazzy auto complete features to select unit managers. Besides units, more investigation of the mediaelement.js player occurred during this sprint. IU and NU spent some time getting their pilot systems set up. We're just about ready to see what Avalon 1.0 can really do!
On Wednesday, May 29, the Avalon team hosted a community webinar. With around 50 participants and no technical difficulties, we consider it a smashing success! Thanks to all who joined us.
We would also appreciate it if you would take our brief survey. We're trying to learn about the community's plans and current practices to help shape future releases of the Avalon Media System.
After releasing Avalon 1.0, the team spent some time cleaning up our code and investigating some future changes to Avalon, including looking at alternative player options and other ways to handle group management. If you have any feedback about what functionality you want to see in future releases, please join us at next week's webinar!
Click here to watch the full recording of this week's demo.
- Player Investigation (VoV 1543) - Phuong (0:00:00)
- Hydra Group Management Investigation (VoV 1577) - Chris (0:10:32)
- Future Releases and Bug Fixes Path (VoV 1446) - Michael (0:19:23)
- Rails Best Practices (VoV 1549) - Chris/Adam (0:32:07)
- Review of Sprint Stories – Team led by Steve (0:35:26)
We're looking forward to talking with the Avalon community about our recent 1.0 release--and we hope you'll join us! This will be an ideal time to familiarize yourself with 1.0, ask questions, and provide feedback to the team. We will record the webinar for later viewing by those unable to join us.
To receive connection information for the webinar, please fill out our registration form: http://tinyurl.com/avalon1-0
Date: Wednesday, May 29
Time: 12:00-1:00 PM EDT
- Overview of version 1.0 functionality and the download/tryout options
- Demo of version 1.0
- Roadmap and schedule for planned future releases
- Questions and feedback from participants
Throughout the process of working toward release 1.0, developing effective documentation was just as important to the team as developing effective code. The Collection Manager's Guide describes features, functionality, and how to navigate the Avalon Media System.
This guide will be most useful for the individual who had already downloaded release 1.0 and wants to understand more about the following aspects of the software:
- Logging in, browsing and searching
- Player and controls
- Creating, editing, previewing, and deleting an item
- File management
- Resource description
- Access control
- Group management
We hope the Collection Manager's Guide will help collection managers become more comfortable using release 1.0. If you have a question or suggestion for improving this guide, please contact us or share your ideas on avalon-discuss-l.
In our new series "Get to Know the Avalon Team," we're providing a closer look at the individuals who are working each day to develop the Avalon Media System.
Chris is the lead developer on the Avalon project at Indiana University. Previously, he worked on the Variations Digital Music Library leading to its being open sourced with over a dozen institutions adopting the system. Chris graduated from DePauw University and has worked for the Digital Library Program since 2006.
Can you talk a bit about your role in the project?
I evaluated technology choices for the Avalon planning grant. With the current grant, I developed a prototype and set up the testing environments while the other developers were coming on board. Now I continue to manage some of the testing infrastructure and am often a point person for developers at IU. When programming, I float between all parts of the code but tend to focus on Matterhorn and the backend.
What is a typical work week like for you?
What apps/software/gadgets can't you live without?
None ideally, but I really love my record player and FM radio.
When you’re not working, what can you be found doing?
Living and learning with my wife and three kids. Learning about and trying to be a part of the Catholic Worker Movement. Cooking, volunteering, and watching Anime and Korean dramas.
Release 1.0 of the Avalon Media System is now available for evaluation and pilot. The release includes the following features:
- Secure delivery of video and audio to desktop browsers and iOS (iPad/iPhone) devices.
- Implementation as a Hydra application to provide easy search via the Blacklight discovery tool and integration with a Fedora repository.
- Support for both Adobe Media Server and the Red5 open source media server for audio and video streaming.
- Integration possibilities for a variety of authentication systems, along with permissions management by user- or group-based authorization.
- Manual media ingest and description and a dropbox-based batch import capability.
There are several options for exploring release 1.0. You can try it out on our public test server. You can also download and install a preconfigured Avalon virtual machine image, perform a step-by-step installation, or find out how to download our source code from Github.
If you plan to try out or download Avalon, please sign up for the new email list, avalon-discuss-l, to get technical support or provide feedback. If you are not yet signed up for our main announcement email list, please sign up for avalon-l.
We will be scheduling a webinar within the month to provide a 1.0 demo and give the community an opportunity to ask questions and offer ideas.
As you can see, the Avalon team is so excited to share release 1.0 that we donned crazy hats at our most recent face-to-face meeting!
This week the team refined the various methods to download or try out Avalon Media System and cleaned up the documentation. We have our demo server up and running with Avalon and enough content to make it interesting!
Click here to watch the full recording of this week's demo.
- Updated Demo Server (VoV 1324) and Content (VoV-1500) - Chris (0:00:00)
- Avalon R1 System Requirements (VoV 1192) - Julie (0:11:26)
- Location/Documentation of Downloading Options (VoV 1506) - Mark (0:14:04)
- Documentation for Installation, Configuration and Usage (VoV 1501) - Mark (0:22:21)
- Previously Demoed – Avalon VM (VoV 955)
- Review of Sprint Stories – Team led by Steve (0:35:23)
VM images, content and licensing, oh my! The release candidate is just about ready to be shared with everyone. Final tweaks and testing are happening! If you want to see the stories that we are working on each sprint, check out the current sprint page on our wiki.
Click here to watch the full recording of this week's demo.
- Avalon VM (VoV 955) - (0:00:00) - Brian
- Demo Content (VoV 1272) - (0:16:08) - Chris/Phuong
- Licensing (VoV 1444) - (0:21:53) - Nathan/Claire
- Publicly Accessible Sprints (VoV 1445) - (0:30:22) - Andrea
- Path to Release (VoV 1367) - (0:34:13) - Team
- Review of Sprint Stories – Team led by Steve (0:50:05)