Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[POC] Update
Manifest
structure to make HLS implementation possible
NOTE: This is just a background, low-priority, Proof-Of-Concept. It is not currently functional and is in the middle of its implementation, there's also no HLS code for now, only HLS-related ideas. Overview ======== This PR is a Proof-Of-Concept where I explore whether HLS playback can be natively implemented in the RxPlayer without sacrificing too much the RxPlayer code's readability. This is not the first attempt, but the approach here is different than previous ones. One of the core idea is to keep the RxPlayer API as is, and thus to hide all HLS differences in the RxPlayer code. We already thought of potential HLS compatibility when designing our v4, so there seem to be nothing in our API incompatible with HLS concepts. Also our core code is for the most part protocol-agnostic, so we presumably could keep, and profit from, most of our logic while playing HLS streams. However, this attempt completely changes our internal `Manifest` concept, especially the `Adaptation` subpart of it (which was equivalent to the concept of a "track"). Manifest hierarchy change ========================= The issue --------- One of the main differences between HLS and other protocols handled by the RxPlayer (such as DASH) is the concept of "variant streams" only HLS have. Basically in DASH, you first select your wanted audio + video + text tracks and then select a Representation (i.e. quality) according to your current playback conditions such as your network bandwidth. In HLS however, this is reversed. You first have to select your "variant stream" based on your playback conditions (mainly: network bandwidth) and then see which "media" - including our notion of a track - is available for that variant stream. Because of edge cases, we cannot translate the HLS model into our DASH-like model wihout losing some HLS features. Doing the reverse (adapting DASH model into HLS model, which seems to be what e.g. the shaka-player more-or-less did) could work yet it doesn't seem like an optimal solution (e.g. we would either lose some bandwidth information or creating a huge number of variant streams for all potential combinations). How I tried to fix it --------------------- So what I did here, was to change the Manifest object's hierarchy so it can adapt to both how HLS is treating thing and how DASH is treating things. The Manifest looked like this before this commit: ```ts type Manifest = { periods: Array<{ // Define a particular track adaptations: Record< "audio" | "video" | "text", Array<{ // qualities representations: Array<{ // ... That Representation's metadata }>; // ... The rest of that track's metadata }> >; // ... The rest of that Period's metadata }>; // ... The rest of the Manifest's metadata }; ``` Now it looks like: ```ts type Manifest = { periods: Array<{ tracksMetadata: Record< "audio" | "video" | "text", Record< string, // The track's id { // All qualities linked to that track representations: Record< string, // That Representation's id { // ... That Representation's metadata } >; // ... The rest of that track's metadata } > >; // Groups of available tracks and qualities combinations variantStreams: Array<{ id: string; // bandwidth for that variant, only defined for HLS, others have // only a single variant bandwidth: number | undefined; // Authorized tracks + qualities combinations in that variantStream media: Record< "audio" | "video" | "text", Array<{ // `id` the corresponding track in `tracksMetadata` linkedTrackId: string; // `id` list of the Representations' in `tracksMetadata` representations: string[]; }> >; }>; // ... The rest of that Period's metadata }>; // ... The rest of the Manifest's metadata }; ``` So basically in a Period, we'll now separate a tracks' metadata and the conditions in which we may play them: the former rely on `tracksMetadata`, the latter on `variantStreams`. Note that `variantStreams` only use `id`s to refer to tracks and Representations: it does not contain the metadata directly. This is to avoid having to repeat a track's and representation's metadata already present in the `tracksMetadata`. We cannot just rely on a same-object-reference trick because the Manifest object has to be able to be transmitted through the worker and main tread. Worker compatibility is also the main reason why we're not relyng on `Map` objects to link ids and metadata, though it may seem more logical. This new structure allows to enforce complex HLS features, like restrictions on which tracks and qualities can be played when another unrelated track is selected. Here incompatible tracks would never be present the same variantStream. Though it is very clear that it adds net complexity on top of our Manifest's structure, as those "variant streams" concept do not exist in Smooth or DASH. For Smooth and DASH, only a single `variantStream` will be present, with a `bandwidth` set to `undefined` (Representation-level `bandwidth` is still exploited by our ABR logic) and containing all tracks declared in `tracksMetadata`.
- Loading branch information