Online Streaming Bitrate limit wrong calculated

[Happy2Play 8252]

5 hours ago, Painkiller8818 said:

My logs are in the beginning of this thread already and you already responded to it.
So i think everything is here

Sorry but that only applies to post 1 not any of the other examples.  Also I believe as @rbjtech mentioned there is a Hardware vs Software factor also but the devs will have to comment on that.

[sooty234 266]

I mean, seriously. If the default doesn't work (which it doesn't) are  we supposed to start trying the thousands of possible configurations to see what does and doesn't work and under what circumstances? The professor did it, with the candle stick in the library.... Or was it really the colonel with lead pipe....???? Hmmmm...??? We can't possibly provide logs for each variation that doesn't work. That would take weeks if not months of continuous testing to find out. Come on guys! Look at the big picture. 

[Happy2Play 8252]

Only one log has been provide and many different example contain nothing so all anyone can do is guess, I can say I am not seeing this same behavior except on clients that use Auto and always get lower rates do to the Auto algorithm.  So without all the information to go with a example there can not be any true answer given.

[Carlo 4330]

sooty234 but it does work as designed.  There seems to be a misunderstanding of what AUTO does.  You and others think it should maximize the bandwidth used up to the limit but that's not what or how it was designed.  It trys to choose a moderate low bandwidth that should work for the media to maximize the available bandwidth for ALL USERS.

Of course if you don't like what it chooses as a default you can override it or set new client defaults.

So it's not broke as it obviously chooses a bitrate that is under any of the limits.

If this isn't the functionality you want then make a feature request to change it to always try to maximize the available bandwidth each user is given.  It's double edged sword so to speak because other users won't like this and will have to readjust if possible their settings or purchase more bandwidth which isn't always possible. A tremendous amount of people run on system like Comcast and you only get 10 to 15 Mbps of total uplink so having Emby choose the low amount is perfect for them.

Edited August 5, 2020 by cayars

[sooty234 266]

IT ABSOLUTELY DOES NOT WORK! And stop trying to teach me s***! 

( I must breathe.... Whooosaaaahhh....) 

Ok I'm back. I had to re-write this a few times.

Well, this is pointless. As usual. Nothing gained, so I shall go and do other things...

[Carlo 4330]

sooty234 Am I correct in assuming you want AUTO to use as much bandwidth as possible up to the limit?

That it doesn't do this you consider it broke?

Is that a fair assessment?

[Q-Droid 634]

3 hours ago, cayars said:

sooty234 but it does work as designed.  There seems to be a misunderstanding of what AUTO does.  You and others think it should maximize the bandwidth used up to the limit but that's not what or how it was designed.  It trys to choose a moderate low bandwidth that should work for the media to maximize the available bandwidth for ALL USERS.

Of course if you don't like what it chooses as a default you can override it or set new client defaults.

So it's not broke as it obviously chooses a bitrate that is under any of the limits.

If this isn't the functionality you want then make a feature request to change it to always try to maximize the available bandwidth each user is given.  It's double edged sword so to speak because other users won't like this and will have to readjust if possible their settings or purchase more bandwidth which isn't always possible. A tremendous amount of people run on system like Comcast and you only get 10 to 15 Mbps of total uplink so having Emby choose the low amount is perfect for them.

I get what you're saying but this simply isn't the case. Yes, the Auto setting will most often choose a bitrate lower than the server max. However, this is not due to some conservative calculations. Take Firefox for instance. It would ALWAYS set the bitrate to 1500000 no matter what. At least until recently when that value was changed and I believe it was upped to 3500000. Don't quote me on the actual value but I know there are threads where this was discussed.

I understand there is some vudu and a fudge factor in the estimate but the bottom line is the server dictates the max and the client can report what it can handle. The issue is the client side bandwidth report is kinda broken when using Auto. I myself have pre-converted titles at bitrates below (5mbps) my server max (6mbps) just for the purpose of direct browser playback yet more often than not it still transcodes because Firefox reports too low and I can't get my one remote user to stop using that browser. So I've told her to max out her bitrate settings so that my server streams the right version.

I don't have the answer for client bandwidth reporting because I don't know what mechanism is used to come up with the values. But it is not reliable and it causes more headaches than it prevents...IMO.

 

Edited August 6, 2020 by Q-Droid

[Carlo 4330]

On 8/4/2020 at 10:15 AM, ebr said:

That is going to depend on a lot of other factors and our auto algorithms have to be conservative because the most important thing is that the item plays smoothly.  If we get too aggressive with the auto calculation it is possible that playback will stutter or not work at all because we pushed the limit of what our bandwidth test told us.

If you are certain that both your clients and server can always handle a certain bitrate, then that is why we also allow you to set the max value in the apps to a specific value.  Of course, if you do this it is possible there will be problems depending on network conditions and server load at any particular point in time.

 

On 8/2/2020 at 5:15 PM, Luke said:

This value is a limit, it is a maximum. Setting it to 8 mbps doesn't mean they will get 8 mbps. It means they won't go over 8 mbps no matter how they have configured the quality setting from within the app they are using.

