Auto Transcoding Isn't Very Auto

[CoastInTheFog 1]

Just got Emby set up for the 1st time on Ubuntu server and playing around with the different settings. I'm noticing for transcoding on remote devices, namely an iPad, and iPhone, and a Macbook Pro, the auto setting for quality doesn't really do anything. No matter the movie, it's always transcoding at 1080p 4mb.

I have transcoding enabled and working on a i7-8700 CPU. My internet is 1gb symmetrical. Testing is being done at a C band 5G location on my iOS devices where I can speedtest at 500mbps. I do not think bandwidth is the issue. I can set speeds at 4k 200mbps and it will direct play 80mbps 4k dolby vision movies without a problem.

I even went to the extreme of routing the traffic on my Windows desktop through an external VPN so that it can only reach my Emby server from the outside, albeit at around 200mbps. Still, the max auto will give me is 6mpbs.

So what's the deal with this auto thing? Does it do anything except transcode the video at the same low quality every time when I'm away from my home network? 

[Abobader 3464]

Hello CoastInTheFog,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[CoastInTheFog 1]

Hmm, after searching around in the forums a bit, it seems this has come up many times over the years but it's not being resolved by Emby and they don't plan to fix it. If anyone has any other info I'd be interested.

[ebr 16176]

1 hour ago, CoastInTheFog said:

Testing is being done at a C band 5G location on my iOS devices where I can speedtest at 500mbps. I do not think bandwidth is the issue.

Hi.  If you are positive this is the case, just set the quality in the iPad app to what you desire.

[CoastInTheFog 1]

1 hour ago, ebr said:

Hi.  If you are positive this is the case, just set the quality in the iPad app to what you desire.

You are basically saying "if it's broken, don't use it." I guess I was hoping for a bit more than that.

Yes, I am certainly capable of setting the quality manually according to the bandwidth that is available wherever I am with an iPad. I could constantly run speed tests not just to a geographically distributed system like speedtest.net, but to the speed test server I host on my own network, and then set the quality in the app to a level appropriate to my current connection so that the video I'm watching is transcoded at a level that does not cause stuttering, but does not present at an unnecessarily low quality either.

The thing is, Emby is not for me, and I will never use it. The few people who will be using it are not tech savvy enough to know how fast their home network is, or how fast their mobile connection is at a given time or location, or even to know what bitrate would be appropriate if they knew what bitrate was in the first place. 

Auto will work in terms of playback, since it's choosing a very low bitrate. I could probably have them set it manually to around 10-20mb and be fine. But there is this feature called "auto" and it doesn't appear to work. If your answer as part of the Emby team is "yes, we know, we don't care, don't use it," I can live with that. It's just unfortunate.

Edited August 26, 2024 by CoastInTheFog

[RanmaCanada 495]

In my experience Apple products are garbage and they throttle for whatever unknown reason. This is what happens when you try to use a device outside their own eco-system. Apple is great if you want to stay locked down in their protected little world, and horrible if you actualy want to use it outside of it. The amount of problems Emby devs have with crApple products is astounding. Even the "competition" gave up on attempting to make things work to the point most people use third party programs like Infuse.

[CoastInTheFog 1]

1 hour ago, RanmaCanada said:

In my experience Apple products are garbage and they throttle for whatever unknown reason. This is what happens when you try to use a device outside their own eco-system. Apple is great if you want to stay locked down in their protected little world, and horrible if you actualy want to use it outside of it. The amount of problems Emby devs have with crApple products is astounding. Even the "competition" gave up on attempting to make things work to the point most people use third party programs like Infuse.

I'm not really a fan of Apple, but in 16 years of using iOS, I don't think I've ever encountered any kind of throttling, at least not when it comes to CPU, GPU, network I/O, etc. Aside from iOS itself, I don't use any apps in their ecosystem. I'm new to Emby, but are you saying that this specific feature tends to work fine on Android (though seems not on Windows)? Aside from "because Apple products are garbage" is there any specific data to support that this is an iOS problem, and not an Emby problem?

[yocker 1247]

