Default Video component features and functionality for React.

[cjpillsbury]

Default Video Component

TL;DR

We will support official components etc. for standard HLS, DASH, and natively supported media mime types, but we need to decide what the "default" component should be for <Video/> - something simple and lightweight or something that comes with full support of (at least) these common media formats. The primary tradeoffs of each:

1. Thick (HLS + DASH + MP4 etc.) - Discovery and learning curve is simple; code size by default is is large
2. Thin (simple video element wrapper) - Discovery and learning curve is harder; code size by default is small

Background

In our current Tech Preview implementation, just as a POC, the <Video/> component is an interface-compliant wrapper around hls.js and also does not support mp4 playback. We also have a <SimpleVideo/> component, which just uses the <video/> tag under the hood. This status quo is obviously not what we're anticipating for any official releases (even alpha). However, we should figure out what we want the default <Video/> element to support and, conversely, how much code it should include (since small code footprints are among our top priorities with the new architecture).

video.js currently ships vhs (dash + hls supporting tech) by default, which was an intentional decision and a change from prior version where it was an "opt-in" tech. This reduced discovery friction for common use cases, but also added additional weight to the code footprint.

Additional context that may be relevant

1. It's at least likely (though not officially decided) that our default <VideoProvider/> will have support for the sorts of features that only make sense for HTTP Adaptive Streaming ("HAS") standards like HLS/DASH, e.g. different media tracks, different quality levels, live streaming, etc.
2. We should be able to take advantage of tree shaking in any build setup, so, even if a "thick" component is part of the main package export module, it shouldn't be part of a final build if it's not used.
3. My general impression is that it's uncommon for folks to use a mix and match of e.g. HLS, DASH, and MP4 in a single context. If that's correct, a "catch most" <Video/> component will almost always be overkill for a particular use case (this is one of our central goals/motivations for the new architecture).
4. There are discovery tradeoffs in either direction - either folks have to discover how to play particular content or they have to discover (assuming they notice) that their code is unnecessarily bloated
5. Regardless of this decision, we'll have clear/official component use cases for HLS, DASH, etc.

[heff]

Proposal:

• <Video /> is just <video> but works with our state provider, at least on the react side, maybe also create one for the html side (with a dash in the name somewhere)
• In the Getting Started docs a user will pick their source type, add a URL, or upload a file, and we'll help them pick their specific Media Renderer for the best overall performance.
• For simple examples where ease of use is needed (Homepage embed example?) or multiple types of source might be used (ex. end-user can supply a source) have <SmartVideo /> (name?) that can auto load the right renderer dynamically.

[cjpillsbury]

While I may press on some deets/examples, I'm on board with this general approach and it's consistent with out of band discussions/ideas. I'd still consider this a vote for (2), since this is still suggesting that <Video/> will be the "Thin" version. As per the callouts in the initial post, we're planning on supporting different (non-default) permutations regardless (though this is still good public feedback and mentions details that are worth calling out).