I agree with changing the syntax to html5 audio video tags - mainly because these allow us to support captions / text alternatives which is not really possible with the current media filters.

But in the interest of usability we should not deprecate or prevent the existing "link based" methods from working - many existing teachers will be trained to add videos this way and changing it will frustrate them. 

It would be great to build subtitle support directly into the Atto plugin which could store the text track as an additional file in the file area associated with the current text field (if it supports files).

core_media API was added by the OU because we wanted to use our own media player, and we are still using it. At the time linking in with theme renderer overriding was a simple way to achieve what we wanted to do. It was sufficient for our needs, and I guess the integrators were happy with it.

I have to looked at the detail of the existing discussions, but off the top of my head I would imagine a solution like this:

1. New plugin type for media players seems sensible.
   
2. Keep the core media API as-is, or try to only extend it in backwards-compatible ways. (For example, add new options to some methods so information about things like transcripts can be passed.)
3. Change how the API does its output, so that instead of (or on top of) the existing renderer code, so that it uses a new plugin type to output the appropriate player. That is, the body of each renderer method (only kept for backwards compatibility) would become
   get_player_plugin_for_content(...)->render_player(...);

I will try to point sam (who originally implemented core_media) at this thread.

Basically I am advocating option 3 from Marina's post above. I think we need just one filter_media that will act as abstraction layer between media html content (<video>, <audio>, legacy <a>) and Media API, which in turn:

• implements a new plugin type for media players;
  
• makes possible to clearly describe players-specific capabilities in terms of features and supported formats;
  
• provides unified process of embedding players from other areas of Moodle;
  
• informing other areas of Moodle of players features and current configuration;

I am re-posting my tracker response here, to keep discussion in one place. Below is the list of statements I made to support using new plugin type for media players, rather than using filters for that purpose:

I haven't spent enough time in the code lately to be as on-point as I should, apologies, but I would like to relate the issues I had when we needed a simple extension to the standard Moodle Flowplayer in order to play RTMP streams (campus server running Adobe FMS, now Wowza).

Having everything seemingly controlled by javascript-static.js (whether or not to load Flowplayer based on array element counts, loading one and only one player, etc.) meant I had to create a different filter, with its own YUI module.

So, yeah, providing for a render-time selectable player (to override a default) would be welcome.

Supposedly the selection of the player would be made by the the context laid out in the data- tags in the markup. Choosing between how the markup is generated and placed into the page, mod versus filter? Can't say right now.

But from the user's perspective, when they select a specialized media plugin from a list of (activity) resources, the context is laid out and it's a simpler to generate and render the needed markup: e.g. choose an .mp4 movie (repo hosted), we know what and where from the outset. With a filter, there's the pattern matching, then determining, what and where, and so on. Filters are problematic if the user doesn't enter the URL or other sought-out pattern in the correct way--so for filter_rtmp, we chose to create a repository plugin to take care of that for them.

So: media player plugin, yes; specialized media resource plugins, open to debate, but preferred over filters; on the browser, provision for using a JavaScript module supplied by the specialized media resource mod (via $PAGE->requires->js_init_call) that would select/extend the media player.

Marina, while our filter is obviously not a theme, we did have to override the core_media_renderer, so thanks for that heads-up. 

Having made several filters that produce media players from links, there are two observations that I would make. The first is that virtually every media player that I am aware of does not require a jot of backend code (ie PHP). The second is that media players are an area that users want flexibility. 

backend / frontend

In the VideoEasy and PoodLL (ver3) filters most players occupy between 2 and 30 lines of JS, and load a CSS and a JS file. What happens in php is the parsing of html elements on the page, version handling and the settings page. Actually the parsing function is so generic that it should be centralised into a core api. 

Last year or earlier I proposed a different solution and went as far implementing a prototype which I just kept on at. That is VideoEasy and it uses a template of CSS/JS/HTML per player. The template is editable in the admin settings interface of the plugin.

It works great.  There are templates for VideoJS, Flowplayer, MediaElement.js, JW Player as well as some original players that users write themselves to solve their own needs. I have yet to see a player that a template couldn't be made for.

So sure we could make a new mediaplayer plugin type, but it would be almost exclusively front end code. VideoEasy templates are around 2-5kb each. 

Flexibility

The ability for admins/teachers to edit, copy and share templates is a factor I think that has not really been considered in this discussion. One user (Adam Murray) wrote and submitted a 3 speed audio player (slow normal fast) written entirely in the admin settings interface. And how about subtitles? Some sites like their subtitles on the screen, just like the movies. Other sites use interactive subtitles below or beside the player that highlight and can be used to navigate through the video. 

I think we should get away from thinking about decisions like "flowplayer or jwplayer" and more along the lines of allowing users to create "players" that match their needs. That might be the outright creation of new players. Or it might be 3 different flowplayer templates with sets of settings appropriate to the way they will be used. 

The major weakness of the template system in my experience is that there is no nice settings interface per template. The admin has to get into what looks like code. But if we could solve that, we could give the Moodle developer and user community a much better ride. (And ...  I might add .. VideoEasy is already most of the way there, so that saves someone a lot of work ...)

I've thought about this a bit more now and I see a few issues with the 'ditch core_media and just use filters' approach, but they are not necessarily insurmountable. Anyhow here is a rather tl;dr brain dump about it

1. If we use filters then that means every filter has to reimplement the necessary regular expression matching. (OK this might not be a big deal for players that just annotate the video/audio tag but for anything that works similar to current media plugin, this is complex.)

