Emby auto quality extremely aggressive

[DancingTable 11]

My parents and brother have started using Emby. Parents client is Apple TV on wifi, brothers is Linux desktop on ethernet.

I have 150 mbps upload, they both have gigabit down.

I’ve noticed each of them watching something at 5 mbps, being transcoded to 4 mbps. I have more than enough capacity for 5 mbps (this was seperately) and even 10 mbps if they’re watching together, yet it seems to really want to save that single mbps.

I changed the quality setting from “auto” to “1080p 20 mbps” on both, and they both work flawlessly, but I’d really rather leave it on auto. Why is Emby so desperate to save that single Mbps? Is there a way to change how aggressive it is?

[Lessaj 467]

It will be updated to 12 Mbps on the next release to my knowledge. Since the connection is viewed as remote limits are put in place, but if you add their subnet to the LAN network it will treat them like local and should be "max speed". May not apply on their end immediately even after you add it though.

[DancingTable 11]

Why can't it just be actually auto? If my connection to them shows 150 mbps, let it use that. If my max upload is 150, 2 people are watching, give them up to 75 each (or if ones using 50, the other can use 100)

 

12 covers a fair bit of my library, but I would still prefer it just run at whatever it can. Seems silly to have "auto" be just a predefined limit. 

[Q-Droid 989]

It does seem silly but the devs really love this feature. Search the forums and you'll see for yourself. Getting them to consider an actual fix or to give admins centralized control is like pulling teeth. 

So until then get used to the bandaid fixes and telling your users to override with their playback settings. 

[Happy2Play 9780]

That is why they need to call it something different then AUTO as it does not mean what any user will think it means.  As 99% of the time it will fallback to hard coded values per client as the client network probe doesn't seem to work for most.

[DancingTable 11]

4 minutes ago, Q-Droid said:

So until then get used to the bandaid fixes and telling your users to override with their playback settings. 

Yeah, I have set it to override, currently at 20 mbps. Which is fine for most of the content on my server, but I'd rather they have max. I'm scared to set it to max though, because they I could theoretically run into a situation where 3 or 4 people watching the server on something really high bitrate could exceed my upload. Auto should be able to solve this, but apparently it cannot.

 

Even if default was something reasonable like 12 mbps, you should be able to set auto and have it actually be auto.

Edited January 9, 2025 by DancingTable

[Happy2Play 9780]

10 minutes ago, DancingTable said:

Auto should be able to solve this, but apparently it cannot.

There is no adaptive speeds here as every user gets what they start with and adding more uses will not ever change the speeds of existing connections.

[DancingTable 11]

2 minutes ago, Happy2Play said:

There is no adaptive speeds here as every user gets what they start with and adding more uses will not ever change the speeds of existing connections.

That's still a flaw in my opinion. Auto should automatically adjust to conditions. It is auto, after all. Oh well, I guess I will set everyone to like 20.

[Happy2Play 9780]

Just now, DancingTable said:

That's still a flaw in my opinion. Auto should automatically adjust to conditions. It is auto, after all. Oh well, I guess I will set everyone to like 20.

That is why it needs a different name as it has nothing to do with what you think it does.

But you can always take a read here.  But I would think most servers still would be able to handle the load though.

  

 

[Q-Droid 989]

3 minutes ago, DancingTable said:

That's still a flaw in my opinion. Auto should automatically adjust to conditions. It is auto, after all. Oh well, I guess I will set everyone to like 20.

It doesn't matter what you set unless you're also telling your users to do the same. If your users are setting their bitrate to max then yes, you can manage it from the server when your value is lower than theirs. But when the users have Auto it will fallback and use the lowest of the two values.

[Happy2Play 9780]

Yes the only workaround here is have all client set to max and you throttle them per user server settings.  But currently there is nothing adaptive to better share with multiple users so yes one or two could technically use all available upload speed leaving nothing for others if you don't micromanage per user to a value you know will work for all your users.

[DancingTable 11]

1 minute ago, Q-Droid said:

It doesn't matter what you set unless you're also telling your users to do the same. 

