Auto Transcoding Isn't Very Auto

[Lessaj 467]

It's not just iOS btw, it's all the apps AFAIK. I just tested with my android phone on cellular data after removing the subnet from the list and it's limiting to 4 Mbps on auto, I could see it in the logs.

[CoastInTheFog 1]

4 minutes ago, Lessaj said:

It's not just iOS btw, it's all the apps AFAIK. I just tested with my android phone on cellular data after removing the subnet from the list and it's limiting to 4 Mbps on auto, I could see it in the logs.

Thanks for your response @LessajSee? Not that hard for someone else to just test it instead of all the other crap I got. Especially the fact that 4mbps keeps coming up exactly confirms there's some hard coded limiter someplace. Software does not work as expected. I can move on now.  

[Happy2Play 9780]

Yep still need this.

 

[Happy2Play 9780]

Someone else would have to break this down on its actual meaning but think most clients are using it.

    function detectBitrateWithEndpointInfo(instance, _ref) {
        return _ref.IsInNetwork ? 2e8 : function () {
            if ("undefined" != typeof navigator) {
                var connection = navigator.connection;
                if (connection) {
                    var downlink = connection.downlink;
                    if (downlink && 0 < downlink && downlink < Number.POSITIVE_INFINITY)
                        return downlink = downlink * 1e6 * .7, downlink = parseInt(downlink);
                    if ((downlink = connection.downlinkMax) && 0 < downlink && downlink < Number.POSITIVE_INFINITY)
                        return downlink = downlink * 1e6 * .7, downlink = parseInt(downlink)
                }
            }
            return null
        }
        () || 4000002

 

[CoastInTheFog 1]

Well there you go. How in the world did you find that?

I'm not good with code, but I fed it to ChatGPT and this is what it said:

"The function determines the network bitrate based on whether the user is within a specific network or using the browser's network information. If network information is available through the navigator.connection API, it calculates the bitrate based on the downlink or downlinkMax properties. If these properties are not available, or if the user is within the network, it returns predetermined values (200 Mbps for in-network or 4 Mbps as a fallback)."

My interpretation is that there is an attempt at detection of downlink speeds for outside the network. The code to determine whether a device is within network or outside the network obviously works, however it seems the code to detect the downlink speed does not. Therefore it defaults to the fallback at 4mbps which is exactly what we're seeing.

Based on your other post, it seems like the downlink speed detection has been broken for a while, and at some point in the last couple of years they bumped the fallback from 1.5mbps up to 4mbps, but never fixed downlink detection in the first place. Why they didn't, and whether they could is of course beyond me.

[Happy2Play 9780]

Technically each client will be slightly different as they have different in network values as that if from the web client.  But is in the apiclient.js.

 

[ebr 16176]

5 hours ago, CoastInTheFog said:

" NOT some version of "If it's not working for you, don't use it." @ebrWhat is wrong with you?

My point is that the auto setting can only be so good and you have a special situation.  If, instead, you were actually on a mobile network and had less bandwidth, the auto function would determine that and use a value that would work well in that situation.

You have a very specific situation and seem to know for sure what the capabilities of your connection are.  In that instance, you should use the specific quality setting that works best for you.  That is why those settings are there.

[CoastInTheFog 1]

3 minutes ago, ebr said:

My point is that the auto setting can only be so good and you have a special situation.  If, instead, you were actually on a mobile network and had less bandwidth, the auto function would determine that and use a value that would work well in that situation.

You have a very specific situation and seem to know for sure what the capabilities of your connection are.  In that instance, you should use the specific quality setting that works best for you.  That is why those settings are there.

My special situation? Where I try to play videos back remotely? You didn't read any of the thread, did you? What are you guys doing over there?

[visproduction 315]

13 hours ago, Happy2Play said:

 function detectBitrateWithEndpointInfo(instance, _ref) {
        return _ref.IsInNetwork ? 2e8 : function () {
            if ("undefined" != typeof navigator) {
                var connection = navigator.connection;
                if (connection) {
                    var downlink = connection.downlink;
                    if (downlink && 0 < downlink && downlink < Number.POSITIVE_INFINITY)
                        return downlink = downlink * 1e6 * .7, downlink = parseInt(downlink);
                    if ((downlink = connection.downlinkMax) && 0 < downlink && downlink < Number.POSITIVE_INFINITY)
                        return downlink = downlink * 1e6 * .7, downlink = parseInt(downlink)
                }
            }
            return null
        }
        () || 4000002

Right, so what is probably going on here is the typeof navigator fails to find a browser type, perhaps it is Apple iOS or that it has to sense the browser through a 5G packet that encapsulates the TCP packet.

...
if ("undefined" != typeof navigator) {
...
			}
            return null
        }
        () || 4000002

The function attempt to find the browser type (navigator) has a bad reputation of failing, especially with Apple iOS browsers, particularly Safari.
See: https://stackoverflow.com/questions/63303001/mediadevices-getusermedia-support-for-ios

If you look closely to see that if the browser is undefined, then the value returned becomes 4000002.  This is probably the reason the encoding locks into 4000 kbps.  Fix the recognition of the browser type or change the 'if' parameter to some other test and then you would get the inner part of the code to set the encoding speed for your iOS 5G connection.

This inner part looks at a connection downlink value uses 70% of that value as the safe encoding speed that probably will NOT cause the playback to stutter.  Someone either guessed this value or tested it.  You could change .7 to .9 or even .95 and see what happens. Sometimes the conservative setting is to cover someone playing back media in the middle of nowhere.

Of course adjusting inside a .js is really for Emby dev to do, because if we customize something like this, then it will just disappear on the next update.  So Emby dev have a close look at the typeof navigator.  Try to fix it for iOS browsers through 5G connections or change the approach to some other test.  Maybe allow the .7 to be adjusted upward if users are on a fast network in the city.  

In summary: My guess is that the browser through iOS and 5G just comes up undefined, because the the javascript typeof navigator is not good for all situations.  We probably need a better method.  This undefined clamps the encoding down and that causes the original problem in this post.

The .7 multiple quality setting in the code was also mentioned in an earlier forum post. https://emby.media/community/index.php?/topic/125404-auto-quality-issues-in-web-app/&do=findComment&comment=1338811

Hope that makes sense.

 

[CoastInTheFog 1]

@visproductionLessaj above mentioned it's doing the same thing on Android, so this might not be just an iOS problem. Maybe the opposite approach is needed: Where DOES it work? I have yet to see someone comment "works for me!"

[yocker 1247]

Tested on my Android phone with auto on just now, it picks the highest quality possible every time.
This might not be a good test though as i live practically right next to a 5G tower.

[visproduction 315]

On 8/28/2024 at 8:08 AM, CoastInTheFog said:

@visproductionLessaj above mentioned it's doing the same thing on Android, so this might not be just an iOS problem. Maybe the opposite approach is needed: Where DOES it work? I have yet to see someone comment "works for me!"

Right, and this .js "if" function that maybe doesn't work, like the reason I suspected,  would result in the problem happening for everyone in any OS.  Testing it is tricky, because like Yocker posted, it worked for him but maybe his browser version was recognized by the .js function and then other browsers get the undefined browser type result and this causes the issue. 

It sort of takes code dev person to go in and monitor with browser types or add comments to the code to see which browser fails.  We can't do that on the outside.

 

 

Edited September 7, 2024 by visproduction

[CoastInTheFog 1]

Thanks @visproduction yes I think that makes sense and I appreciate your explanations. Just to reiterate one thing: I was doing testing on 5G because that's the outside network I have available to me when I'm at home. However, someone I'm trying to share my library with is using it with WiFi at their home and having the same issue. I haven't been able to test from other WiFi networks to really confirm, but I'm skeptical that it's related to 5G at all and not just access from an outside network. 

A bit separately from trying to diagnose: What's up with Emby devs on things like this? Most other forums I've been in devs of a product will engage at a meaningful level in the forums OR there's a policy that only bug reports get their attention. Since this issue has come up before, it seems they know about it. It would be nice to know from them why it can't be fixed.

[visproduction 315]

Coastin,

You have to recreate the issue first.  Maybe all systems they test on do not include a Safari browser or some 5G speed and packet issues factor.  If you cannot see the problem on your test system, the ability to fix it essentially stops.  Ideally, a QA person would test 'cross browsers 'and possible with 5G in demanding network signal areas, to recreate the issue.  Then, troubleshooting to see that maybe the 'if' function that gets the browser type, returns 'undefined' for a lot of browsers and maybe also for 5G networks that don't process the 'if' request fast enough which may cause a time out.  This perhaps causes the code to flip to browser 'undefined' and the issue happens.  

Until you suspect what is causing the issue, it cannot be fixed.  Often, there are limits to QA testing for production releases.  I work in this field and I am often told by companies to simply not test for Safari, at all.  To be clear, I am not speaking about Emby.  These OTHER clients of mine are just not willing to pay for support costs for some browsers.  Safari and Microsoft Edge have such a bad reputation and their global use is under whatever use percentage... could be less than a few percent worldwide.   Clients just refuse to allocate money to support these lesser used browsers.  I've also been told to not even test for tablets.  From inside the business, it's obvious that supporting everything, costs a lot of money.  In the US, adding support for Safari and tablets to a website might run over $100K a year after paying for everyone's time to tweak the site to work for everything.  Overseas support would cost less.

Anyway, you asked a bit more of what might be the reason of what takes so long to fix issues.  I would just say, it's hard to fix something when you cannot replicate the problem.  No one above mentions which browser they are using.  If my suspicion on the browser type code failure is correct, then the problem has to do with the browser or also a TV App.

Hopefully, that makes some sense.  Remember I am also outside the Emby team.  These are just guesses and I have no knowledge if some testing for a particular browser is not already being done by Emby.  This is just info regarding industry trends and steps to fix things.

Edited September 7, 2024 by visproduction

[guunter 49]

@CoastInTheFogi just tested on 5g on my iPhone and I seem to be direct playing using auto. I am on the beta channel for my server though.

 

edit: nvm I forgot I had my on demand wireguard vpn turned on so that’s why it direct played. It did do 1080p 4mbs once I turned it off

Edited September 8, 2024 by guunter

[CoastInTheFog 1]

@guunterSo close! I had started looking into the beta changes, couldn’t find anything relevant, and then saw your edit. 

[guunter 49]

4 minutes ago, CoastInTheFog said:

@guunterSo close! I had started looking into the beta changes, couldn’t find anything relevant, and then saw your edit. 

Yeah my bad. I was like wait let me give my two cents and remembered that I'm always on my home network

[Jdiesel 1431]

I was struggling with this for a while too in the end I just accepted at most out of network devices would be stuck at 4mpbs. I try my best to get people to manually set the quality but it's a losing battle. It's very annoying but there seems to no desire to improve this.

 

[guunter 49]

9 hours ago, Jdiesel said:

I was struggling with this for a while too in the end I just accepted at most out of network devices would be stuck at 4mpbs. I try my best to get people to manually set the quality but it's a losing battle. It's very annoying but there seems to no desire to improve this.

 

Hey it’s better than plex’s 720p at least

[Jdiesel 1431]

1 hour ago, guunter said:

Hey it’s better than plex’s 720p at least

Is that really the case? Last time I used Plex the auto setting seemed to work reasonably well. 

I get the reasoning for it, its better to just have things work by default than require adjustments to get things working. I just wish I could manually set the fallback bitrate myself server side. Bumping it up to 5 or 6 mbps would eliminate almost all unnecessary transcoding in my case.

[guunter 49]

1 hour ago, Jdiesel said:

Is that really the case? Last time I used Plex the auto setting seemed to work reasonably well. 

I get the reasoning for it, its better to just have things work by default than require adjustments to get things working. I just wish I could manually set the fallback bitrate myself server side. Bumping it up to 5 or 6 mbps would eliminate almost all unnecessary transcoding in my case.

I just mean the default is 720p 2mb and trying to get people to change it was 50/50. I’ll take the 1080p 4mbs on auto. It don’t really matter to me because I’m not the one watching it and my server can handle transcodes easily.

[yocker 1247]

Done a little testing from remote devices at different locations.

Crappy low powered Android box - 1080 20Mbps
Android phone - chooses highest
Samsung TV - 1080 - 6Mbps
Browsers - choose highest no matter what browse, computer or phone.

Don't know if it's of any help but thought I might as well post it here when I had tested it anyway.