+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: General Questions (https://forum.jellyfin.org/f-general-questions)
+--- Thread: Best Transcoding/Bitrate Practices (/t-best-transcoding-bitrate-practices)
Best Transcoding/Bitrate Practices - ANJ_ - 2025-02-02
I've had my Jellyfin server up and running now for quite a while but haven't really looked much into best practices for setting bitrate limitations. While I use it in-network and haven't had to worry about this much for my own experience, I do have some out-of-network users and would like to make sure things work well for them.
At the moment I have the pleasure of an ISP that only gives me around 15mbps up, which really limits my rate of served data, because of this I have assumed setting some bitrate limitations is key. Without much research I figured the best logical baseline limiting would be to take my 15mbps up and divide that between my maximum expected connections. ie. 15 total up / 3 users = 5mbps bitrate limit (which is my current bitrate limit). While I'm simplifying a bit and am actually allowing for leftover upload data for other needs, this is the basic setup I have.
What I have found with this setup are a few things: First being that if I am doing any other kind of uploading, especially through web apps that don't allow for any kind of limiting, an out-of-network Jellyfin user will experience notable buffering. Second, most files being served over Jellyfin are natively encoded at a bitrate higher than 5mbps which inevitably leads to a guarantee to hit the bitrate limit which in turn leads to: third, transcoding will almost always occur to serve the data out of network as the bitrate limit is met.
My questions for the more knowledgeable are this:
Does the logic I have drawn for my settings make any sense? In other words, have I gone about my needs correct in dividing my max upload between my expected connections, allotting for some leftover room? Or is there a better way that you could explain?
Does setting a bitrate limit that will inevitably be hit by the files native settings make any sense? Or, is it better to raise or eliminate the limit so that this doesn't happen?
If the answer to the above is that it should be raised/eliminated, then: Will raising or eliminating the limit cause issues when/if there are simultaneous out-of-network users? Or will I run into more issues when/if other data is being uploaded elsewhere from other sources?
Does transcoding to meet these bitrate limits cause added/unnecessary buffering or other problems for end-users? / Is serving the native file better if it means raising the bitrate limit some to avoid transcoding?
Also, although less important, I am curious about this: While observing I have noticed in the Jellyfin Dashboard when users are receiving data there is a red bar indicating the amount of file loaded, when the red bar disappears/the file is loaded (i'm assuming), is my server then done serving them up data and they can scrub through the file freely without me uploading anything? I'm just curious because when someone reported an issue I stopped uploading a file elsewhere to alleviate their buffering but wasn't sure if I were to start uploading my file again, once the red bar was gone, would their video start buffering heavily again?
admittedly I am not well versed in networking and I have been learning more about self-hosting as a hobby through trial and error mostly. The hardest bit for me is trying to optimize anything that is out-of-network as it basically requires me to be in two places at once (the source and the end point). I have some pretty obvious limitations at the time and am trying to learn more. Appreciate anyone that chimes in here, would love to learn more especially about how transcoding works in these scenarios and what offers the best final output.
Also, a small note on hardware in terms of transcoding I am using the QSV encoding on a i7-7700k
RE: Best Transcoding/Bitrate Practices - TheDreadPirate - 2025-02-03
To clarify how the bit rate limit actually works, when you set a bit rate limit Jellyfin will transcoding higher bit rate content down to that limit. However, that does not apply to the actual transfer of that transcoded data. There is no mechanism to then limit the speed of that transfer to 5Mbps. At least not in Jellyfin itself.
Having said that, your OS should juggle multiple streams to achieve approximately an even split of your available upload bandwidth.
Ideally, you should try to avoid exceeding 50% upload utilization to ensure consistency and to ensure that your client is receiving data fast enough to build up a buffer to smooth over dips in data transfer.
But your options are pretty limited. As you already know, 15Mbps just isn't enough. I feel your pain. I have to get the 1Gbps plan with my ISP just to go from 10Mbps upload to 40Mbps upload. And I still have to set a bit rate limit to ensure a consistent experience for my two remote users + me and my wife when we are out of the house.
The only thing you can change is A) get a higher tier plan with a higher upload if that is available or B) set an even lower bit rate limit.
Neither are great options, but you gotta do what you gotta do.
RE: Best Transcoding/Bitrate Practices - ANJ_ - 2025-02-03
(2025-02-03, 01:24 AM)TheDreadPirate Wrote: To clarify how the bit rate limit actually works, when you set a bit rate limit Jellyfin will transcoding higher bit rate content down to that limit. However, that does not apply to the actual transfer of that transcoded data. There is no mechanism to then limit the speed of that transfer to 5Mbps. At least not in Jellyfin itself.
Having said that, your OS should juggle multiple streams to achieve approximately an even split of your available upload bandwidth.
Ideally, you should try to avoid exceeding 50% upload utilization to ensure consistency and to ensure that your client is receiving data fast enough to build up a buffer to smooth over dips in data transfer.
But your options are pretty limited. As you already know, 15Mbps just isn't enough. I feel your pain. I have to get the 1Gbps plan with my ISP just to go from 10Mbps upload to 40Mbps upload. And I still have to set a bit rate limit to ensure a consistent experience for my two remote users + me and my wife when we are out of the house.
The only thing you can change is A) get a higher tier plan with a higher upload if that is available or B) set an even lower bit rate limit.
Neither are great options, but you gotta do what you gotta do.
Oh! well that's news to me. So then if most of my files are probably just 1 or 2 mbps higher than my set bitrate limit I probably shouldn't even set a limit right? Just means extra transcoding for not much reason no?
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).
RE: Best Transcoding/Bitrate Practices - TheDreadPirate - 2025-02-03
To clarify, the 50% utilization comment applies to the NEEDED bandwidth to support the underlying video stream(s). Meaning if you have 15Mbps of available bandwidth, the cumulative video+audio bit rate of the the videos being served shouldn't exceed 7.5Mbps.
The goal is to have more bandwidth than you need so that the clients can build a buffer. In the above scenario you are transferring the video(s) at about 2x the video's actual bit rate.
If the cumulative total bit rate of the videos you were serving was 15Mbps the clients would never be able to build a buffer. ANY hiccup, dropped packet, re-transmit, etc., during the stream results in buffering.
This isn't a hard rule, but something to keep in mind. Serving video smoothly requires extra bandwidth than what is strictly needed to build a client side buffer. And it is definitely an even harder rule to follow when your upload is as low as yours and mine are.
RE: Best Transcoding/Bitrate Practices - Efficient_Good_5784 - 2025-02-03
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
(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.
RE: Best Transcoding/Bitrate Practices - ANJ_ - 2025-02-04
I see, thank you both for the information! I'll be experimenting a bit more with this in mind.
with my 5mbps bitrate limit I was coming to find most out-of-network streams resulting in transcoding almost always, but as there are rarely multiple out-of-network streams happening at once I will try raising the cap some to try and avoid transcode while still protecting against buffering...
until I can get fiber
RE: Best Transcoding/Bitrate Practices - goerdi - 2025-02-04
Hi!
If you are low on upload bandwidth and its not live tv you want to watch , maybe media Download during low usage times is an option...
Ciao Gerd