Reducing bitrate due to quality setting

[Guest]

Hello:

I have a user currently streaming and noticed that the stream is being transcoded due to quality setting. I am on 1 gig fiber and don't have a limit configured.

I also verified he does not have a limit set.

He checked and playback shows quality is set to auto. He confirmed he's seeing the same message.

Why?

Edit: he is also on 1 gig fiber. We both checked and we're getting high bandwidth and low latency.

Edited June 25, 2023 by andrewds

[Q-Droid 989]

Auto detection is unreliable and mostly gets it wrong. It's been this way forever and I've seen it detect a max of 1500000 on my LAN. What I recommend to most is they set their server to the highest remote upstream bitrate they want to allow and the clients to the highest downstream bitrate they want use. Match their broadband service if desired or in your case the max bitrate in the list. The server will use the lowest of the two values as the bitrate limit.

 

[ebr 16184]

1 hour ago, Q-Droid said:

and I've seen it detect a max of 1500000 on my LAN

Hi.  The auto setting doesn't do any detection on a LAN.

9 hours ago, andrewds said:

Edit: he is also on 1 gig fiber. We both checked and we're getting high bandwidth and low latency.

At the time he played this item, it is possible something was happening either on your server or his network or somewhere in between that caused the bitrate test to come back low.  Is it repeatable?  He can try setting the bitrate manually in the app and see if that works well for  him.

[Q-Droid 989]

2 minutes ago, ebr said:

Hi.  The auto setting doesn't do any detection on a LAN.

I understand that. I was simulating a remote connection thru my reverse proxy.  The connection was direct from wired PC to wired reverse proxy endpoint that is on the same host as the Emby server, all on the same LAN switch.

 

[Luke 42079]

HI, is you find that auto on the remote network is too conservative, try bumping up the quality setting manually and see if that helps.

[Guest]

Ok, so this is expected behavior. Thanks.

[rbjtech 5284]

13 hours ago, andrewds said:

Ok, so this is expected behavior. Thanks.

I don't know about expected behavior, but it is the known behavior yes. 

I expect it to not be an issue on high speed internet services, but it doesn't work as advertised - ie it is not Auto ..

[Guest]

22 hours ago, Q-Droid said:

Auto detection is unreliable and mostly gets it wrong. It's been this way foreve

 

You agreed with Q-Droid's statement (+1) so at the least you believe his statement is correct. One of the product architects is suggesting a workaround for the behavior I'm observing rather than acknowledging that it is behaving in a way other than intended. It seems that it is expected behavior.

That's fine. I simply wanted an explanation. It's (another) thing that can be handled with configuration and/or training.

 

[rbjtech 5284]

2 hours ago, andrewds said:

You agreed with Q-Droid's statement (+1) so at the least you believe his statement is correct. One of the product architects is suggesting a workaround for the behavior I'm observing rather than acknowledging that it is behaving in a way other than intended. It seems that it is expected behavior.

That's fine. I simply wanted an explanation. It's (another) thing that can be handled with configuration and/or training.

 

Maybe sematics - but you have described your environment, 1 gig internet connections at each end with presumeably a decent low latency tcp connection.  You are attempting a tiny 4Mbit/sec HLS stream - my (and your, and anybody likely reading this) expectation is that this would NOT transcode due to bandwidth issues.

Luke suggesting the Auto value is too 'conservative' (when it is using a max of only 5% of the available banwidth..) is simply ignoring the problem - they know Auto needs work - so suggesting a workaround is just another way of saying we are aware of the issue ...