Skip to content
2

Quality switcher #4795

ferferga asked this question in Ideas
Quality switcher #4795
Dec 15, 2020 · 7 answers

@ferferga
ferferga Dec 15, 2020
Collaborator

Originally in jellyfin/jellyfin-web#1993 (specific comment)

I want to give the concept I had in mind for making the quality switcher great:

  • First of all, quality options shouldn't be handled by clients. According to the file's bitrate, server should generate a combination of possible options and return them to client. This is good for consistency, as users will have same quality options in web and in Android.

With the current system, a 1080p - 30 Mbps option appears when I'm watching a 15 Mbps movie, which doesn't make any sense.

  • We should only have two "default" options that will appear all the times:

    * **Maximum**: Stream original file when device is capable of direct play or the maximum quality transcoded version that the device can handle (in case it's not compatible)
    
    * **Auto**: Stream's quality changes in real time based on the connectivity of the client.
    
  • Keep only resolution options and remove any mention to bitrates. They're confusing for most people. We can add in the nerd stats of each player an option for requesting specific bitrates in case we really want to keep this. In that case, client should know from server (as mentioned above) the bitrate of the original file, so user can't request a file with a bitrate higher than the original one.

  • Add an option in each's client settings (Data saver mode for instance) where the bitrates (except in Maximum) of each of the resolutions are cut in half or by a quarter. So, for instance, if for a movie in 4K@50Mbps server determines that best bitrate for 720p is 4 Mbps, client forces the server to use 2 Mbps instead.

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.

Replies

1

Keep only resolution options and remove any mention to bitrates. They're confusing for most people.

Bitrate selection is an incredibly important feature to many users like me - who use Jellyfin exclusively remotely (hosted on vps/dedi). I would definitely leave the option to easily select a bitrate there, but maybe reduce the number of options in relation to the currently played media (I did this on my private web client fork).

So, for instance, if for a movie in 4K@50Mbps server determines that best bitrate for 720p is 4 Mbps

Let's say that the server determines that the best bitrate for 1080p transcode of 4k@80Mbps movie is 25Mbps. If I was on a 10Mbps connection I would be pretty much SOL and would have to drop to 720p or lower.

Right now, the web client only sends the bitrate to the backend, iirc. The resolution is then set by the backend to a sane value (e.g. 4Mbps would be 720p, and 5Mbps 1080p for a 30Mbps 1080p remux). If I'm on a slow connection I usually select 5 Mbps, but when I'm home I can safely set it to 20Mbps without any buffering... Both 5 and 20 Mbps are 1080p, but with a large quality difference.

As a power user, I would even welcome an option to select the audio bitrate separately to that of the video (I added this feature to the jf kodi plugin options in #395).

5 replies
@ferferga

ferferga Dec 31, 2020
Collaborator Author

Bitrate selection is an incredibly important feature to many users like me - who use Jellyfin exclusively remotely (hosted on vps/dedi). I would definitely leave the option to easily select a bitrate there, but maybe reduce the number of options in relation to the currently played media (I did this on my private web client fork).

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 😋. See how Youtube's nerd stats work work.

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).

Let's say that the server determines that the best bitrate for 1080p transcode of 4k@80Mbps movie is 25Mbps. If I was on a 10Mbps connection I would be pretty much SOL and would have to drop to 720p or lower.

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.

As a power user, I would even welcome an option to select the audio bitrate separately to that of the video (I added this feature to the jf kodi plugin options in #395)

Pretty much everything said earlier with nerd stats.

@Electry

We already have a similar feature in Jellyfin as well. Nothing prevents us from adding a few fields there.

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.

but there are some times that you just want relax wih your content and get things to work, without troubleshooting or trying different options

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.

Also, in the future, all the players will be able to handle adaptive media

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.

@ferferga

ferferga Dec 31, 2020
Collaborator Author

@Electry

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.

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 :).

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.

Same as above

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.

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".

1

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.

0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
💡
Ideas
3 participants
Beta