Media bitrate exceeds limit

[epical 2]

Hey team

 

I've seen some posts regarding this issue but none of them seem to have answers to what I'm looking for. I recently configured Emby coming from Plex and one of the most annoying things I have to deal with is to constantly ask users to fix their remote streaming quality settings so they don't transcode everything unnecessarily. I've been doing some tests with Emby while using "Auto" in the Max Streaming Bitrate setting under playback on my Nvidia Shield Pro but Emby seems to insist on transcoding some files even if there is plenty of bandwidth and other resources available. If I set the bitrate to 1000 Mbits/sec then everything runs smooth, which has me asking why does Emby transcode the file while on auto?

The file in question:

I don't have any limits configured anywhere else in my network settings or transcoding settings but the log clearly shows there's a limit in place somewhere:

embyserver.txt:2022-03-07 23:39:06.839 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 63787766, max bitrate: 59375000
embyserver.txt:2022-03-07 23:39:06.839 Info App: Bitrate exceeds DirectStream limit: media bitrate: 63787766, max bitrate: 59375000

Why is Emby limiting streaming down to 59375000 bits?

[Abobader 3464]

Hello epical,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke 42078]

HI, I would check the quality setting in the app that you're playing from. What is it set to?

[epical 2]

Hey Luke, thanks for getting back so quickly. In the Emby client I'm running on my Nvidia Shield Pro I'm using Auto. My main goal is for Auto to just work without any limits since all of my users have plenty bandwidth and my server is on a 10G backbone. Having them configure the quality setting is a pain in the a** when you have 40+ users and they all gotta do it on every single device/browser. If I set the quality to 1000 Mbits/sec then everything works fine but I would prefer Auto to just work.

[RanmaCanada 495]

Auto has some serious problems.  I've mentioned it a few times (even with test proofs of it being broken), and the answer is always "we'll look into it".  Part of the problem could be the ISP, either yours, or theirs, throttling web streaming traffic.  I've tried to setup QOS but apparently Emby isn't recognized as an app that uses bandwidth on my server, and everything is just "web streaming".  Plex.tv has it's own entry so I have no idea why Emby isn't recognized.  

[Luke 42078]

1 hour ago, epical said:

Hey Luke, thanks for getting back so quickly. In the Emby client I'm running on my Nvidia Shield Pro I'm using Auto. My main goal is for Auto to just work without any limits since all of my users have plenty bandwidth and my server is on a 10G backbone. Having them configure the quality setting is a pain in the a** when you have 40+ users and they all gotta do it on every single device/browser. If I set the quality to 1000 Mbits/sec then everything works fine but I would prefer Auto to just work.

On a remote connection you may find that sometimes auto is a little conservative and needs to be increased to a specific value. It's something we are working on improving. Thanks.

[rbjtech 5284]

If Auto cannot be fixed (for whatever reason), then a simple server side controlled client 'overwrite' feature would be useful.   

Part of this alternative has already been implemented on the stream limits - so in the example below, I KNOW that this is the reliable stream limit for this users  connection.

If this value exists, could this value be used as an 'overwrite' on the client bitrate calculation ?

btw - I'm aware this is a 'per stream' limit - so maybe take into consideration the max streams as well ?

 

Edited March 8, 2022 by rbjtech

[RanmaCanada 495]

I've had issues with server side/client side stream limits being removed during upgrades.  It's frustrating when you finally find what the user's ISP will tolerate as traffic and then suddenly an update breaks everything again.  Maybe I'm just unlucky?

[rbjtech 5284]

1 hour ago, RanmaCanada said:

I've had issues with server side/client side stream limits being removed during upgrades.  It's frustrating when you finally find what the user's ISP will tolerate as traffic and then suddenly an update breaks everything again.  Maybe I'm just unlucky?

Mine appear to be ok - but I'm on Stable - so I'll know for sure after the 4.7 update .. 

 

[VladTepz 47]

I ran into this issue a while back too "Media bitrate exceeds limit" & tried all the suggestions posted so far, and then some...

What worked for me was to UNcheck "Allow video playback that requires transcoding" in that users "Media Playback" options.
*****(Not saying it's a solution, but might be helpful to try during troubleshooting)*****

Haven't ran into any issues for the past few months since. The user's does require "requires conversion without re-encoding" and all their playback does get remuxed by Emby, but it's an almost nonexistent resource hit to the server, especially compared to transcoding.

Perhaps the need for the video to be remuxed, because of the container in (my case), causes Emby to choose a full transcode by default instead of just a simple remux for some reason?

Edited March 11, 2022 by VladTepz

[CharlieMurphy 92]

Just to be fair, since Plex is mentioned here, the auto setting does the same thing on their platform for me. You have to set it manually on every single client or it will transcode for no good reason.

[DarKni8 41]

This issue is like a plague for Emby. And then when you disable transcoding , the thing wont play simple enough

[ebr 16182]

On 3/8/2022 at 7:59 PM, VladTepz said:

What worked for me was to UNcheck "Allow video playback that requires transcoding" in that users "Media Playback" options.

We do NOT suggest doing that as it is very likely to lead to playback problems.

[VladTepz 47]

17 hours ago, ebr said:

We do NOT suggest doing that as it is very likely to lead to playback problems.

Agreed. Sorry about that.

It was meant as a suggestion for troubleshooting this particular issue & edited my reply to reflect that.

[epical 2]

All in all it would be great to be able to disable any limits server-side, all my users are on 1Gbit connections and no ISP's in my country throttle media streaming at all so having Emby implementing a "fake" bitrate limit while using the automatic profile is moot for me

[CharlieMurphy 92]

I would like that too but I gave up on asking for it from Plex or Emby years ago. I think it's a policy thing. If you direct stream everything you could just use Kodi or VLC. From the standpoint that the point of Emby is the ability to transcode files to play on slow connections and devices that can't play the file in it's native format, it makes sense I guess.

Instead I made pic collages for Plex client settings to send family members when my Tautulli script kills their stream for transcoding. The fun part is that the interface is so different on different devices that I need a lot of collages. I also tried keeping versions of files that wouldn't need to be transcoded. That seems like a solution but it can't actually work. Plex default is 2mbps on Android and 4mbps on Roku. If you make the alternate files at 2mbps, then Roku will force the bigger file to transcode to 4. If you choose 4mb, Android TV will ask for a transcode to 2. Literally the only solution over there is a Tautulli script that kills the stream and tells them to ask for help. Also, the killstream message doesn't actually come up on every platform (LOL).

I'm just sharing this to say it probably isn't an oversight. We are just in this stupid limbo of devices that won't play popular codecs and people who have bad WiFi.

[CharlieMurphy 92]

My last compromising idea was to ask the user to set the bitrate in the client on the first run. If a user doesn't know what that means they will leave it at default or ask the server admin for instruction. That seems better to me than causing unneeded transcodes. Nobody liked that idea.

Edited March 13, 2022 by CharlieMurphy

[Luke 42078]

We'll look at improving it. Thanks for the feedback.