11 hours ago, CoastInTheFog said:

You are basically saying "if it's broken, don't use it." I guess I was hoping for a bit more than that.

Yes, I am certainly capable of setting the quality manually according to the bandwidth that is available wherever I am with an iPad. I could constantly run speed tests not just to a geographically distributed system like speedtest.net, but to the speed test server I host on my own network, and then set the quality in the app to a level appropriate to my current connection so that the video I'm watching is transcoded at a level that does not cause stuttering, but does not present at an unnecessarily low quality either.

The thing is, Emby is not for me, and I will never use it. The few people who will be using it are not tech savvy enough to know how fast their home network is, or how fast their mobile connection is at a given time or location, or even to know what bitrate would be appropriate if they knew what bitrate was in the first place. 

Auto will work in terms of playback, since it's choosing a very low bitrate. I could probably have them set it manually to around 10-20mb and be fine. But there is this feature called "auto" and it doesn't appear to work. If your answer as part of the Emby team is "yes, we know, we don't care, don't use it," I can live with that. It's just unfortunate.

As i understand the auto quality setting makes one test on loading a movie and then stay on that quality the whole time, it's not a dynamic changing thing, so what you get at the start is what you get unless you change it your self.

The other media server products out there seems to do it the same way, Jellyfin at least didn't have any dynamic quality when i used it.

Personally i find dynamic quality rather annoying, Youtube can never make up it's mind even on my 1Gbps line and some times changes down to 480p even though it will gladly play at 4K with no problems if i force that resolution.
Finding what quality fits the device, manually set that and then forget all about it just works better for me, for example my parents have a low powered android box for their TV so have set quality to a setting fitting that device.

[CoastInTheFog 1]

1 hour ago, yocker said:

As i understand the auto quality setting makes one test on loading a movie and then stay on that quality the whole time, it's not a dynamic changing thing, so what you get at the start is what you get unless you change it your self.

The other media server products out there seems to do it the same way, Jellyfin at least didn't have any dynamic quality when i used it.

Personally i find dynamic quality rather annoying, Youtube can never make up it's mind even on my 1Gbps line and some times changes down to 480p even though it will gladly play at 4K with no problems if i force that resolution.
Finding what quality fits the device, manually set that and then forget all about it just works better for me, for example my parents have a low powered android box for their TV so have set quality to a setting fitting that device.

I did think of that, which is why I experimented with force quitting the app, reloading it, and playing another video from the start about 20 times. Every single time I got the same result: 1080p at 4mb.

I think whether auto adjust or setting constant quality is better is a matter of opinion and circumstance. It's a bit easier on a fixed device to figure out the best setting, and it's certainly easier if you are somewhat technically knowledgeable and are doing the figuring out rather than telling your parents to load up different quality settings to see how well they play.

I too have a fixed 1gb line, and Youtube does not always choose what I want. But, it does seem to choose different settings based on how large the window I'm playing back the video is. It's "auto" is doing something. Emby's auto seems to do nothing, thus my question.

[Happy2Play 9780]

Impossible to compare to Youtube or anyone else that has the video in dozens of resolutions and formats as you most likely have one in Emby.

But there is no dynamic/adaptive anything, but Auto for the most part can be conservative and fallback to the hardcoded playback values set on each client when playing remotely.  Don't think the technical aspects of Auto have ever been mentioned but it comes back to Auto should just play your media.  But yes this does potential create issues for anyone that wants to direct play that high bitrate media across the internet and will force them to apply a set quality on the client.

But at the same time possible have issues of buffering/pausing do the nature of the internet and throttling that is out of Emby's control as you can have the fastest internet speed on the planet but will not be able to use it from point a to b in all situations.

[CoastInTheFog 1]

1 minute ago, Happy2Play said:

Impossible to compare to Youtube or anyone else that has the video in dozens of resolutions and formats as you most likely have one in Emby.

