[ad_1]
When you consider how thoroughly open source has dominated everything from server-side infrastructure, to programming languages and frameworks, to just about every developer concern for the last 20 years — there are some domains you look at and are surprised to still see proprietary stacks and vendor lock-in like we’re stuck in the 90s.
Video is one of those domains.
Those of us over 40 remember those heady early days of the commercial internet when it seemed like every browser had its own plugin. You had Windows Media Player plugins, you had RealPlayer plugins, you had Quicktime plugins and more. As a user you were constantly bombarded with messages that you needed to download the latest plugin version. It was very fragmented and messy.
Then with the introduction of Flash, we finally had a single, unifying plugin standard that would work across all browsers. Flash was great for developers at that time because at least now there was a single plugin to write against.
But then HTML5 hit the scene, promising to bring video natively into browsers as a built-in functionality, and when Apple mandated HTML5 for iOS, that pretty much brought the whole industry over to HTML5 as the default media playback standard for the browser.
All these years later, video is still a stovepiped domain for developers
Behind every video stream on the Internet lurks a range of challenging technical problems. The video back-end handles concerns like transcoding, tradeoffs between file size, compute when encoding and compression. Even the simple process of playing back video on devices turns out to be not so simple: Android, iOS and every web browser are quite different. That’s why there are so many video infrastructure providers out there.
SEE: Windows, Linux, and Mac commands everyone needs to know (free PDF) (TechRepublic)
There are also many video player providers out there. Some of the general open source players include Video.js, jPlayer, MediaElement.js, Plyr and Clappr. Some of the JS-specific players include ReactPlayer, Videogular, Vue-core-video-player and Stencil-video-player. And then there are the proprietary players like JWPlayer, Bitmovin, Theo, Nexplayer and castLabs. Each has their own specific benefits and their own specific baggage.
Most challenging for developers: They are all closed ecosystems, meaning all these different player options are tightly coupled with specific playback infrastructure. In other words, you may start to customize on one, but you can’t easily translate that customization to another player. It’s easy to get locked into a single video ecosystem, and that’s not the spirit of the open web.
Media Chrome wants to set developers free
Mux is an interesting player in the video ecosystem. I covered earlier this summer when they unified all three major video formats (on-demand, real-time and live video) into a single API abstraction. Mux is to video what Twilio is to unified communications or what Stripe is to payments: Developer API-driven abstractions to domains that were once extremely burdensome to developers.
As Mux introduces its new Mux Player for developers creating video playback experiences on the web, the heart of that Player is really interesting. Mux open sourced Media Chrome and then built the Mux Player on top of it. Media Chrome is a front-end framework that lets developers use plain HTML and CSS to build player UIs on the web.
The breakthrough is how Media Chrome abstracts the user interface of media players from the back-end playback infrastructure, and gives developers the simple components-style workflow they are used to, for bringing media (video and audio) into their applications via plain DOM HTML without being tied to any specific playback architecture.
A game-changer for video, made possible by Web Components
The story of Media Chrome is actually the story of two open source efforts.
Media Chrome was built using Web Components, a browser specification introduced by Google that’s been under development for more than a decade, and it recently gained massive traction as a browser standard. Web Components essentially allows the re-use of custom elements with fully encapsulated functionality across any browser environment.
SEE: Linux turns 30: Celebrating the open source operating system (free PDF) (TechRepublic)
Web Components allowed Media Chrome creator Steve Heffernan (also the creator of Vide.js) to create media player components — play buttons, seek buttons, media controllers and more — that developers can invoke as plain DOM HTML elements, across all browsers.
With Media Chrome, the UI components are separated from the playback engine. This is a significant separation of concerns and it allows developers to build video player UIs without having to worry about the underlying playback technology. Video playback is a really interesting domain for front-end developers today, as live, real-time and on-demand videos are increasingly being brought natively into web sites and applications.
Aside from React, which is actively working to support Web Components, today pretty much every popular web framework works cleanly with Web Components, so it’s a really solid standard to bet on, and Media Chrome is a technology developers can confidently adopt knowing it will work across all modern web infrastructure, both today and for the foreseeable future.
A giant leap for developer choice in the video ecosystem
Video as a web medium has long been ruled by highly specialized video engineers who understand the many back-end considerations required to make video playback predictable.
But it’s reasonable to forecast that with open source breakthroughs like Media Chrome, video will follow a similar trajectory as the rest of today’s API-driven ecosystems, where developers will be able to choose the slickest front-end technologies they want to use to create custom video experiences on the web, while using API calls to invoke the back-end infrastructure that serves their purposes. That’s cool, and it’s progress.
Disclosure: I work for MongoDB but the views expressed herein are mine.
[ad_2]
Source link
