I want to give the concept I had in mind for making the quality switcher great:
With the current system, a 1080p - 30 Mbps option appears when I'm watching a 15 Mbps movie, which doesn't make any sense.
TLDR, the idea is to make the quality switcher simpler and common, like the one found in YouTube, Vimeo, etc... While still being useful for power users and the use case of a media server.
I guess this will need to wait for 11.0 once we have an stable API, but would be great to have as much input as possible for this.
As I state in my third point, nothing prevents us from adding options in the nerd settings to do that. I mention nerd stats without further ado and I haven't considered that readers of this thread might not know what they are
We already have a similar feature in Jellyfin as well. Nothing prevents us from adding a few fields there. Also, in the future, all the players will be able to handle adaptive media and dash (is a core thing to support if we want to have dynamic quality based on network connection).
What server determines will be the bitrate that the maximum option will offer. If you choose Auto, client will request a lower bitrate if your network can't handle it.
As mentioned in the original issue, server will determine a maximum bitrate value for each of the qualities. Good point about your example, because I didn't think that it also should determine a lowest possible value for each of the qualities. It doesn't make any sense to have 1080p at 1 Mbps for instance, there should be a range at which the Auto option in the quality switcher will force you to go to a lower res
The main point stated here is exactly how to solve the problem you're having: right now, we're far too reliant on you manually changing and tinkering into bitrates and stuff to get an smooth experience on unstable networks (like cellular). We are power users who enjoy playing with bitrates and this stuff, but there are some times that you just want relax wih your content and get things to work, without troubleshooting or trying different options.
YouTube, Netflix, Hulu... all of them are super reliable, no matter if you're commuting, jogging or at home. That's what would be great to have in Jellyfin as well.
Also, we now have a really large userbase, so everything we focus on getting things as simple and workeable as possible is better. Let's be real: most people de a pie doesn't know what terms like bitrate, codecs, container means. A quick dive on our issues will quickly make you realise how many people doesn't know the difference between a codec and a container. The more we can abstract this stuff to the end user so it works as good for them as for the power users, the better.
Pretty much everything said earlier with nerd stats.
As of now, I can't imagine having to type in a value to an input field (in a hidden nerd stats-like window) to select a bitrate on a regular basis... that would be horrible UX, even for a power user. I can easily explain to a relative that their internet connection is shit and that they should select 5 Mbps... once they know what it is, it's literally only 2 clicks to adjust.
Yes, exactly. I know what my network can handle so I know what to select. If I only had a generic 1080p option with a preset bitrate value, I would have to compromise either on quality (by selecting lower res.), or risk having to deal with buffering and interruptions.
That would be ideal. But until then, I see EASY (as in 2 clicks) manual bitrate selection as the only option. When we get to the point where dynamic quality/bitrate switching works seamlessly, I won't have an issue with hiding/moving the manual selector elsewhere.
But why do that when that relative will already have the best quality possible for the network without doing anything? Why make him remember that?
As a side note, input it's the best thing to have once we have a fully functional adaptive quality switcher, fixed values are not nerdy-friendly enough imo :).
Same as above
This discussion is here as the starting point for an RFC process around this. With our current codebase, we're too far from this approach, this might even materialize in 2 years and only after version 11 is done, where we will hopefully be already happy with our codebase and API.
This means that everything that we're discussing here it's what should be in place (if most people agrees with those approaches/ideas) when we get to that point that you're mentioning here
I think you are confused and you think this is something that will happen right now, with our current state of the art. Simply not, that's why we're sticking to the current system, as it works as you mention. A system that works doesn't mean it's the best one, that's why this discussion is here for pointing out ideas, approaches, samples and so on between contributors.
We are starting to use discussions for this kind of meta thing for huge new features, future goals or to reach an agreement in code styling, processes, etc. Huge features usually involves multiple people working on them, so that means that those people will need to agree somehow in how they're going to accomplish that :).
Only stuff made from now on by us in issues/PRs are things to consider that will arrive "soon".
I definitely think we should keep the options. I too find them quite important especially with an uplink of fluctuating quality and bandwidth.
That said, as-is, they're a bunch of dumb levers, which I agree makes things very hard to handle. There don't need to be nearly that many options, and the options should be valid.
What I'd very much prefer would be an intelligent quality system. Have JF determine the base quality of the video file and use that as a baseline, then provide some transcoding-to-lower-resolution/bitrate options based off some general rules
So let's say we had a 1080p x264 video with a normal bitrate of 40Mbps 1080p. That would be our "top quality", rather than the current 60Mbps 1080p which makes zero sense for that video file. Then maybe have it do some stuff like "half bitrate", "quarter bitrate", "eighth bitrate" so 20, 10, 5Mbps each, then some low-resolution options (limited to maybe 1 or 2 bitrates per lower size). We could also let the admin customize the valid options on a global level.