I get there’s additional complexity, but I don’t understand how a system that requires a user to say yes to an upgrade or downgrade would be less complex than one which just automatically makes the change.
I’d assume this proposed system is designed for scenarios where a user accepts every offered upgrade/downgrade? If so, then why ask the user at all? If not, then is that not a major omission from the proposal?
Or is there something else I’ve missed which makes just automatically accepting the upgrade/downgrade more problematic than if the user manually accepts that prompt?
It’s far more complex. Making a manual change like this interrupts the playback session (so you’ll see a very brief loading screen as it loads up the new quality). Attempting to do it dynamically during playback is very complicated, especially if you don’t want to interrupt what’s actually shown on screen (like Netflix, Disney+, etc.). Because it will interrupt the session, we want the user to make a deliberate choice, rather than seeing a black screen in the middle of playback with no input from them. Users might also know that the interruption to their connection is temporary (say an OS update downloading in the background which is almost done), and don’t want to downgrade because of that. There are lots of reasons people might not want to change, and we shouldn’t force them into that.
Sounds like a good solution to me, looking forward to it (at last) and appreciate the work. Appropriate that after all these years there’s one last (hopefully last) moment of frustration with the decision to test it only on Android, which makes zero difference to me or anyone on my server
Wait. Will playback always start at the maximum or will it start at whatever was the last bitrate? So if a user for whatever reason downgrades, which most users will do if playback doesn’t work properly, and then get a better connection, it will start transcoding to a lower bitrate at the next session as well? If so then I fear a lot of users will just stay at the lower, quality because it “works”. Then nothing is really solved for server owner.
I really want whatever this logic is doing to always prioritize trying to playback without trancoding first. That is the single most important thing this needs to do.
No, playback will start at the last known good bitrate. Should they be able to upgrade, they’ll be prompted to do so. We tried what you’re proposing, and it was not a good solution, and resulted in a poor playback experience for the user. Our data says that the approach we have taken results in significantly increased bitrates for users, and far less time spent buffering (or encountering buffering at all). I know people have reservations about certain scenarios and potential edge cases, but I’d ask them to reserve at least some judgement until they’ve seen it in action, before saying it doesn’t solve the issue.
Have you tested/considered doing a bandwidth check and if the client is overwhelmingly capable of streaming at maximum quality, upgrading automatically?
For example, client has 100mbps connection, but something in their network craps out and their bandwidth drops to 10mbps. They’re watching media with a bitrate of 20mbps so they’re promoted to downgrade, which they do.
Later, their network recovers, but when they go to watch something with a bitrate of 30mbps it gets downgraded to 10mbps even though they’re currently capable of 100mbps.
In that scenario, will they be prompted to upgrade immediately when starting to watch the second time? Can they just be upgraded automatically considering their bandwidth is more than capable of handling maximum?
Yes, we considered and tested that in an earlier iteration of this work, and it was nowhere near as reliable as what we settled on in terms of providing a good playback experience. In that scenario, the user would be prompted almost immediately to upgrade when the network recover. However, we will not override a user made decision, so if they choose not to upgrade, then they won’t be upgraded automatically. However, as I’ve mentioned before, please wait until you’ve got to try and experience this, before we start getting into cases where you think it won’t work, or users won’t do X or Y.
I’m sure it’s a lot better than what we have at the moment.
But I just can’t help thinking about “edge cases”, like what if the server just can’t transcode a file? I have some HDR 4k files that my server just can’t decode fast enough to also reencode into any format. This Christmas I was going to watch The Two Towers at my parents place, and for some reason the Plex for Android TV had reset it’s setting to 2mbit remote streaming. And it was just a complete BS stutter party. Completely unwatchable. Setting it back to to maximum solved all of this, of course.
I never allow 4k transcoding on my server (despite the server being more than capable of doing it) as it is a waste. I provide 2 copies of the file, one 1080p the other 4k (if it exists) so don’t waste my server power transcoding 4k when you can easily just play the 1080p file.
Thing is, most of the time, plex is smart enough to serve the right file based on device and remote streaming settings, however in those edge cases where people wanna mess around, I use notifiarr to cut any 4k transcoding.
I know it’s partly my own fault, because I don’t really want to waste space on multiple versions that I’m never going to personally use or need. My remote users are all on devices connected to TVs and the devices today are so capable that imho a transcode just shouldn’t happen. Neither myself or my users stream movies on cellular, so bandwidth or datacaps are never an issue.
The only time I’ve transcoded in the past was when I had to burn .ass subtitles into a stream when chromecasting at a hotel room. I’ve since bought a Chromecast with Google TV for traveling purposes, and .ass is now natively supported on Android fixing that scenario as well. I don’t think I’ll ever need to transcode a file again tbh.
I just want Plex to always go for the original quality first and only offer transcoding if that fails. I get that a lot of users are on mobile devices and that Plex needs to consider these users, but it’s not optimal for my server and me personally.
I’m doing the same but without notifiarr. If notifiarr kills 4K transcoding, how will the remote user be able to play the 1080p file? Just try again? Or force play the 1080p file using “play version”?
If clients don’t have the bandwidth to stream the original file, and your server isn’t powerful enough to transcode, they’re no worse off than they are today, and those two issues aren’t problems we can solve. The default is maximum, so it will Direct Play if possible.
Just to be clear my server is powerful enough for transcoding most things if necessary, except 4k HDR, and I wish I could just disable that resolution completely from the transcoder.
Tbh, from my experience, most of the time transcodes have happened in the past, it was because of 1) The absolute garbage default 2mbit limit, which will finally be fixed soon, and 2) lack of format support in devices that should be able to Direct Play but didn’t because there was various limitations, like the lack of .ass support on Android or AV1 capable devices not being allowed to Direct Play it because of some technical debt at Plex that seemingly took years to get proper attention. But you’ve finally done a lot of good work at these kinds of issues in 2022, so hopefully frequent transcoding will soon be a thing of the past.
I think the last remaining small headache I have with Plex that causes issues with playback, once the proposed solution to internet streaming has gone live, would be allowing 10-bit h264 to be played in software on capable devices like the nVidia Shield, as there is not a lot of devices that have hardware support for that particular format. Currently you get a lot of artifacts with these files on these systems, as it’s trying to play 10-bit files with an 8-bit decoder.
Well, for all my whining about issues in the forums I’m happy with Plex probably 98% of the time.
You mind sharing that exact message to me? Does this affect/kill only 4K video transcodes? What if it’s audio transcoding and direct streaming the video?
