I don’t have an issue with that. I only have issues with my server having capable upload and my remote users having capable download on a direct playable file being transcoded to 2Mbps because Plex says its’s so.
Yes, that is correct, however it will only occur when transcoded. I’ve personally used it and I’ve seen it use everything from 0.7Mbps to 20Mbps (as it should). I’m certainly not saying it’s perfect, but can attest that it does change as needed and greatly minimises buffering.
2 Likes
See my previous comment:
Wow just double checked that myself and you are absolutely correct, on both accounts.
Honestly I feel the same, would be great, hardly a deal breaker. Transcoding to h264 is a managable load for the number of simultaneous streams I typically see. And folks that are keen enough to notice quality differences between a 8mbps transcoded stream and an 8mbps direct stream usually tend to be technical enough to find and adjust the quality setting. What drives me batty is seeing all those crappy 2mbps streams when you just know they haven’t noticed the quality adjustment.
PS I need to remember to qoute more … so much less confusing.
1 Like
I saw it, I just hoped that “on transcoded media” could have meant “initially”, not “always.”
if not today, then eventually. But hardly a deal breaker, anything is better than 2mbps streams!
2 Likes
Thread closed due to name calling and personal insults.
So to wrap things up:
Many people feel that the current default remote quality of 2-4 Mbps results in poorer visual quality than their infrastructure could handle. It also introduces unnecessary transcodes when the library is not specifically optimized to 2 Mbps.
A stream will always start with the configured bitrate (2-4 Mbps by default). The server will either direct play/stream if the file’s bitrate does not exceed the configured bitrate, or it will transcode the stream to that bitrate.
With auto quality turned on, if the stream starts with direct play it will stay that way and nothing will change. If the stream starts transcoded, the bitrate will be dynamically adjusted between 0.7 and 20 Mbps depending on the capabilities of the infrastructure, but it will respect the remote-streaming limit (which can be configured by the administrator and is not the same setting as the quality setting).
Considering the above points, turning on auto quality by default will improve the visual experience for many users with internet connections faster than 2 Mbps, but it will not reduce the amount of transcodes. Transcodes would only be reduced if the default quality was be set to a higher bitrate, which could introduce problems for users with slower internet connections. In a perfect world the auto-quality feature would be able to switch seemlessly between direct play and transcoding but I understand that this is technically difficult to implement. I believe that the sensible thing for auto-quality to do instead would be a short bandwidth-test before the start of the playback to determine the maximum bitrate that the infrastructure can handle, then start the playback as usual but with the determined bitrate as the starting quality. This would ensure the best visual experience and the least amount of transcodes without penalizing users with slow internet connections. I am not sure how this could be implemented without introducing a short delay before playback, but I understand that emby does a similar thing and in my experience the streams start faster there than they do with plex.
5 Likes
The challenge around using Auto as the default is that we don’t currently have a way to transition between transcoded video and remux/direct play and back. That’s been the blocked for moving to default Auto.
5 Likes
