Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Quality Controls #572

Closed
ScottAgirs opened this issue Feb 8, 2023 · 5 comments · Fixed by #734
Closed

Docs: Quality Controls #572

ScottAgirs opened this issue Feb 8, 2023 · 5 comments · Fixed by #734
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@ScottAgirs
Copy link

Which documentation could use some work?

  • mux-video
  • general mux-elements documentation
  • hls

🖊 Describe what you'd like to see a change in the documentation

HLS is great, but it feels a little odd that there is no way to natively select video quality. For example, if the content of the video is quality-critical, IMHO the user should be able to select the quality explicitly.

Currently, I have not been able to find a way how to enable the quality controls neither in mux-player-react nor make plyr work with Mux source :( This is a major pain point, and I hope that I'm simply missing something. Am I?

@ScottAgirs ScottAgirs added the documentation Improvements or additions to documentation label Feb 8, 2023
@gkatsev
Copy link
Contributor

gkatsev commented Feb 8, 2023

This is definitely not available yet. However, we're working diligently to create such a menu. Unfortunately, we don't have a timeline for that yet, but it's definitely a highly requested feature.

@aminamos
Copy link
Contributor

@gkatsev question related to this item: when the quality selector is released in the future, if someone selects a quality level above what their connection can support, wouldn't they have a "worse" viewer experience?

Example: someone wants to lock their resolution at 1080p, their connection can only reliably support 480p, as a result they would experience buffering...right?

@gkatsev
Copy link
Contributor

gkatsev commented Mar 14, 2023

@aminamos yes, theoretically, they could have a worse experience. It would depend on how much can get preloaded ahead of time (often not much with MSE, which is why offline download could be helpful, but that's a whole other 🥫🪱). At the same time, users often know that their internet isn't that good and expect the extra buffering for the higher quality.

@ScottAgirs
Copy link
Author

If I may, I'd like to add to this - while indeed it may require more pre-buffering/waiting which would result in a worse UX, I would argue in certain cases the trade-off is worth it when the ability to see detail is critically important, I'll spare y'all the list of use-cases that comes to mind. 😃

@luwes luwes added the enhancement New feature or request label Apr 5, 2023
@cjpillsbury
Copy link
Contributor

resolved by #734 (should be coming soon thanks to @luwes's valiant efforts, @ScottAgirs!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants