Show HN: HTML5 Video Player in TypeScript
github.com
github.com
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.
- 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
Exactly, I also find it useful and get annoyed when I have to manually activate landscape mode on my device to get the player to use the whole screen (I have auto rotation disabled most of the time).
" This allows the use of HTML5 video to play back DRM-wrapped content such as streaming video services "
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.
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, ...
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.
Can you elaborate on this? I use <video> to debug HLS issues all the time. Is there something specific that straight-up video tag won't do?
If there are edge cases I'm sure I haven't seen them, because personally I'm only ever using HTML as basically a control group when reproducing bug reports from native video player stuff.
HLS Isn’t supported natively in a lot of browsers. Chrome doesn’t. It’s pretty easy to shim with Media Extensions so it’s fine to use but just sticking it as a src property in a lot of browsers it won’t work.
Personally I think that the Media Extensions API is going to be the primary mechanism for adding new codecs and transports moving forward as opposed to having the browsers need to implement all the options.
Try scrolling down to the player, entering fullscreen, hitting Escape, you're back to the top of the page.
The scale between y=0 and y=720 wouldn't have to be linear.
I haven't been able to find an exact match, but this overly-broad-yet-approved patent might encompass it, and the filing date seems to fit: https://patents.google.com/patent/US9069452
Edit: the state interface can be found here: https://github.com/matvp91/indigo-player/blob/master/src/ext...
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'.
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.