But there is no dynamic/adaptive anything, but Auto for the most part can be conservative and fallback to the hardcoded playback values set on each client when playing remotely.  Don't think the technical aspects of Auto have ever been mentioned but it comes back to Auto should just play your media.  But yes this does potential create issues for anyone that wants to direct play that high bitrate media across the internet and will force them to apply a set quality on the client.

But at the same time possible have issues of buffering/pausing do the nature of the internet and throttling that is out of Emby's control as you can have the fastest internet speed on the planet but will not be able to use it from point a to b in all situations.

Yes, fair point about Youtube. I only have one version of my movies.

It would be nice if Auto was adaptive during playback so that it could scale up and down during playback. I would think this could be achieved for example by measuring the number of stutters over a period of time and then requesting the transcoder to deliver a lower bitrate, at least in the case of scaling down if needed.

But like I said, having it make a choice during initial playback would also be nice. When you say "fallback to the hardcoded playback values set on each client" what are you referring to? All values are "Auto."

I am not asking to direct play, though if I'm trying to playback a 50mbps video and have 500mbps of bandwidth it should be able to make that choice. I'm asking for that 50mbps to be played back at any rate other than 4mbps, ever, even one time out of all my attempts. If even once I saw it playback at 10mb, or 2mb I would know it was doing something. Then I could say more conclusively that it's working but that it's too conservative. Feel free to let me know if I have an unreasonable expectation and educate me on what "auto" is supposed to do, as obviously I'm just making my own assumptions here.

Does anyone know how this thing actually works? Is it measuring bandwidth back to the server on app start? On movie playback? Is it measuring latency? Is there a way to see the results of this testing in the logs?

Am I the only one this feature doesn't work for?

[Happy2Play 9780]

Requested here.

 

14 minutes ago, CoastInTheFog said:

But like I said, having it make a choice during initial playback would also be nice. When you say "fallback to the hardcoded playback values set on each client" what are you referring to? All values are "Auto."

Do not know the technical aspect of Auto on how it probes the connection but there is a hard coded value to fall back to in every client when Auto is selected.

But in the end Auto does not really work the way anyone thinks it should and devs probably need a definitive answer on its functionality.  But personally tell all remote users to set client to max and throttle via user limits. 

As Emby has no adaptive functionality if your connection gets worse or throttled you will see playback issues when streaming at high bitrates.

Edited August 26, 2024 by Happy2Play

[CoastInTheFog 1]

@Happy2PlayInteresting thread on adaptive streaming. That would be the ideal option, but is more advanced than what I'm looking for. Also no reply from Emby for over 2 years on it.

Isn't there some kind of roadmap someplace for what they are working on?

[Happy2Play 9780]

1 minute ago, CoastInTheFog said:

Isn't there some kind of roadmap someplace for what they are working on?

Sorry no as they don't publicize what they are working on or what will be in any perspective release.   All we get is what is added in release notes or specific functionality testing when something is added to beta.

[Happy2Play 9780]

Feature Request are just that and if or when one may be added is anyone's guess.  As any comment from the devs everyone assume it will be added but the future is always still in front of us.

yes this is certainly possible for future updates

 

[RanmaCanada 495]

I'll add I've tested this on the same ISP, with the same user, in the same house (on the other side of town), with Android, Roku and crApple boxes all hard wired. All on auto, the Android and Roku devices have no issues and will manage to direct play 4k remuxes with no issues, where as the stupid crApple devices always throttle down to 4mbit.

I know Apple fanbois don't like to hear it, but their devices are crap. Disagree all you want, but if they were good, people wouldn't drop projects on them and the Emby Dev team would not have spent the better half of the last decade fighting with the stupid things.

[CoastInTheFog 1]

13 minutes ago, RanmaCanada said:

I'll add I've tested this on the same ISP, with the same user, in the same house (on the other side of town), with Android, Roku and crApple boxes all hard wired. All on auto, the Android and Roku devices have no issues and will manage to direct play 4k remuxes with no issues, where as the stupid crApple devices always throttle down to 4mbit.

I know Apple fanbois don't like to hear it, but their devices are crap. Disagree all you want, but if they were good, people wouldn't drop projects on them and the Emby Dev team would not have spent the better half of the last decade fighting with the stupid things.

