[POC] Update Manifest structure to make HLS implementation possible

[peaBerberian]

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 PR:

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:

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 ids 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.