Shaka Player: DASH and HLS through MSE, and the platform rows it grades untested

Adaptive playback with no plugin, built on two web standards

Shaka Player is a JavaScript library for adaptive media, and its whole approach is to stay inside the browser's own capabilities. It plays DASH and HLS without plugins and without Flash, relying instead on MediaSource Extensions for the media pipeline and Encrypted Media Extensions for protected content. On top of that it does offline storage and playback backed by IndexedDB, where content can be stored in any browser and the storage of licences depends on how much support the browser itself offers. The stated goal is to make adaptive bitrate video and audio easy to stream with modern browser technology, and the stated constraint is equally concrete: keep the library light, simple and free of third-party dependencies. Everything needed to build and deploy is said to be in the sources, which is why there is no companion runtime to install.

On older iOS the same API just hands the manifest to Safari

The iOS story is the clearest example of one API hiding very different behaviour underneath. Support for iOS 9 and above runs through Apple's native HLS player: the top-level API is the same, but the library sets the video element's src to the manifest or media, so it is dependent on the browser supporting the manifests itself. Newer targets get the real thing. MediaSource Extensions are supported from iPadOS 13, and ManagedMediaSource Extensions from iPadOS 17 and iOS 17.1. In the platform matrix this shows up as Native for Chrome, Firefox, Edge and Opera on iOS, while Safari is marked Y on iOS 17.1 and later. The consequence for an integrator is that a feature you verify on desktop can be missing on a phone, not because of your code but because the native player was handed the manifest instead.

The support matrix marks untested rows with footnote numbers

Rather than a single yes or no, the browser and platform matrix grades confidence, and the footnotes explain what each grade costs you. Rows marked untested are expected to work but are not actively tested by the team, which covers Firefox on Android, Chromium Edge on Android and Opera on Android. A separate grade covers devices that are community-supported and untested: LG WebOS, with official support still tracked as an issue, plus Hisense, Vizio, PlayStation 4 and 5, Titan OS and TiVo OS. Tizen is split by model year, with the 2017 model actively tested and supported and the 2016 model community-supported. Chromecast is different again, tested against the latest stable firmware, with both the sender and the receiver implementable in Shaka Player. So for the rows carrying footnotes 6 and 7, a Y in the Other column means community support rather than testing by the maintainers.

DASH covers in-progress recordings, HLS covers event streams

The manifest support matrix is small enough to read in one look and it is where format choice gets decided. DASH is marked for Video On-Demand, Live and In-Progress Recording, but not for Event. HLS is marked for Video On-Demand, Live and Event, and not for In-Progress Recording. So the two formats are not interchangeable: a dynamic VOD workflow recorded as in-progress works over DASH, and an event-style playlist works over HLS, but neither covers the other's case. If your stream type falls in the gap, the answer is not a configuration change. The project does offer an extension point for the format problem instead, a manifest parser plugin that lets you support custom manifest formats, which is a development task rather than a switch.

The unsupported DASH list is specific enough to test against

Most player documentation avoids saying no, so it is worth reading what this one rules out. Xlink is supported on load with resolve-to-zero and fallback content, but not with actuate onRequest, and Xlink dereferencing through MPD Patch is unsupported. Manifests without any segment information are out, tracked as issue 1088. MPD Patch cannot modify elements carrying a schemeIdUri attribute, and the supported patch cases are enumerated precisely: SegmentTemplate with $Number$, SegmentTimeline with $Number$ and SegmentTimeline with $Time$. Two more limits are easy to trip over: several trick mode tracks at the same resolution with differing frame rates or bitrates are not supported, and a timescale so large that timestamps cannot be held as JavaScript integers, past 2 to the power of 53, cannot be represented, which is issue 1667. Check your output against that list before you commit a stream.

The build runs a dated Closure Compiler and forked toolchain pieces

The build stack is visible in the package manifest, and it is pinned harder than most. The compiler dependency is the Java artifact of Closure Compiler at a dated build, 20260819.0.0, alongside Closure Library and Closure deps, with karma and jsdoc also coming from forks rather than the registries. Linting uses eslint 9 with the Google config pinned to a GitHub commit, plus a custom rules plugin loaded from a file path inside build/, which means the lint rules ship with the repository rather than from npm. The tree also exposes two uncompiled entry points at the top level, one of them for the transmuxer worker, alongside externs/, conditional/, ui/, demo/, test/, third_party/, docs/ and an app-engine/ directory.

shaka-player.uncompiled.js
transmuxer_worker.uncompiled.js

Consequence for a contributor: a Java toolchain is part of building the production bundle.

Three release lines were published on the same day

Shaka Player is versioned in parallel rather than on one line, and that has a practical consequence for which file you load. Three tags were published on the same day, v5.3.3, v5.2.16 and v4.16.55, all on 2026-10-29, which points at active maintenance of older lines rather than a single trunk. The up-to-date list of maintained branches lives in maintained-branches.md in the repository, and release automation is configured through a release-please config and manifest. The package manifest itself records version 5.3.0 and names Google as the author with three named maintainers, and the licence is Apache-2.0. What comes next is published as a roadmap in roadmap.md rather than as release notes, and day-to-day questions are covered by the community docs under docs/ alongside SECURITY.md and the contribution files.

Editorial conclusion

It fits teams shipping adaptive streaming on the web who want one library for DASH and HLS, no plugin requirement, and offline downloads through IndexedDB, and who are willing to read the footnote markers in the platform matrix before promising a device. It does not fit a project whose content hits the unsupported DASH list, whose TV target is one of the community-supported rows, or whose team needs iOS behaviour to match desktop behaviour exactly. Check four things first: whether your packager emits segment information your streams depend on, because manifests without any segment info are on the not-supported list; which iOS version your audience is on, since older iOS goes through Apple's native player; which maintained branch matches your browser floor, since three versions were published on the same day; and what licence terms the Apache-2.0 grant gives your organisation.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shaka-project/shaka-player on GitHub