Interesting. I appreciate the data point. If this really only effects Apple devices I'd be curious as to what the specific issue is. If that's true, then at least it's not just me seeing it.

Between iOS devices, MacOS, and AppleTV this should be affecting a pretty large user base, regardless of "their devices are crap."

[Q-Droid 989]

21 hours ago, CoastInTheFog said:

Hmm, after searching around in the forums a bit, it seems this has come up many times over the years but it's not being resolved by Emby and they don't plan to fix it. If anyone has any other info I'd be interested.

Everyone with remote users has dealt with this over the years. Not much has changed except maybe the default fallback bitrate was increased from 1.5 mbps some time ago.

You can add your 2 cents to any of the multiple threads about this. In the end for your user's enjoyment and your sanity the advice below is the way to go. You can tell your remote users who use Emby from home to max out their "quality" and you can then limit the bitrate at the user level on your server. It's the easiest way to manage this for older and non-technical users. You can discuss and/or work through it with the more technical ones.

4 hours ago, Happy2Play said:

But in the end Auto does not really work the way anyone thinks it should and devs probably need a definitive answer on its functionality.  But personally tell all remote users to set client to max and throttle via user limits. 

[Spaceboy 2573]

12 hours ago, CoastInTheFog said:

Interesting. I appreciate the data point. If this really only effects Apple devices I'd be curious as to what the specific issue is. If that's true, then at least it's not just me seeing it.

Between iOS devices, MacOS, and AppleTV this should be affecting a pretty large user base, regardless of "their devices are crap."

its all remote devices. ignore the edgelord

[visproduction 315]

On 8/25/2024 at 7:32 PM, CoastInTheFog said:

 

Testing is being done at a C band 5G location on my iOS devices where I can speedtest at 500mbps. I do not think bandwidth is the issue.

It is not really fair to believe that 5G data transfer with encapsulated TCP packets will be flawless.  It does not behave the same way as TCP only packet delivery.  You seem to believe this data delivery is the same.  It is not.

TCP packets are encapsulated and may sometimes be sliced up and arrive, out of order, inside mobile 5G packets.  Then the end user's phone receives the 5G packets and pulls out the TCP packets, one at a time.  This process is sometimes quick and sometimes not, depending on the Internet traffic, the 5G data network bandwidth and mobile signal strength.  It is not a correct comparison to think that straight TCP packet delivery should be the same as TCP encapsulated into 5G mobile packet delivery.  If there are data transfer issues resulting in 5G packet arrival and unpacking TCP response time, then this could be the cause of the transcoding issues.

There are quite a few pdf white papers on this online.  If you search you probably can find the latest.  Here are some:
https://ieeexplore.ieee.org/document/9205403
https://www.sciencedirect.com/science/article/abs/pii/S1389128621003765

Edited August 27, 2024 by visproduction

[Lessaj 467]

Indeed auto for remote clients isn't actually auto, it's 1080p 4 Mbps which you'll see in your logs when someone is looking at an item detail page, so yes you either need to set the bitrate higher on the device or you need to add remote network subnets to your LAN Networks config. This is personally how I'm handling allowing full bit rate for remote clients, though I am doing it in a very shotgun way because I'm not trying to figure out all the very specific subnets used by the ISP that my friends are connecting from, I'm just looking for successful transcoded segments or direct play requests for original.mkv within my reverse proxy logs (but you could do this with the regular emby logs with a little more effort) since I know those are successful requests from authenticated users and the shotgun is using the first octet with .0.0.0/8 for the rest. Now that I've been doing this for a while here and there I'll see a new subnet get added

I include my actual LAN networks and VPN network as a base, and then append the rest and print out the list and then I just copy paste it into the field. Quick and dirty one liner, so dirty I'm even using backtick instead of $() for sub processes. Old habits die hard.

Quote

