editor(plugin-video): allow native html5 video media types

[oellers]

Current state

• Supports YouTube, Vimeo and WikimediaCommons media sources

Goal

• Allow native html5 video media types
  • video/mp4
  • video/webm
  • video/ogg

Draft

• POC commit: ee5d5ea..., not ready for a PR

Discussion (UX)

• Currently, media sources from youtube, vimeo and wikimedia commons are validated by regex;
• There are several challenges with validating arbitrary remote urls

How can remote media types be validated?

1. Extension validation (soft validation) Url indicates a typical media extension type (e.g. .mp4, .webm, .ogg for html5 video elements). Disadvantages:

   • No real validation of media type
   • Other URLs serving media would be invalid (if this is the only type of validation); workarounds by suffixing with a valid media type, e.g. in the query parameter (bad ux)

2. Header validation Retrieve the content-type response header from the URL. A (cors) request to get the headers of the URL could be initiated. Disadvantages:

   • A frontend request will only work based on regular CORS restrictions (appropriate Access-Control-Allow-Origin headers), there's a good chance this won't work in most cases.
     • Alternative: Headers could be validated with a backend proxy route, e.g. compared to mathpix proxy, but this would introduce cross-origin dependencies

How do others deal with this situation?

H5P

• h5p tries to [determine the mime type based on the url (basically validating the "extension")
  • by regex \.(\w+)$ within the html5 video
  • by url.match(/\.(webm|mp4|ogv|m4a|mp3|ogg|oga|wav)/i); within the h5p editor
• h5p has a fallback mime type for html5 players: video/unknown that is set by the h5p editor; in this case it simply tries to load the video anyway and listens for media errors on the video player (MEDIA_ERR_SRC_NOT_SUPPORTED)

Conclusion

• Since the above validations (1+2) are pretty much limited (except for the backend proxy route), no URL validation might be "sufficient" at this point. Compared to the h5p solution the video player could simply run into the Media error MEDIA_ERR_SRC_NOT_SUPPORTED if source is not supported

Follow up question What are the opinions of the Serlo maintainers on that matter? I could prepare a PR based on the decision.

[elbotho]

Thank you @oellers for your super thorough suggestion! We will talk about it next week and get back to you.

[kulla]

Thank you @oellers for the issue + PR. It shows that integrating video files will be easy to implement. Currently we are planning a new plugin for interactive videos (see https://2024-09-06-demo-interactive-video.vercel.app/). For this we need to change our video player anyways since we will need one which support chapter markers (do you know one)? Then we plan to work on this issue as well and to add support for native html5 video files.

[elbotho]

Also a quick question @oellers: Do you have examples / use cases where those files would be hosted? It also has upsides for us to restrict where videos can be embedded from.

[oellers]

For this we need to change our video player anyways since we will need one which support chapter markers (do you know one)?

Like WebVTT chapters? VidStack.io could be of interest. We used video.js, mediaelement.js and paella player for older projects.

You might also want to inspire yourself from our list of video annotation tools, e.g. in terms of features, that we gathered in the Opencast Annotation Tool Community Meetings.

Also a quick question @oellers: Do you have examples / use cases where those files would be hosted? It also has upsides for us to restrict where videos can be embedded from.

Literally anywhere (if this will be a generalized feature), that's kind of the challenge of validation here, unless you want to introduce some kind of custom allowlists for deployments;

Examples:
https://media.w3.org/2010/05/sintel/trailer.mp4 https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4

Edit: If you change the player, I'd actually would love to see HLS/DASH-Streaming as well =) (though the interesting part will be the stream authorization then for my specific use case)

[elbotho]

unless you want to introduce some kind of custom allowlists for deployments

Unfortunately due to privacy constrains we basically have to.