If you set the limit to 8 mbps on the server, and they set 6.5 mbps in the app, then they will get the lower of the two values.

 

On 8/2/2020 at 6:40 PM, Luke said:

I don't really understand the problem you're trying to report. You set the limit on the server to 8. The client has a limit of roughly 6.5, which could either be set manually or could come from the Auto value.

So 6.5 is lower than 8 and that's why you got 6.5.

 

On 8/2/2020 at 7:09 PM, sooty234 said:

This process really doesn't work well. I was just fooling around with it. 

Server user limit = 6 Mb/s  +  in app limit = 6 Mb/s   =   Server transcodes to ~2.5 Mb/s

Server user limit = 6 Mb/s  +  in app limit = 120 Mb/s  =  Server transcodes to ~2.5 Mb/s

Server user limit = 6 Mb/s  +  in app limit = auto   =   Server transcodes to ~2.5 Mb/s

Server user limit = no limit  +  in app limit = 6 Mb/s   =   Server transcodes to ~2.5 Mb/s

Server user limit = no limit  +  in app limit = 120 Mb/s  =  No transcoding, and movie direct plays at 10+ Mb/s

Clearly my bandwidth isn't an issue. And bitrates confirmed in external player.

All worked perfectly respecting limits and auto choose a bitrate under the limit.

[Happy2Play 8252]

See @softworkz replies in this topic.

 

 

[Painkiller8818 203]

11 hours ago, cayars said:

sooty234 Am I correct in assuming you want AUTO to use as much bandwidth as possible up to the limit?

That it doesn't do this you consider it broke?

Is that a fair assessment?

Ok but i think than it should be more clear, because this is really what People think it does. I came from Plex and thats exactly what this function does because i don't always have the chance to get physically to the Client Device to set the Bandwidt there and also a Client User who isn't tech specific doesn't think about that, he is just opening the browser or the app and start to stream without checking the settings, if the language is correct the world is ok for them.

This should really be something a serveradmin has control about.

This is something The Server should handle out for the Client if i set a limit.

My Understanding of this (and i am an IT guy and programmer)  is that "Auto" checks the Clients Internet, and if it is able to get the Limit i set on the server, it is very close to this value. There should be no way, a Client set limit could overrule my Serverside set 8MBit Limit for "THIS USER" but my tests are showing that the Client on Auto get way less than i set and the clients internet can, and if i set the Server to 8MBit limit "FOR THAT USER" and the client sets a higher limit, he can overrule the limit.

So maybe this Function should be checked or more specified in the decription

Maybe we could get an answer from a dev or an admin to have a nice and friendly discussion about that instead of bouncing the problem around with phrases like "thats not how it work, we need more logs etc."

I already replied to @Luke if there is something more he needs from me or if some logs are missing but i didn't get an answer to that.

I really would like to find a solution and a user friendly way, i can manage my Users instead of telling who's fault this is and the client needs to configure the app etc.
My Friends and family aren't tech guys and i am happy if they can turn on the device so please don't tell me they should all configure their Apps and if they use a tablet don't forget to do it again, and on the phone etc... they are just user

Thanks

PS: This is what @softworkz wrote about that, and i am using hardware transcoding:

 

Edited August 6, 2020 by Painkiller8818

[Carlo 4330]

I kind of have the feeling that it for the most part works as designed but maybe not how users want it to work which are two different things.  From a current design standpoint it seems like it tries to use the lowest bitrate it thinks will work. GPU vs CPU process differently and size will often be different.

What I think users want/expect is for auto to choose the highest quality it can that fits any limits imposed (server global or user max) as well as available bandwidth the client has. Ideally you would have a new setting for each user.  There would be the standard Max bitrate we have now that determines the max allowed direct play or direct stream (no transcoding) bitrate, but also a new Transcoding Target Bitrate.  So if the file can't be direct played the client would ask for the largest size that makes sense and the server could limit it back down with the new transcoding target setting.

Edit: So you could allow 12mbps for direct stream or play to avoid transcoding but if transcoded use a max of 8 mbps.

That would likely give far more control to the admin as well as make the client AUTO function more like how people think it should work.

Edited August 6, 2020 by cayars

[Painkiller8818 203]

23 minutes ago, cayars said:

I kind of have the feeling that it for the most part works as designed but maybe not how users want it to work which are two different things.  From a current design standpoint it seems like it tries to use the lowest bitrate it thinks will work. GPU vs CPU process differently and size will often be different.

What I think users want/expect is for auto to choose the highest quality it can that fits any limits imposed (server global or user max) as well as available bandwidth the client has. Ideally you would have a new setting for each user.  There would be the standard Max bitrate as well have now that determines the max allowed direct play or direct stream (no transcoding) bitrate but also a new Transcoding Target Bitrate.  So if the file can't be direct played the client would ask for the largest size that makes sense and the server could limit it back down with the new transcoding target setting.

That would likely give far more control to the admin as well as make the client AUTO function more like how people think it should work.

Exactly, it would be great to see something like that in an update soon because i think a lot of people think thats how this function is working, and so it is confusing.