Update Track documentation

Branch: master.

I can see that getTracks() has been deprecated in favour of getVariantTracks(). In both cases all the tracks returned are of type variant. However the Track documentation still indicates that the type should be one of video, audio, or text. Which is correct? The documentation or the code?

If you are thinking of moving away from listing the media type, then I think the current deprecation notice won’t be sufficient because for people who rely on the type as it is now, this change will already be a breaking change before 2.2 is released.

[joeyparrish]

In particular, we could have split up the audio and video parts of a variant, and we considered doing so early in our HLS implementation. We still stream the independently, so separating the streams themselves is not an issue. But splitting up variants to treat HLS as DASH caused issues with the ABR system.

We used to choose audio and video independently, but HLS only provides a bandwidth value for the combination. There was no way to split them up without making guesses about the proportions. We found that deducing the correct bandwidth for each was complex and we did not always have enough information to do it. Rather than potentially break ABR, we decided to change our internal structures to variants.

Expressing DASH in terms of variants is a trivial transformation by comparison. Unfortunately, those internal changes necessitated changes to our external track objects.

[TheModMaker]

The HLS manifest specifies a set of possible variants that the player can choose from. It does not allow switching between arbitrary streams. So when HLS specifies two variants with different audio and video streams, you can’t switch between all possible combinations, only between the variants that were specified.