...

• Enhanced structural metadata editing—edit structure for a section visually
• Import of structure within media files (such as WAV cue points) upon ingest
• Performance improvements for objects and playlists with large numbers of items
• IIIF Manifest generation from media objects

Release 7

Our goal with Avalon 7.0 is to offer a full-featured media streaming application based on the modern Samvera stack. To this end, Avalon 7 will be built using Hyrax as a base, offering developers an environment they know and understand, and offering administrators the flexibility to run stand-alone streaming solutions or integrate scalable streaming into existing Hyrax-based applications. As we work toward full-feature parity with Avalon 6, we will continue development and support. Each dot release milestone is estimated to be an 8-week work cycle.

0.1 (Github Milestone) - Using the Avalon Media Player Within Hyrax and IIIF 3.0 Generation and Consumption

The Avalon player will be embedded in a Hyrax app and be initialized with a IIIF manifest generated dynamically from item metadata. In addition, the Hyrax generic work type will be extended minimally to allow for a work to contain necessary technical metadata.

• Core media types (audio and video) can be ingested, transcoded, and attached to a Generic Work.

• IIIF Manifest generated for consumption by player

  • IIIF gem used in Hyrax updated to generate IIIF Presentation API 3.0 manifests (possible collaboration with community)

  • Necessary technical metadata added to Generic work for IIIF manifest (upstream)

• Media player consumes IIIF manifest generated by the application from the work's metadata

• Player streams media (basic http streaming or from specific streaming server)
  

• Development, testing and infrastructure needs for Avalon 7 development defined and in place
  

0.2 (Github Milestone)

This preview will further refine the IIIF Player, auto-generate IIIF manifests based on an Avalonish -work type metadata, and begin discussion and sketches for a branded hyrax-based Avalon solution bundle. Structural metadata will be ported over as is for use in a IIIF manifest.

• A Media Work type in Hyrax is created to store descriptive metadata and technical metadata. Metadataists work on descriptive metadata for the Avalon work type
  • Order of masterfiles is necessary metadata
  • Order of multi-valued pieces of metadata will wait until later
• Player consumes IIIF manifest generated by the application (media work type)
  • Time can be navigated via structural metadata
  • Port Structural metadata (structure within) as current XML 
• Dynamically generated IIIF compliant manifest generated from Media Work type
  • We intend for the manifest to be a central point of interoperability
  • The manifest will be based on the current IIIF-AV 3.0 standard
  • Manifests will be generated based on technical and descriptive metadata
  • Manifests  should ideally use the same endpoints as Hyku (possibly the same generation tool)
  • The manifest contains the structural information, The display should exercise the manifest. 
  • Structural metadata will be stored in XML and crosswalked to the manifest
  • Metadata experts talk through what metadata (descriptive or any other kind) to include. There is already an issue for the recommended descriptive metadata. Need to take a deeper look for technical metadata. (https://github.com/avalonmediasystem/avalon/issues/1772)(https://gist.github.com/jlhardes/1e3adada7410591f46b170e65dce20af)
• Investigate Matterhorn alternatives
  • Matterhorn gives us the nice interface for monitoring
  • Hyrax may suggest a monitoring interface for job queues
  • Exploring how from a collection manager/depositor perspective: if there are issues, how does that get resolved?

0.3

The goal of this cycle is to continue refinement of our media work type while developing our streaming/derivative generation pipeline. UI/UX work will begin, and we will deliver initial mockups. Work on the standalone player will continue. 6.4.3 will be cut as a bug fix.

...