Client determining bitrate?

[bitmap]

This is not a feature request, though could easily creep towards one. Right now it's just a curiosity as to how the current design came to be... 

As it stands, clients can request a lower bitrate manually. Has there ever been discussion or attempts at having clients automatically requesting a bitrate they're capable of supporting? For instance, I travel frequently and bring a travel Roku with me. Hotel internet sucks much of the time and I'm either on < 3Mbps Wifi or I'm using my phone as a hotspot, both of which require me to artificially restrict the bitrate by setting the user's limit lower since Roku doesn't provide this option via UI.

I know that true adaptive streaming is dynamic and constantly monitoring the capability of the client (plus generally has several pre-encoded tiers to choose from), but is it feasible to have a system where part of the streaming initiation process is a network check of capability, setting that as a bitrate cap for the transcode (or forcing transcoding if direct play was possible previously), then if network issues such as frequent buffering take place, re-initiate that network check, set that cap again, etc...? Or is this something that could possibly break down very easily and cause instability? Or maybe it's too complex to insert into the current process of how streaming/transcoding is initiated?

For me, it's not that big of a deal, but it's kind of a quality of life improvement that could make a big difference for folks that could be enabled/disabled as a feature flag. Again, not in "feature request" territory, just in curiosity around why any kind of adaptive measures haven't been put in place.

[Deleted User]

i am going to be a little out of my depth regarding what jellyfin does but adaptive is completely possible when using dash

here is a write-up - https://blog.zazu.berlin/internet-progra...fmpeg.html

and it has already been feature requested to support dash - https://features.jellyfin.org/posts/1757...sh-support


it could be implemented in a client side that the client decides what it's bandwidth limit is based on current conditions but if those conditions happen to be low then you are stuck low (same issue arises from premium streaming services Prime, Hulu, Netflix)



at minimum i think you would be able to request the setting on your roku client to select bandwidth - android already has this setting in the client (not for adaptive, it is just a setting)

[bitmap]

To be clear -- and this is murky because of the language I'm using -- I'm not advocating for completely adaptive streaming. I think that might be out of scope. But better handling of low-bandwidth or poorly-networked clients seems like a good target, as stuttering video due to poor connectivity is a common issue that folks experience and remote network troubleshooting is difficult at best.

Most of what I'm wondering about is the history of how we got to the current implementation of what seems to be "user knows best". That's audio, video, and bit rate selection, which leads to all kinds of issues. I don't necessarily agree with other posts that Jellyfin should automate ALL of this, nor that features should obfuscate media selection through this sort of feature, but a bit of intelligence in bit rate selection (while it might increase transcoding) would offer a better end user experience.

[Deleted User]

i read your initial post clearly, perhaps it was mine that was not

what i was suggesting was an additional not a replacement for the current mechanisms in place

my thought would be along the lines of

Client Settings - 120M, 100M, 60M, Auto


where i would never select Auto on anything on the same network but perhaps in your use case i would have Auto set on a portable roku by default because i will not always know the available bandwidth

[bitmap]

No, I think you were clear. I'm just worried somebody will come in and believe I am suggesting a full-blown Netflix/Youtube/Hulu adaptive streaming solution. Which I'm neither suggesting nor would that be the end goal were I to submit a feature request...

[thornbill]

This already exists as a feature! It can be inaccurate at high bitrates though and I don’t know if Roku specifically implements it. Android TV ended up disabling it by default because it would often produce inaccurate values leading to more transcoding.

[bitmap]

Interesting! Any idea what led to inaccuracies or where (approximately) this exists in the code? Been thinking about where I could possibly start with a project for October and, while this sounds too complex for a first contribution, I'm interested, and that tends to lead me down the right path...

[thornbill]

I believe part of the issue was that for higher bandwidth values, you need to request large amounts of data to test which can be slow and the Android TV app was only testing on app startup... it does look like some of the server side limitations have been fixed though.

You can find some more context here: https://github.com/jellyfin/jellyfin-and.../pull/1010