g="192.168.0.0/16, 10.0.0.0/24" ; for f in `egrep "[0-9].ts|original.mkv" ssl_emby_access_log.2024* | egrep " 200 | 206 | 304 " | awk '{print $1}' | cut -d ":" -f2 | cut -d "." -f1 | sort -n | uniq` ; do g=${g}", ${f}.0.0.0/8" ; done ; echo $g

P.S. I tried using 0.0.0.0/0 initially, to make everything seem like local, but I don't think this actually worked.

[CoastInTheFog 1]

@visproduction You are starting to get a little bit beyond my understanding of how this stuff works, but my interpretation of what you are saying is that 5G has additional overhead due to encapsulation of 5G packets compared to a normal wired network, and even probably compared to a Wi-Fi network. I was able to go through the 2nd article you sent, and it seems to explain that while 5G can deliver data at a fast rate, buffers can't necessarily handle that data, leading to dropped packets, increased latency, and poorer performance than the speed of 5G would otherwise deliver, even though they also point out that it's a large improvement over LTE.

So yes, 5G is not perfect. Wireless transmission of data has always had inefficiencies and overhead as far as I know. I can easily get 1gb out of a wired 1gb link, but getting even 750mb, out of an 866mb wireless link is nearly impossible.

But, I don't think I'm asking for anything "flawless." Problems aside, 5G does work to drastically increase data transmission.

This is a speed test from my phone, via 5G, to an internal speed test server running on my network:

I can easily sustain transfers between 200-300mbps from a file server, to my phone over the 5G network. Obviously all this data is TCP packets encapsulated inside mobile 5G packets. 21ms of latency is not that bad. I can also easily play back a video at a bitrate beyond 4mb. There is plenty of room in this connection, flaws of 5G aside, for Emby to say "you know what? Let's bump (or start) the encode up to a whopping 10mbps. In fact, let's get crazy and go to 20mbps!" It obviously does not do that, which is my entire point. Considering I can direct play an 80mbps file no problem, I do not think my expectation of what is possible is unreasonable, nor do I agree that 5G is my issue.

Taking into account the additional information from RanmaCanada and Lessaj who seem to experience the exact identical problem on Apple devices, I think I can definitively say that "auto" on iOS does nothing. There is nothing automatic about it, unless you consider automatically choosing the exact same low bit rate every time as qualifying as "auto." Just to clarify, because "holly shit really?" I am making the assumption that "auto" is short for "automatic" which has as one of it's definitions the following: "having a self-acting or self-regulating mechanism." I feel like I just lost some brain cells by typing that out, but there it is.

Whether it's broken because of Emby, or because of an iOS/Apple limitation I wouldn't know. 

Normally I would now move on instead of stirring shit up, but I feel I've got to say that this whole conversation has been a bit disappointing to me. Not because I paid money to use software that has a seemingly very helpful feature for my use case that doesn't work (maybe just delete auto and be done with it?). I encounter software things that don't work all the time, and that's part of how these things go. But some of your responses have been ridiculous. I appreciate getting your replies, and some of you were very helpful, but this has been an unusually strange forum experience for me.

You know what would have been nice?

From Emby, if you are going to respond: "Yeah, we know, it says auto, but it doesn't do anything on Apple devices. We don't plan to fix it because it would just take too many resources/it's not a priority/it's impossible." OR "We are working on it." OR "This is what it's supposed to do, and this is why it doesn't do what you think it's going to do." NOT some version of "If it's not working for you, don't use it." @ebrWhat is wrong with you?

From everyone else: Maybe just say "yeah, it's a known problem" or if you want to double check, ask about my setup and why I think it should work the way I think it should work. Maybe suggest something that could be helpful the way @Lessajdid. Yeah, I have an iPhone. Half the damn world has iPhones, if not more, especially here in the US. @RanmaCanadamaybe you need some therapy to deal with your Apple rage problems? There is no need to use my post to insult me about it.

There is also no need to tell me that I don't want to use auto either. Yes, I clicked on the little gear icon, I can see there are other bitrate options. I don't think I'm coming off as a total idiot but you never know. I asked why this one thing doesn't work!

