TL;DR we’re specifying product & technical requirements for an implementation of the video player in React! Please read our Approach memo and add your questions/comments by 1 March.
As many of you know, the video player is in need of an overhaul. The current video player cannot be rendered directly inside of an MFE, nor does it work as a “video preview” player inside of the Video Settings Editor. It is not possible to have video preview on the video uploads page with the current player. The current player is full of crufty code, including many settings and features rarely, if ever, used, which increases code complexity and maintenance burden.
Many members of the Open edX community have embarked on creating their own video player implementations to overcome deficiencies with the player in the standard Open edX installation. The work represented in this document will result in an editor that the community can coalesce around. The benefits of this are a community-supported video editor that everyone can agree should be used.
Our goal is to come to community consensus on the problems of the current video player and agree upon an implementation direction. We ask that you read our Approach Memo and Technical Specification document carefully. Please add your thoughts, questions, comments. We want to make a video player that works for everyone!
Please leave comments by Wednesday, 1 March. Thank you!
Hi Sarina,
I am writing here because i am not able to write there. I have done some research on video player. All the video player xblock uses Videojs one way or other. My humble request will be to you guys.
Please add support of HLS and DASH with DRM.
Resolution control of video
Video Language control multiple language of a course.
we also have to upgrade in video player android and IOS for the same. we have seen many user are complaining the same in mobile apps. User can download HLS and DASH videos encrypted in the device. These are my observations. I am really sorry if I gone to far
Hi Sarina,
I’m writing here because I also don’t have access to comment on the wiki (I have submitted a request through the link you provided Parvin).
I have recently worked on implementing a custom video player in videojs for my organization (Medality). We use Vimeo to host our videos, and we would be interested in seeing native support for Vimeo videos brought to the platform. We created a custom xblock to support Vimeo for our needs.
In our experience videojs’ support for Vimeo is less than ideal, we ended up having to build custom tech to support Vimeo based on videojs-vimeo which is outdated and looks to be no longer maintained. While we were able to create a player that meets our basic requirements, we are looking to migrate to react player in the future when we add more advanced functionality. We found that extending the functionality of the player forced us to introduce a lot of code in often hacky solutions, and that customizing the appearance of the player to match our theme was challenging as well. This was largely due to having to not been leverage our custom MFE’s design system, which I imagine would be mitigated by having the player rendered in an MFE rather than an iframe, but just from our experience left a lot to be desired for the developer experience.
As we are looking to move to react player in the future for our custom solution, we’re interested in why edX feels react player would be less suitable to achieve your accessibility requirements.
@Parvin_Kumar I will have to defer to @jmakowski and Brad about the features you request (HLS/DASH support, resolution control of video). If “DRM” means “Digital Rights Management”, I do not believe this open source project will be supporting it.
Does this mean that you’d like the person to be able to switch the whole course language if they select a video stream in a different language? For various reasons, I think that’s well outside the scope of this video player block change.
@emartus - your case is interesting. I don’t believe Vimeo has come up in our conversations about this video block. That’s not supported by the current video block, correct? So you are requesting for Vimeo support to be included in this block?
I would need to defer to @jwitt on questions of accessibility.
@sarina That’s correct, the current video block does not support Vimeo and I’m requesting support for it to be considered for this block as it would give members of the community more flexibility for where to host their videos.
This is a particularly interesting point. If we were to pick something like video.js we might find we make a lot of contributions to it which would resolve a number of other issues it has, but theming is a persistent quandary. However I’m not sure picking a React-based solution will necessarily solve this either, since an outside React-based project isn’t going to conform to, say, Paragon’s design specification.
However the current effort around design tokens might resolve that-- though we might need to contribute code to whichever player we pick if we want it to pick up theming. Otherwise we might still need custom compiled SCSS for outside components like this one. Thoughts, @AdamStankiewicz@xitij2000 ?
On Vimeo support in particular-- I think that adding support directly should be out of scope for the initial implementation, since that’s a significant feature addition and this project is already going to introduce a number of critical variables, but it would be a nice thing to add later, and I think it’s fair to suggest whatever player we use should be extensible to consume new hosts with sufficient plugins.
Out of curiosity, what about videojs’s Vimeo support was lacking enough that you needed to create your own custom block? Maybe it would be easier to get some community momentum behind improving it if we don’t end up picking a block that supports it well out of the box.
The design tokens project generates custom --pgn-* namespaced CSS variables. If we wanted the video player to be themed with Paragon’s color palette, etc., we’d need to have custom CSS/SCSS to override/customize the default styles provided by the video library’s default CSS (e.g., video-js.min.css in the case of video.js). In doing so, we could associate the relevant CSS variables from Paragon into the video player’s skin.
Looking at the documentation for video.js skins, it also looks like it creates additional <style> elements included in the HTML document’s <head>. To override those generated styles, we may need to generate our own style properties for the custom styles to take precedence. Here is an example of creating a custom skin for video.js: Skins | Video.js
Got it. I can see that this repo was updated 6 years ago, which I imagine is why you had to make your own fork. If we did go with videojs, is there any reason why you don’t think your custom Vimeo plugin would work with it?
Aside from that, if the theming changes for MFEs do end up working as described by Adam, would you still need to move players? What, other than theming, are you missing?
@sarina , is there an evaluation document from those who looked into accessibility that details what react-player is missing? I know they recommended videojs, but did they recommend it over react-player or did they recommend it because they knew videojs met accessibility needs, regardless of whether react-player also does?
As far as base functionality, I believe theming is the main constraint at the moment. In our current implementation do have additional functionality such as a custom auto-advance plugin and progress updating we are accomplishing with message passing from the iframe to our learning MFE. Many of the pain points we experienced around those would be alleviated by the proposed improvement of having the video player rendered in the MFE rather than in an iframe.
We do have some proposed features we want to bring to our video player in the future to enhance the learning experience for our users which we believe will be easier to develop using something like react-player over videojs. Our motivation being primarily to bring our player out of an iframe into the MFE and working with react components would increase our productivity over using videojs’ component creation methods.
I am wondering whether it might be possible to combine all of the features that cause forking in the video player xBlocks, to make a super-video player. I’m particularly concerned that if one video player has best-in-class accessibility features, the others won’t gain the same advantages. Appsembler created a modular video player in 2017 . Would it make sense to build off of this one (or at least the back-end modularity), and add in new front-end features to reduce the need for forking?
This is honestly not a question I know how to answer, as I don’t know the video player landscape or particularly the code very well. It sounds to me, as an engineer with 10+ years of experience, like a tall order - making one thing meet everyone’s requirements is often difficult or impossible. @dave if you’ve got a moment to consider this question, I’d appreciate your thoughts.
Also @Jeff_Witt did you see the question asking for documentation on how you did your a11y assessment? @Fox_Piacenti is looking to understand the factors that you use to choose videojs, and wants to understand the limitations of react-player.
@Fox_Piacenti I went looking for evidence of support for Audio Description, then confirmed the more ordinary accessibility conformance things that I expect to find in most players. I can’t tell if react-player supports Audio Description. Also the dependency on video.js is not clear in the npm docs so I don’t assume anything.
I think this is an interesting idea, but that it would significantly blow out the scope of the current project, and would be something we should consider for follow-on work after the base video player is in a saner and more modern place. Our short term goals are frontend modernization and backend cleanup while breaking as little content as possible.
I spent a little time looking over the docs for both videojs and react-player and it does look like videojs may be the best option based on features and maturity alone. It doesn’t look like react player would be able to meet the accessibility needs we’re expecting without significant code contributions. It’s possible there are undocumented capabilities to add in narrative tracks, but I think we probably need the more mature offering of VideoJS even if it’s going to be a bit out of our normal toolchain. As tCRIL noted in the document, the important part is being able to wrap it in React more than having it be implemented in React directly.
