edit: my bad, I thought the project in the OP didn't use html5 video at all, I see how that it is a wrapper around it.
HTML5 video is only really simple if you want to just play MP4's with H264 encodings. For everything else you're going to want a wrapper to deal with compatibility checks, smoothing out cross-browser bugs, deal with ads, set up DRM, ...
Fun fact: besides FairPlay compatibility, HLS in Safari is way more annoying to deal with than HLS via hls.js in browsers that don't natively support it. Safari provides you way less information about what's happening stream/buffer wise, and if you work with HLS event streams you need a ton of hacks to make it behave correctly.
" This allows the use of HTML5 video to play back DRM-wrapped content such as streaming video services "
Noting that most player still use the video tag under the hood, but a lot of functionality has been pushed to the Media Extensions layer for different formats of video.
Using HLS with HLS.js or Dash with Dash.js is the "Simple" way of adding adaptive bitrate support to HTML5 Video tag for better performance. After that its your video delivery pipeline.
- Clicking the video should pause/play;
- Clicking the volume button on mobile when the volume bar is hidden should not mute the video, instead it should just show the volume bar;
- Interacting with the volume UI on mobile should reset the time until the UI hides, the UI hides while I'm ajusting the volume.
These are a few points I think should be improved, I'd love to hear others opinions on whether or not these make sense :)
Keep the great work!
1. Absolutely, it's on my radar.
2 & 3. According to me, the volume button seems off in mobile. I think I'll remove it completely on mobile devices, people are used to lowering the volume with the physical buttons (assumption). What do you think?
To facilitate mobile development of the library its probably the best approach, at least for now and you can revisit the issues later on :)
Mobile is (typically) a single mode application situation, as in, there's no need to control volumes of simultaneous applications separately. It would also be easy to argue that almost no-one needs that feature.
- Add possibility to watch the player on landscape mode even when this option is disabled in the device settings, I'm not sure it is possible but if so it would be a great feature :P
The scale between y=0 and y=720 wouldn't have to be linear.
Try scrolling down to the player, entering fullscreen, hitting Escape, you're back to the top of the page.
I think Plyr can be seen as a better and unified UI on top of a <video> element, while this is an extensible player 'framework'.
Edit: the state interface can be found here: https://github.com/matvp91/indigo-player/blob/master/src/ext...
In addition to other feedback in this thread, I'd also want the Volume icon to change: show muted state / volume level state without showing the slider. YouTube does this well.
Another thing is how extensions are dealt with here. In video.js, if you need DASH support, you'll add videojs-contrib-dash and dash.js. Together that's at least 500kB of JS extra. Even in Safari where you won't need any of those, you'll have to do some hacking to avoid loading that JS for no reason. In Indigo here, dynamic bundle loading is core to the extension setup. When reading a config there's a lightweight check to determine what library to use for playback (if one is needed at all), and it'll only be loaded when it's necessary. In Safari, where you generally don't need any libraries, nothing will be loaded. In Chrome, you'll load Shaka when you want to play DASH, and hls.js when you want to player HLS. Indigo makes that very easy (and a default), video.js makes it hard.
These are advanced problems though. You're not likely to hit these issues with video.js if all you do is play a simple stream without DRM and with one single ad provider. But the solutions to those issues that are a core part of this project actually provide benefits in all situations and make development easier, so it's a net win for everyone in the end.
A lot of the ideas we came up with made it into this project, and what Matthias did differently in this iteration (like adding Typescript and improving how you write extensions) look really good. You can consider this to be an alternative to video.js, for example, but with easier ways to build advanced extensions without having to fall back to pretty oldschool ways of doing JS.
Matthias' default UI for example is built in React, but there's nothing stopping you from not using his UI extension and building your own that works however you want. Because of the heavy use of Webpack bundle splitting, if you don't use the built-in UI React won't even be loaded, and that approach is core to how this is designed.