Sorry if I wasn't clear: I meant I will manually set their devices to 20. Although setting it to max and then adjusting from the server isn't a terrible idea, gives me a bit more control as I add people to the server. Right now 2 people use it remotely, but if I share it with a couple more I could adjust then. 


If they set it to 200, and I set it to 20, it won't try to do 200 from their end and just freeze constantly though? It'll drop down to 20 and transcode properly?

[Q-Droid 989]

5 minutes ago, DancingTable said:

Sorry if I wasn't clear: I meant I will manually set their devices to 20. Although setting it to max and then adjusting from the server isn't a terrible idea, gives me a bit more control as I add people to the server. Right now 2 people use it remotely, but if I share it with a couple more I could adjust then. 


If they set it to 200, and I set it to 20, it won't try to do 200 from their end and just freeze constantly though? It'll drop down to 20 and transcode properly?

The playback stream will use the lowest value.  Server User limit overrides Server Global limit which is then compared to the Client limit.

[Jdiesel 1431]

 

Here is another thread that discusses how things actually work. As mentioned above, there is nothing auto about the auto setting in most cases. It should really be called "Default (4 Mbps)" soon to be "Default (12 Mbps)". If people understood what auto actually was they would be more inclined to adjust it, the way most users interpret auto is "best quality for their connection" and that is not what is happening.

[Lessaj 467]

As I mentioned earlier your users can leave it on auto if you add their class A subnet to be considered as a LAN network, for example 67.0.0.0/8. Then you could fine grain per user if you want, so the users don't need to do anything on their end and it's all handled by you.

Also don't forget that a user may not necessarily saturate a connection either, rather it will request an amount of buffer, so rather than seeing a constant 5 Mbps flowing to a specific IP instead you'll see spikes maybe up to 100 or even up to your 150 capacity, and then nothing for a period of time before it makes another request. This traffic pattern changes based on if direct play vs transcoding based on my observations.

[DancingTable 11]

1 hour ago, Lessaj said:

As I mentioned earlier your users can leave it on auto if you add their class A subnet to be considered as a LAN network, for example 67.0.0.0/8

I don't think that's a solution because then I could run into an issue where it caps out my upload speed

[Lessaj 467]

9 minutes ago, DancingTable said:

I don't think that's a solution because then I could run into an issue where it caps out my upload speed

Not necessarily if you limit them from the user page after. This just means your users don't need to do anything and you are fully in control of their max limit. Also as I mentioned you would really only hit your cap when they first start a stream, if there is even enough data in that initial buffer to ramp to your full speed, and after that will be spikes. The same thing happens regardless of the bitrate though, the client will make the request to your server, let's say it's transcoding so it's requesting a TS chunk, and the server will try to respond to the client as fast as it can. All the bitrate limit is doing is capping the stream quality, it is not capping how fast you can respond to requests. Lowering the quality will result in smaller chunks, which will transfer faster, but at the end of the day whether the chunk is 5MB or 20MB, it's still going to try to deliver that file to the client as far as it can.

Edit: For example I could see in my logs someone transcoding a 4k remux to a compatible video format, chunk sizes are say 50 MB each and it takes about 2 seconds to deliver. That means they were using ~200 Mbps of upload bandwidth to retrieve that chunk in that amount of time, even though the stream itself is let's say 75 Mbps CBR just to throw a number. It still went as quickly as it could to the client.

Edited January 9, 2025 by Lessaj

[DancingTable 11]

1 hour ago, Lessaj said:

Not necessarily if you limit them from the user page after.

I only get the ability to limit out of network speeds. If I set their IP to be LAN to Emby, it's not out of network, meaning I can't control the speeds anymore.

[Lessaj 467]

18 minutes ago, DancingTable said:

I only get the ability to limit out of network speeds.

Where? Because the Internet streaming bitrate limit is not network speed, it's video bitrate to my knowledge. I used to only have 10 Mbps upload available to me and I had set it to 3.

I'm happy to do some testing when I get home to prove what I am saying. If anything it will confirm if my own knowledge is correct. I have 3 Gbps now so I don't have a cap anymore.

