Dynamic user bandwidth allocation?

[dakazze]

Hey guys!

Sadly it looks like it will take another year until we finally get fiber here and for the time being I am stuck with 50 MBits upload. Since I only have 2-3 users outside of my LAN and not too much concurrent use, limiting their upload to 20 MBits has been working fine but thinking about ways to make the most of what I got I came up with this concept and I would appreciate some input for the jellyfin side of things (API possibilities, etc.):

So my plan is to build a node or python daemon that basically has 2 main components.

1. Talk to openWRT:
Keep asking the openWRT router about the demand for upload bandwidth outside of Jellyfin and if I am super motivated, it might dynamically change SQM settings.

2. Talk to Jellyfin:
Keep asking Jellyfin how many users are streaming outside of the LAN and dynamically limits upload bandwidth for each remote user.

This way a single streaming user can have 100% of the bandwidth as long as there is no other demand for it. When a second remote user starts streaming, both get an equal share of the bandwidth and when there is high priority demand from my office PC I can still ensure that both remote clients still have a good minimum share of the cake to stream their stuff.
This way the upload bandwidth I have available is always utilized as good as possible and my users get the best possible quality all the time, only getting throttled when actually needed.


I would really appreciate every bit of input:

• Does something similar already exist?
  
• What do you think about this idea/approach?
  
• Is there some kind of dynamic bandwidth allocation already implemented in Jellyfin or only the static limit?
  
• Is there anything speaking against this idea?
  
• Does the API already support getting the info from Jellyfin (amount of remote users currently streaming) and updating the bandwidth limits for each user?
  
• I could build a version that skips the openWRT implementation so it only allocates bandwidth dynamically based on a set value and therefor can be used by everyone. Do you think there is enough demand for a feature like this?
  

Thank you very much for reading all of this!

[akepound]

Your idea of a daemon that dynamically checks both OpenWRT and Jellyfin states is solid. For Jellyfin, the API does expose session info (/Sessions) which includes whether a user is streaming, their IP (LAN or WAN), bitrate, etc. So tracking remote streaming users in real time is totally doable.

[dakazze]

Thank you @akepound !

I just finished studying the API a bit and it looks like everything I need is already in place.
The only important piece of info I am missing (for now) is what happenes after changing the bandwidth/bitrate limit mid session. Does anyone know if it is applied right away mid-session or if it would take a session restart for the change to take effect?
If it does not work mid session I would have to figure out a way to make the process as seamless as possible.

[Venson]

no a bitrate change mid-session does not change a stream in progress

[dakazze]

no a bitrate change mid-session does not change a stream in progress

Thank you very much for this info! 
I already built the framework for my little daemon and it is already getting active sessions, checking their IPs, getting and setting the bandwidth for each user.

Applying the changes mid session proofs harder than expected though, so I would be grateful for any idea that might help.
For now I am using the playing/stop endpoint to force stop a session which is then automatically resumed but it is a ~3 seconds interruption that is flashing the episode selection for ~1 second which is far from seamless.

(edit: almost finished with a first fully working version. I already prepared a github repo and will share it once done)

[Efficient_Good_5784]

Considering that the server stops the current ffmpeg process and creates a new process with the updated settings, maybe making it launch a new ffmpeg process while the old one is still running can solve the issue.

Then, it would just be a matter of timing the new transcode to align with the old one, switching to the new one, and finally deleting the old process when done.

[dakazze]

Considering that the server stops the current ffmpeg process and creates a new process with the updated settings, maybe making it launch a new ffmpeg process while the old one is still running can solve the issue.

Then, it would just be a matter of timing the new transcode to align with the old one, switching to the new one, and finally deleting the old process when done.

Thanks for taking the time to chime in!

I already tried via ffmpeg but for some reason it did not work out. I think it was because there is only a ffmpeg process when transcoding so updating users in a direct play session would not work.

With a bit of tuning I might get this working without it being too intrusive:
- change bandwidth limit
- get current episode and timestamp
- stop playback
- start playback
- jump to timestamp

All of this is already working in my current build but it somehow is pretty hard to really allign the timestamp correct. Another unforeseen challenge is getting a good reading of jellyfins outgoing traffic (excluding streams of local users) due to flow offloading but I already have a few ideas on how to get a reliable reading on that.