2025-02-03, 07:28 PM
(This post was last modified: 2025-02-03, 07:31 PM by Efficient_Good_5784. Edited 3 times in total.)
In case you want an example to help you understand what @TheDreadPirate stated, lets use this following example.
Assume you grab a 24 minute tv show video and re-encode it with something like handbrake or ffmpeg to an average of 2Mbps.
Lets also assume that the final size of the video is 360MB in total.
You then add this file to your Jellyfin server.
When a remote client requests this video on your network with an upload of 15Mbps, the file will be streamed to the user at 15Mbps (or as fast as the connection can support at the time).
Now despite the video having an average bitrate of 2Mbps, this just means that the entire video will download faster than what the client can watch it at (when watching at x1 speeds).
The whole file usually isn't sent in full and is actually sent in chunks to most clients.
As in, most clients have a pre-determined cache/buffer size and once that is hit, the client will slow down on how much data it asks for to keep filling up the buffer.
However, lets assume that the entire file would be sent in one go to the client. This 360MB file will have been sent to the remote client in 3.2 minutes at 15Mbps.
As you can see under this assumption, the 24 minute video was provided in 3.2 minutes
The client can't build a buffer if it's getting exactly the amount of data it needs to play the video in real-time. A cache/buffer exists solely to fight against video pauses due to bad network connections.
So what Dread was saying is to try and set the remote bitrate limit to be no more than 50% of the upload speed so that remote clients have a chance of building this buffer for smoother playback.
If you were to create a video with exactly 15Mbps, you're leaving the client with the expectation that there will be absolutely no hiccups to your home's upload network and the remote client's download network speeds.
Assume you grab a 24 minute tv show video and re-encode it with something like handbrake or ffmpeg to an average of 2Mbps.
Lets also assume that the final size of the video is 360MB in total.
You then add this file to your Jellyfin server.
When a remote client requests this video on your network with an upload of 15Mbps, the file will be streamed to the user at 15Mbps (or as fast as the connection can support at the time).
Now despite the video having an average bitrate of 2Mbps, this just means that the entire video will download faster than what the client can watch it at (when watching at x1 speeds).
The whole file usually isn't sent in full and is actually sent in chunks to most clients.
As in, most clients have a pre-determined cache/buffer size and once that is hit, the client will slow down on how much data it asks for to keep filling up the buffer.
However, lets assume that the entire file would be sent in one go to the client. This 360MB file will have been sent to the remote client in 3.2 minutes at 15Mbps.
As you can see under this assumption, the 24 minute video was provided in 3.2 minutes
(2025-02-03, 10:10 AM)ANJ_ Wrote: Also I am a bit confused, if setting the bitrate limit doesn't apply to the transfer of data how am I supposed to control exceeding 50% upload utilization as you suggest? It sounds like I'm basically given no control over that (within Jellyfin at least).If we were to follow this and limit the network to 2Mbps for this one stream, the client would stop the video and buffer if there were any interruptions to the network speed while it was playing the video in real-time.
The client can't build a buffer if it's getting exactly the amount of data it needs to play the video in real-time. A cache/buffer exists solely to fight against video pauses due to bad network connections.
So what Dread was saying is to try and set the remote bitrate limit to be no more than 50% of the upload speed so that remote clients have a chance of building this buffer for smoother playback.
If you were to create a video with exactly 15Mbps, you're leaving the client with the expectation that there will be absolutely no hiccups to your home's upload network and the remote client's download network speeds.