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
1 parent
e9f9758
commit 9c77ee0