[DancingTable 11]

45 minutes ago, Lessaj said:

Where?

In settings.......

[Lessaj 467]

3 minutes ago, DancingTable said:

In settings.......

I ask again, where? All the bitrate limits I'm aware of relate to the max bitrate of the video and NOT network.

[DancingTable 11]

Internet streaming bitrate limit (Mbps)
An optional per-stream bitrate limit for all out of network devices. This is useful to prevent devices from requesting a higher bitrate than your internet connection can handle. This may result in increased CPU load on your server in order to transcode videos on the fly to a lower bitrate.
This will override the default global value set in advanced server settings.



Again. In settings.

[Lessaj 467]

Technically that's in Network and not Settings but I digress.

Okay I poked around and did some testing and I see now that even though it's mentioning a bitrate limit in the log because it's considered local it's not actually adhering to that setting.

2025-01-09 17:52:22.390 Info App: RemoteClientBitrateLimit: 15000000, RemoteIp: REDACTED, IsInLocalNetwork: True

I apologize for making that mistake, but regardless I can still prove my point either way that even if you limit the stream's bitrate it will still deliver the content as fast as it can. Using Emby Theater in Windows I updated the host file to force it to connect to my external VPS - this will connect to the VPS over a VPN so the flow when requesting data the response would flow from my server -> firewall/gateway in my network (via WAN) -> VPS -> VPN provider -> firewall/gateway in my network (running VPN client) -> Windows machine. I removed the VPN subnet from my LAN networks and limited my user to 15 Mbps from the Users page. Home and internet quality in the app both still set on auto. It appears that this app may default to 7 Mbps with auto, I tried a few different ways to change it and it would show 15 but as soon as I tried to play I could see it was actually doing 7. This limiting of the bitrate forced it to default to my 1080p version but I can still select the 4k and try to play it instead.

2025-01-09 18:06:31.071 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 53889618, max bitrate: 7000000

Evidence #1, per network graph in Task Manager it is spiking to 100 Mbps or higher. My update speed is already set to high so this is as granular of a look as that gets

Evidence #2, per my httpd logs using the size in bytes and duration in ms for each 3 second segment - cut out some of the unneeded info the lines are usually much longer.

[2025-01-09 18:10:38.056] "GET 0.ts Size=1297578 Duration=114
[2025-01-09 18:10:38.179] "GET 2.ts Size=1526019 Duration=28
[2025-01-09 18:10:38.114] "GET 1.ts Size=3587020 Duration=111
[2025-01-09 18:10:38.257] "GET 3.ts Size=2816492 Duration=39
[2025-01-09 18:10:38.267] "GET 4.ts Size=2636936 Duration=64
[2025-01-09 18:10:38.354] "GET 6.ts Size=2840701 Duration=77
[2025-01-09 18:10:38.327] "GET 5.ts Size=3003337 Duration=126
[2025-01-09 18:10:38.462] "GET 7.ts Size=2936278 Duration=38
[2025-01-09 18:10:38.492] "GET 8.ts Size=2268785 Duration=25
[2025-01-09 18:10:38.544] "GET 9.ts Size=2541214 Duration=26
[2025-01-09 18:10:38.556] "GET 10.ts Size=2743852 Duration=37
[2025-01-09 18:10:38.607] "GET 11.ts Size=2016748 Duration=28
[2025-01-09 18:10:38.636] "GET 12.ts Size=2840832 Duration=35
[2025-01-09 18:10:38.695] "GET 13.ts Size=2710330 Duration=81
[2025-01-09 18:10:38.795] "GET 14.ts Size=2605049 Duration=384
[2025-01-09 18:10:39.226] "GET 15.ts Size=2656388 Duration=454
[2025-01-09 18:10:39.664] "GET 16.ts Size=2786167 Duration=416
[2025-01-09 18:10:40.514] "GET 17.ts Size=2729969 Duration=72
[2025-01-09 18:10:40.523] "GET 18.ts Size=2721639 Duration=429
[2025-01-09 18:10:41.738] "GET 20.ts Size=2777056 Duration=62