This is important because what you're really saying is that we will have a defined input format (as we kind of sort of halfway do at the moment) and then a whole stack of independent filters will deal with it. So we should have a defined shared way to match it.

Proposal: Go ahead and use filters but put code for detecting and replacing all the media in a text (along with all options, subtitles, etc.) into a separate class in core. So filter_media or its replacement becomes basically a thin wrapper over this class with a callback to slot in the actual media player (or just stick a class in and load some javascript). And you can easily copy this for your custom filter.

2. Including media from a plugin (not in user-entered text) by doing html_writer::tag('video') is hacky and means all the plugins have to do the same hard work to figure out how to correctly include subtitles etc.

Proposal: Create a standard API for writing the HTML code for video and audio, which supports all the alternative formats, dimensions, subtitles, etc. as standard PHP parameters or class members or whatever it is, so that modules (resource/url/lesson/third-party) have a nice standard way to output media. I'd suggest this could maybe be in the same new class. Anyway, this can then even (optionally) wrap the format_text part so that you can just do echo \whatever\class::video($params) similar to the current API, and it will internally use filters, but who cares.

3. The filter mechanism doesn't provide enough information to configure media players. However, this is actually true of the current player mechanism too...

Proposal: Define a standardised way to include parameters for the media plugin, perhaps (just for example) as a specific type of HTML comment within the video/audio tag:

<!--filterparams:name=value,name2=value2-->

Alternatively it could be a data attribute which might be nicer. Anyway, this would then be interpreted by the input parsing API described above so that filters can easily access it. We could have a convention like if a parameter is some kind of generic one (for example to make a 'compact' version of a player) then it will be defined by Moodle, whereas specific parameters should begin with the plugin name.

4. The filter mechanism is a bit rubbish at supporting multiple players. For example, let's suppose you want to use two separate media player plugins - a regular one and a compact one; or you want to use one player for FLV and another player for everything else. If you just enable both filters it will probably screw up and try to filter things twice.

Proposal: Make a standard parameter (as per 3 above) called useplugin where you can specify a particular plugin name, and other media player filters will use this parameter to intentionally not filter that particular video. Also define make some standard for marking the output when a video HAS been processed so we can be sure it won't be re-processed, maybe as another data attribute such as data-filterplugin='myplayer' (obviously this is only needed in cases where the processing results in a <video> tag again).

So in summary I think Marina's preferred filter option is workable but I think we should clearly define the required input format (and where applicable some parts of the output format) for all filters that support media.

Regarding a defined input format, preferably using <video> and <audio> tags and  supporting the current link mechanism only for backward compatibility, I have a few comments based on our experience of this:

• With my accessibility hat on, this should include support for both subtitles and, ideally, audio description MP3 files. And probably transcripts (in various arbitrary formats) too.
  
• This should also support a way to specify a 'poster' image (the image, usually a jpg, that appears before it loads the video rather than a black box).
  
• Whatever element is used for giving subtitle files, it would be nice if there is some mechanism for supporting alternative formats (i.e. if Moodle only supports one format, like whatever the W3C one is) - here at the OU, we have a lot of material using a 'legacy' subtitle format so our media player supports this. It would be good if we could use this in a niceish way in the new system. (One option would be to use the 'parameters' thing I described above with a custom parameter for our filter.)
• When specifying dimensions this should be clearly defined as the video dimension and not the player dimension (often these are the same but not always) so that it works OK when changing players. In other words if the player (filter) knows it has a 30 pixel control bar then it's up to the player to allow extra room for that.

I'd suggest that the input format should be a clearly defined subset of the video/audio tags (subset because it makes it easier for filters to handle) plus some extra stuff, as comments or data attributes or whatever, as needed to control the filters.

--sam

Take a look at the implementation of the media player in the WET-BOEW framework, developed by the Government of Canada i collaboration with the WET community, which places an emphasis on accessibility and multiple language support.

You can start learning about and viewing the documentation and source code by visiting the WET- BOEW Multimedia Player Working Examples page for the media player at:
https://wet-boew.github.io/v4.0-ci/demos/multimedia/multimedia-en.html

The benefits of this approach includes:

• WCAG 2.0 Level AA accessibility compliance
• Support for multiple languages
• One plugin to support both video and audio
• Support for 2 video formats: MPEG4 (H264+AAC), WebM (VP8).
• Support for 2 audio file formats: MP3, Ogg Vorbis.
• Supported closed captions sources: Timed Text Markup Language (TTML), HTML5 Data file and HTML5 Inline Data. 
• Support for YouTube: Although you can embed a YouTube video in a page, using this player enables your YouTube videos to match the common look and feel of your site for a consistent UX.

"the multimedia player leverages the native HTML5 video tag and relies on Flash as a fallback mechanism when the HTML5 video tag is not implemented. The MPEG 4 format (H264 codec) is the minimum requirement for video because the Flash fallback relies on it and H264 is the standard video format on many mobile devices. An optional but highly recommended Webm (VP8 codec) should be added as well to allow some browsers such as Firefox that do not include native support for H264 to leverage the native HTML5 performance gains. The multimedia player's timeline relies on the HTML5 progress element and uses a polyfill when the element is not supported."

Open source code is available on GitHub under the MIT license.

I believe it should be possible to do something similar as a Moodle Media plugin.

Hope this helps.

Best regards,

        Michael