Quality selection UI for audio-only content

[joeyparrish]

Have you read the FAQ and checked for duplicate open issues?
Yes

Is your feature request related to a problem? Please describe.
In the default UI controls, audio-only content gets a language menu, but not a quality menu (equivalent to the resolutions menu for video content). Although the variant tracks API will allow the choice of quality level for audio-only, the default UI doesn't expose this.

Describe the solution you'd like
We should add a new overflow menu item for audio-only content, to allow the selection of a specific bitrate.

Describe alternatives you've considered
We could always leave it up to audio-only apps to register their own button for this, but we could easily make the UI more usable for audio-only content.

Additional context
Idea based on feedback from @vickymin13. Thanks!

[mbvenu]

Hey @joeyparrish any update here in 2021 ?

[michellezhuogg]

Hello @mbvenu, we haven't got time to add that yet. I just marked it as "contributions welcome" to see if anyone is interested to work on it :) Thank you!

[ismena]

This might also be a good gsoc issue if anyone's interested.

[nbcl]

Hello, everyone!

I approached the issue by introducing the quality selection to the currently existing resolution button in the UI, conditionally, when audio-only content is being displayed.

tracks = tracks.filter((track, idx) => {
  // If audio-only content is being displayed
  if (this.player.isAudioOnly()) {
    // Keep the first one with the same audioBandwidth.
    otherIdx = tracks.findIndex(
        (t) => t.audioBandwidth == track.audioBandwidth);
  // If video content is being displayed
  } else {
    // Keep the first one with the same height.
    otherIdx = tracks.findIndex(
        (t) => t.height == track.height);
  }
  return otherIdx == idx;
});

This replaces the resolution menu with an audio quality menu when audio-only content is displayed, but I have a couple of questions.

Are there any downsides to this design or should I reiterate by directly creating a new button that should only handle audio quality?

Also, is using the .audioBandwith attribute the correct approach to obtaining the bits/s, or am I mixing concepts together here?

I left my approach on a draft at my personal fork @draft:feat-2071 as a working proof of concept! 😄

[joeyparrish]

You should use bandwidth instead of audioBandwidth. HLS doesn't give us separate audio and video bandwidth numbers, so audioBandwidth may not be present in all cases. (DASH content is more explicit.) For audio-only content, bandwidth and audioBandwidth should be the same anyway.

I haven't reviewed your draft in detail, but in sounds reasonable. Thanks!

[nbcl]

Thank you for your review and comments on the draft!

For audio-only content, bandwidth and audioBandwidth should be the same anyway.

This was so obvious now that I think about it, if no video is being played, of course there is no videoBandwith, then bandwidth and audioBandwidth should be exactly the same, and clearly, bandwidth is preferred.

Anyways, I implemented the changes - Reiterated to bandwidth and fixed the declaration problem with a conditional operator.

Updated the draft @draft:feat-2071!

[joeyparrish]

Great! Please take the PR out of draft and let us know when it's ready for a more thorough review. @ismena should take a look for UI, or I can take a look if she's busy.