Using this data above we use the longest duration of 454ms to deliver 2656388 bytes, or roughly 2.53 MB. Let's round it to make the math easy and say it took 0.5 second to deliver, it would take 5 MB/s or 40 Mbps to deliver that. Looking at the other end it took 38ms to deliver 2936278 bytes. The math on this works out to something like 73.7 MB/s, or 589.6 Mbps.

Let's try a higher video bitrate, like 40 Mbps, give the math a fighting chance.

2025-01-09 18:24:00.048 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 53889618, max bitrate: 40000000

[2025-01-09 18:24:55.865] "GET 0.ts Size=2109008 Duration=562
[2025-01-09 18:24:55.899] "GET 1.ts Size=16526083 Duration=765
[2025-01-09 18:24:56.439] "GET 2.ts Size=7738219 Duration=298
[2025-01-09 18:24:56.686] "GET 3.ts Size=8842281 Duration=139
[2025-01-09 18:24:56.814] "GET 4.ts Size=8356282 Duration=85
[2025-01-09 18:24:56.866] "GET 5.ts Size=10680433 Duration=191
[2025-01-09 18:24:57.004] "GET 6.ts Size=10437636 Duration=130
[2025-01-09 18:24:57.081] "GET 7.ts Size=11289313 Duration=203
[2025-01-09 18:24:57.260] "GET 8.ts Size=9033204 Duration=115
[2025-01-09 18:24:57.325] "GET 9.ts Size=6646030 Duration=93
[2025-01-09 18:24:57.472] "GET 10.ts Size=7514816 Duration=70
[2025-01-09 18:24:57.489] "GET 11.ts Size=5660251 Duration=83
[2025-01-09 18:24:57.625] "GET 12.ts Size=5031226 Duration=31
[2025-01-09 18:24:57.684] "GET 13.ts Size=9274932 Duration=116
[2025-01-09 18:24:57.780] "GET 14.ts Size=10061489 Duration=169
[2025-01-09 18:24:57.851] "GET 15.ts Size=10151137 Duration=888
[2025-01-09 18:24:58.705] "GET 16.ts Size=9900009 Duration=888
[2025-01-09 18:25:00.405] "GET 17.ts Size=9800368 Duration=124
[2025-01-09 18:25:00.483] "GET 18.ts Size=10505737 Duration=845
[2025-01-09 18:25:02.883] "GET 20.ts Size=9776564 Duration=553

Again using the data above we use the longest duration of 888ms to deliver 10151137 bytes, a little under 10 MB. This is something like 10.9 MB/s or 87.2 Mbps, and then to cherry pick another large size with a short duration we'll go with 203ms to deliver 11289313 bytes, a little under 11 MB. This is something like 53 MB/s or 424 Mbps.

So, in conclusion, you can limit the video bitrate, but it's still going to try to deliver the content as fast as possible over the network whether the user is remote or not. Depending on the resolution and bitrates of the content that you have, how many users you may have simultaneously, and the limit of your upload speed is why I would recommend treating everyone as local so that they can leave it on auto, and then if they have problems they can adjust the bitrate on their end. Either way it's going to try to saturate the network connection to build an initial buffer, and then request data in spikes - as long as you have the bandwidth to keep up with the requests there will be quiet periods. I was hopeful to be able to cap on a per user basis but I was mistaken about that since they won't be treated as remote. Even if you set a higher limit it's still going to default to the auto of the app so I set 15 Mbps but it still came up as 7. If you leave everyone as remote you could still limit per user or globally so that they can't exceed the cap you set though, I tried to set it to 40 Mbps from my client but it got stuck at 15, though again it was actually defaulting to 7 since it was remote.

2025-01-09 18:59:07.236 Info App: Bitrate exceeds DirectStream limit: media bitrate: 53889618, max bitrate: 40000000
2025-01-09 18:59:07.236 Info App: RemoteClientBitrateLimit: 15000000, RemoteIp: REDACTED, IsInLocalNetwork: False
2025-01-09 18:59:07.236 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 53889618, max bitrate: 15000000

 

Edited January 10, 2025 by Lessaj