Overall, Emby does seem like good software. I picked it after doing some research comparing it to Plex and Jellyfin where people were saying it was the best option these days. I appreciate what it's able to do so far, I paid for it, so I will use it for a while. Like I said, I do appreciate some of the responses.

For anyone else who ends up here after Googling it:

The auto option on Emby, at least for iOS, does not do what you think it will do. It may revert you to playing at 1080p at 4mbps, no matter what your source video is, the power of your encoding hardware, how fast your network is, how fast your internet connection is, how fast your device is, how fast it's connected to the internet, whether it's LTE, or 5G, or WiFi on a remote network. All that matters is that you are remote, the client device is on auto, and you will get the same low bitrate video every time.

Emby seems to know, but they will not be helpful. They do not provide a roadmap for when or if it will be fixed, and do not do roadmaps in general. Either set appropriate static bitrates on clients, set high bitrates on clients and remotely limit them in the admin panel, or live with a non-functioning auto setting. BE DONE TRYING TO FIGURE THIS OUT, ENJOY THE SOFTWARE, AND MOVE ON WITH YOUR LIFE.

[visproduction 315]

Coast,

Yes, interesting points.  How does the software handle "auto"?  Is there an iOS issue?  It seems like you could test throughput to 5G, by using a premade media content from some demo source online that does not need transcoding.  Mp4 and AAC or MP4 audio at 1080P correctly encoded as a test video at different bitrates.  You can find this media online.  It's better than grabbing some random video and hoping there are no issues with the metadata or codec.  Just because something plays fine on a 3rd party player, does not mean the media is correctly encoded.

So with such test videos, you can run through your 5G tests and see if any have playback stuttering on the high bit rate copies and at different times of day, when 5G is used more in your area.  The results of this testing will pinpoint if there is any 5G issue that has nothing to do with the encoding.  I know that you are saying it's the encoding setting that doesn't work.  What I am saying, if you find playback issues on 5G with bandwidths that should play fine, then maybe the 5G throughput limitation causes the 'Auto' setting to flip down and not take advantage of the bandwidth as you expect.

If high bit rate 5G plays fine all the time with the test videos, then it seems that there is something truely going on with the 'auto' packet sensing that fails with your iOS and server layer.  If you don't test with demo videos, you cannot eliminate 5G as a culprit.  Maybe the throughput keeps getting incorrect acknowledgement packet speed data and the "auto" math clamps down the transcoding because of these non-responsive ack packets coming back to the server.  Maybe it is what you suspect that some code is not seeing iOS response correctly. I think you need the demo video testing to see if 5G works all the time or not.

Hope that makes sense.

[Happy2Play 9780]

Looking at 5G I have seen speedtests lower than 1mbps and over 200mps and would expect provider to be throttling traffic on their network.  

But in the end AUTO is not what users think it is.

Edited August 28, 2024 by Happy2Play

[CoastInTheFog 1]

@visproductionThanks for your reply. I think I understand what you are getting at, however I have video files at different bitrates that I am testing, and I'm using the same ones over and over again. They are generally all MKV files encoded with either H265 of H264. They can all direct play with no transcoding on 5G, and certainly can on my wireless network at home, so I don't know why there would be issues with the metadata or codec. I've even tried low bitrate video files that run around 10mbps. They are still transcoded down to 4mbps. If there is some standard video file I should be testing, I'm not clear on what it should look like, where I should get it, or why it would be better than any other video file I've got. If a video file that's between 50-80mbps plays fine for me at all times of day over 5G (which I've now tested) at different geographical locations (which I've tested) with no transcoding, then I assume it can also play fine at say 10-20mbp of transcoding, and that auto could theoretically be choosing a higher bitrate than 4mbps. I've also tested on remote networks using WiFi that have at least 50mbps of throughput. Same results. I can stream fine at up to around 30mbps, but auto stays at 4mbps no matter what. I think I've now tested 4 different devices.

Maybe I'm still missing what you are saying, but I'm kind of wrapping this up as I feel satisfied in my conclusion that the software does not function as expected, and that there is no resolution forthcoming. As I'm typing this, Happy2Play has just written another message confirming as such.