I believe there are a few specific issues that need to be addressed as part of the decision process.
Client Playback Capabilities - This should trump all and be the first factor for transcoding. Bandwidth Availability - This can (and should be) means tested. While it’s true you can not assume the client has enough bandwidth available, it should not be assumed by default they don’t. The also needs to be a server calculation involved in this aswell (I believe something kind of exists already in the settings, how this applies to stream, no idea) Client Default Remote Settings - I believe the current plex default settings for clients do need to be adjusted - or maybe a kind of auto/detect mode needs to be added (for remote playback).
Something like:
On connecting to the server / first video playback start - do a quick bandwidth test - can I play without buffing to much? Y/N
If I have the bandwidth, can I play the original file format? Y/N
K great - if it has subtitles - do I need to burn them in? Y/N
I think having those existing settings is valuable to force - but they make horrible defaults.
Transcoding is a great feature - but it also can consume a lot of CPU resources/electricity and the current settings are wasteful in that regard (by potentially forcing something that is not required),
Sorry, but this is a very weak excuse. The server and the client can talk and disclose capabilities, and then after that automagically decide what is better, and if on the fly things are not working (i.e. bandwidth is not enough) then adjust it in order to get the best possible outcome.
This is nothing new, this is how potentially every streaming service works (Netflix, Prime, ATV+, etc), all except of course Plex.
OMG, you insist in letting the end user decide. No wonder why things do not work, you have little awareness of your installed base. Most of our “clients” are techno-illiterates, they are our parents, uncles, siblings, etc who have no clue about bitrates and can’t differentiate bytes from bits.
Again, the real solution is that the default configuration is something SMART that can automatically decide and adjust itself on the fly. Then provide the other options for POWER users.
By the way you talk, you are indeed saying you will keep the status quo.
I think you’re misunderstanding how those kinds of services work, compared to a self-hosted service such as Plex. Those services (as well as our free movies and TV offerings) have multiple versions of content at different bitrates, and can seamlessly swap between them. Self-hosted content is very different, and has more complexities. While what you have proposed sounds good in theory, it’s not super straightforward to implement something like that. We’ve said multiple times now that work is underway on a solution for this, so we’re not keeping the status quo for this. I’m afraid I can’t give an exact timeline, but we are currently testing things internally.
I am not misunderstanding anything. Of course I know Netflix and co, have different versions of the files. And of course what I proposed is not easy, otherwise you would’ve implemented it already, but it is the real solution. I was actually expecting that you told me “ffmpeg does not support changing bitrates on the fly”, so I could tell you “Well, Plex could implement that feature in ffmpeg instead of waiting for someone else to implement it”. But instead you decided to tell me “I know better”. So I am a bit disappointed.
Feel free to keep putting the final decision on the customer running the app, AS YOU ALREADY SAID, and therefore keeping the status quo.
There have been attempts already to implement changing bitrates on the fly in ffmpeg, there was even a patch but it was not accepted in the main trunk. The implementation had a socket and you could communicate with the running ffmpeg and change the bitrate. That was five or seven years ago.
To be honest, I do not follow anymore the current ffmpeg development and I even don’t know if Plex still uses ffmpeg. But the idea is the same.
And even if you do not implement adjusting the bitrate on the fly, just by implementing a mechanism that decides what would be the best scenario is much better than letting the customer decide. Letting the customer decide is THE WORST. You should only offer options for advanced users, but the default should be the best possible option with the existing information.
Sorry that I disappointed you there. However, you’re still misinterpreting what I said. I said that any changes would be on the client side, and that end users would be able to have control. This is also how services like Netflix or Disney+ work. The end user can set their own maximum quality, regardless of what the default from their service is.
We’ve already experimented with automatically adjusting quality on the fly in the past with our “Automatic Quality” option, though that has some issues with switching from transcoding to Direct Stream or Direct Play. With new work, we want to be able to switch between the three more smoothly. We’ve given our solution a lot of time, thought, and consideration, and as I said previously, we’re already testing something internally, and are confident with how it performs.
You let me ever more confused. In at least two aspects first you were saying A and now you are saying B. But it is OK, as you can see we are patient and we will wait and see. Thanks for your replies.
Since when does the customer have a choice of resolution with Netflix, Disney+ and co. That’s news to me. I know countless people at Netflix, for example, who have a 4K subscription but can’t get and set 4K streams on various players.
That there is a setting option there is also new. As far as I know Netflix has 4 qualities and depending on what goes and depending on the subscription he gets the best possible but that works anything but perfect as you now claim.
Why that the user must have control is still a mystery to me. Because again a large part of the user has neither a clue about your Internet line, the connections nor any settings. You wouldn’t believe how many hours I’ve spent on support in the last 12 years, writing manuals and nothing really helps. It would be much easier to test the connection with some files (as big as possible of course) and then you know exactly what the customer and his devices can do. I think 90% of all server admins have this knowledge, but just to give the user this responsibility / power is in my opinion simply not practical, even if certainly laudable. I also love open systems rather than proprietary ones. Still, some users are simply not willing or able to solve this on their own.
These have existed for quite some time. Since launch for Disney+, and for Netflix at least since they launched in Australia in 2015 (see: article one and article two for Disney+, and Netflix’s article), and allow users to set a maximum quality in order to control data usage. We’re working towards giving end users the best possible quality, while still allowing them to control their data usage, which is why any change will be on the client side, and allow users to set a maximum amount of data usage for themselves.
You can’t specifically say you want 720P, 4K, 480i playback like on Plex, but you can limit the bandwidth used, which is pretty much the same thing.
When you log into your Netflix account (not through the app), you can set the amount of bandwidth an individual profile uses. I actually have a profile set up for lower bandwidth usage that we only use when we are at our vacation cabin that only has internet via a hot spot with limited data.
Not quite sure if this is what you meant in the second paragraph of your post, so if I’m just repeating you, I apologize.
The point of this thread is to not have the client automatically transcoding right out of the gate. That’s the whole point. Nothing more nothing less. Just trying to make a simple thing difficult is all that is going on in this thread between Plex and everybody else.
You wanna implement something to make it more user friendly to control their streaming experience then fine, whatever. But stop putting un-needed strain on our equipment. If the user needs to transcode they can choose to do that after the fact instead of having every client DDoS the servers for absolutley no reason. And that is exactly what it is, a DDoS. For a lot of people we can’t sustain large transcodes.
No matter what, we the server admins have to explain it one way or another until Plex makes the settings more accessible for people who know nearly nothing. But it’s even worse when people rip down a 4k movie to 720p when we the server masters of the world know that shouldn’t be happening… why do we know this? Well because we have very close relationships with our “users” aka family and friends. Not some rando from Uganda and Nigeria. LOL BIG LOL.
Yes, and they aren’t turned on by default for users. The service comes set to max quality, and you then go change the setting if you want to lower it. Literally what this feature request is.
Personally, I would love to see a server side option to enable a “Client Bandwidth Test” that does an internal speedtest between the client and the server when the client first logs in, and then sets the default bandwidth profile based on the results. Could still allow clients to choose something other than default, and of course there is variability in mobile clients bandwidth but it seems like this would be a better solution then the current “everyone is 2mbps 720p” approach.
Just had a wave of 10 users this week having transcoding errors because their app updated and reverted their quality settings back to default. Plex. For the love of all that is holy. Please. Fix. This…
I haven’t changed anything and neither did they.
Update Make that 11 users now…
update 2 Ended up being 13 years by about midnight. Not to mention they have a video quality setting and music quality setting separately on some apps… which confuses users because they don’t know what they’re doing in the quality settings as it is…
Plex, you need to realize that the only tech savvy people using your software are server admins (even then some aren’t that savvy). Anyone else using your app is a server admins family and friends. I can only assume Plex devs don’t run their own servers at home or they’d be getting these same calls from their users. Not to mention you guys should really have a test lab that has all the clients in it so you can actually properly test things before release… I can’t count the amount of times I’ve seen questions asked about a particular client only for a dev to say “I have no experience with that client”.
I typically try to keep quiet in here, but this is getting beyond stupid (it was stupid years ago).
Most of my users have all together just stopped using Plex at all.
Most just got frustrated tiring to get it to work all the time, so they stopped asking me for help. Buffering issues in the middle of a movie is a killer… And having them go to setting and revert it back to maximum or original got old… So plex now has lost users because it also affected the Plex online services…
Oh man, what is this nonsense? I actually have to thank you because you just solved an issue I was having. In one client after an update the “H264 Maximum Level” was reverted to “Recommended” after an update and I didn’t realize it and it was transcoding when it was not needed.
Seriously Plex? Why are you resetting user’s configurations? WTH?
