Media players

This page will provide an overview of the digital object media player(s) supported in AtoM, which are used to allow users to play access derivative copies of streaming media such as video and audio files in the browser. It was first created on 2018-11-23, and is current as of the AtoM 2.4 and 2.5 releases.

The current media library, Flowplayer, was implemented in the 1.0.8-beta release. At the time, Flowplayer was a flash-based video player (version 3.1 of Flowplayer was released in April 2009), and version 3.1.5 was added to AtoM in August of 2009, and included in the 1.0.8 release. See development ticket #2187 in the AtoM issues list for further details.

Since the initial implementation of Flowplayer in AtoM, no major upgrades or changes have been made to AtoM's time-based media playback functionality. Meanwhile, increasing discoveries of security vulnerabilities and zero-day exploits in Flash have led an increasing amount of browsers and platforms to disavow Flash support, starting as early as 2010, when Steve Jobs stated that Apple would not allow Flash on the iPhone, iPod touch and iPad – citing abysmal security as one reason (source). Since then, with increasing security problems being discovered in Flash and the arrival of HTML5 (which supports native video playback), most major browsers have chosen to disable Flash by default.

Flowplayer itself has redesigned its media player and while they do still maintain a Flash implementation, future development efforts have been focused on an HTML5 version of the player. Support for version 3.1.5, which AtoM still uses, has been discontinued for some time. The Flowplayer Flash version has not been actively developed since 2014, and the last major release was version 3.2.18. At this point, it is likely that support for Flash will be fully discontinued by 2020.

In August of 2018, Artefactual explored the current open source HTML5 video player landscape in search of a replacement candidate that met our requirements. We found the following page extremely useful in evaluating the best contenders:

After exploring the options listed in the site above, as well as any other popular options that met our criteria we could find, we found the following 3 players to be the closest match to our requirements:

Of the above options, the Artefactual team felt that MediaElement.js would be the best fit as a replacement video player for AtoM.

First developed by John Dyer at the Dallas Theological Seminary and released under MIT license, MediaElement.js is a widely-used project under active development, built responsively with a unified API that can fall back gracefully to Flash, which includes ARIA screen-reader support, subtitles, chapters and playlists, keyboard control, and more. The look and feel is skinnable, it requires no additional Javascript library support, and can also support playback of videos hosted on YouTube, Vimeo, and DailyMotion. It also has a plugin ecosystem that can further extend functionality, such as adding basic Google Analytics support, preview on hover, and extended playback controls.

Artefactual has prepared initial development estimates for our community based on implementing MediaElement as the replacement for the current Flowplayer.

We selected the H.264/MPEG-4 video format for in-browser video playback due to it's broad support across desktop and mobile browsers and operating systems (e.g. Windows, Mac OSX, iOS, Android). AtoM currently uses the MP3 audio format for in-browser audio playback, which will remain unchanged.

There are a few administrative costs not included in the table above, which Artefactual would include in any formal quote prepared based on the estimates above. These include:

Additional deployment, testing, and administrative costs

Subtask

Notes

Estimate

Community support fee

A 10% fee we add to development projects that are included in public releases, to help offset the costs of Artefactual maintaining the feature through subsequent releases, writing documentation, managing bug fixes, and offering basic community support via the AtoM user forum.

$840

Test site deployment

Deployment of an instance of AtoM populated with test data, to be used throughout the development project for previewing the feature, and managing testing and feedback

$600

Q/A Testing

Quality assurance testing and analysis throughout the project to ensure the feature meets the deliverable requirements, identify and resolve any bugs, offer implementation improvement recommendations within the project scope, etc.

$900

Backporting, deployment, and maintenance

Backport the new functionality to a stable branch and either deploy it or make the code available to sponsor for local installation, and assist in running the derivatives regeneration task for current flash-based video derivatives

Given that the costs of sponsoring this development may be out of reach for some institutions who nevertheless would really like to see this updated functionality added to AtoM, we would like to encourage our community of users to consider ways in which the feature might be sponsored collaboratively.

Coordinating with many institutions with different schedules and availability, as well differing perspectives and feedback, can potentially add complications to a development project. In light of this, for Artefactual to be able to work effectively with multiple dispersed sponsors, we have outlined our requirements for managing such a project below.

1) Single point of contact: We require one institution who is willing to act as the project lead, and the main point of contact throughout the project. This simplifies the communication between our team and the sponsors - the project lead institution would act as the go-between with other sponsoring institutions to coordinate scheduling, testing, and administrative communication throughout the project.

2) Single point of feedback: Working with multiple institutions on a collaboratively funded feature can be challenging if we are receiving contradictory input during the testing and feedback phase of the project. Instead, we would ask that the project lead manage internal discussions among the sponsors during the testing phase, and again act as the single point of contact for feedback, so that any contradictions around design, ideal behavior, and change requests can be resolved prior to communicating with our development team.

3) Ideally, a single point of payment administration: Preferably, the project lead can process contributions from any other participating sponsors, so that Artefactual can supply and process a single invoice at the close of the project. We understand that this may not be possible for all institutions, and can explore alternatives with participating institutions if needed.

As with any major feature development carried out by Artefactual, the work will be included in the next major public release for the entire AtoM community to use, and will be immediately available in the 2.5 development branch in our public GiHub code repository. However, if the feature were sponsored collaboratively and all participating institutions wanted access to the enhancement prior to the next public release, there may be additional deployment costs for the participating co-sponsors, so Artefactual can assist in making the work available in a stable branch and deploying it for immediate use.

The prices included in the section above entitled "Costs not included in this table" assume deployment of the completed feature to a single institution. If co-sponsors wanted to access the feature prior to the next major public release and would like Artefactual's assistance in doing so, there will be additional costs, which we would handle on a time and materials basis for each institution. For institutions hosted by Artefactual, it would be possible to use support tickets to cover deployment costs.