FR: device-specific/client-specific toggle option to always transcode

[MrSpaniard 2]

Dear Emby Support Team,

I love this project, thanks to all the developers and Emby team members for what has been achieved here.
I've been struggling with a problem with Emby for a while that I would like to submit this feature request for.

 

The problem:

95% of my media consist of 1080p content that is encoded in x265 hevc 10-bit, to save space on my NAS system and retain quality.
Most of the devices used with my Emby server either direct play this format or get transcoded and the retained quality is more than satisfactory. Good stuff! 

Now enter into the mix tablet devices that 'support x265 hevc', but in reality can't deal with 10-bit content in the slightest (I'm talking 90% dropped frames, completely freezing, you name it.)
Whenever such a tablet client (for example, Samsung Galaxy Tab A6 10.1 2019 model) request to watch a video, the Emby Android App reports to the Emby server that the device support x265 hevc.
The Emby server then says, allright chief, here is your direct play content.
The tablet devices struggles to even display a single frame per second and completely falls on it's face.
You play 1080p x264 content or even 4k, and the device handles it like a dream.

To emphasize, this is not the Emby software that's at fault, it's the tablet manufacturers that flag certain codecs as being decodable, while they clearly aren't up to the task.

What I've tried so far:

- Lowering bitrate below the bitrate of the source content via the client or for the user's account as a whole.
This does work, but since the 1080p hevc 10-bit content already has such a low bitrate (2mbps - 6mpbs) this means you'll be looking at a horrible low bitrate x265 720p stream that becomes so blurry it's almost not watchable.
For some shows with higher bitrates, it's possible to fumble with the settings and get a watchable stream, but for the majority I can't do this, and it turns into a washed out 720p stream with 1.5mbps bitrate that's not very enjoyable to watch.

- I tried all kinds of messing about with the tablet devices to disable hevc x265 encoding entirely, as to trick Emby into feeding it x264 transcoded content.
Unfortunately, I've come a long way with this, but the end result is that this is simply not possible to disable, without rewriting the mobile OS completely.

- Looked through dozens of community posts and feature requests.
Most are for 4k content where the bitrate is so high that the lowering bitrate is a viable option, or posts that come to the conclusion it's not possible to solve this issue with the options we have right now.
I also found a feature request for the exact opposite of what I'm trying to achieve here, but I'm trying to achieve a different result.

- Try running Emby through a webbrowser with bad or no support for x265 hevc content instead of the Emby Android App.
I've had some moderate succes with this, but the interface on the Emby Android App is just so good and the performance of browsers on a lot of tablets just doesn't play well enough with Emby to use this as a default. 
I also noticed some of the browser handling webcontent in a weird way causing content to not load at all or the webpage to freeze on loading. (tested with Samsung Internet Browser, Google Chrome and Opera on Android)
Also, lately more and more browser have started implementing hardware accelaration for video content, which defeats the workaround entirely. On pc you can disable this to solve the issue, but on mobile browsers, these settings are usually burried in the code.
On more computers and other devices the webapplication for Emby works like a dream though.

 

The suggested possible solutions:

I'd like to see a toggle option added in the Emby Android App to always force transcoding for HEVC content.
This would bypass the client hardware's issues and allow the device to request a stream it can actually handle without forcing quality into the '720p and below'-realm.

If I understand the inner working of Emby correctly, this could also be a user-specific setting from the Emby server side.
Where an admin could modify a user setting to always transcode hevc content for that specific user.
I think this can be incorporated with the way Emby decides on wether or not a transcode is needed fairly easily. (I know, that's easy for me to say as I'm not the one programming it, haha)
This could help with development cost and time as no changes on the client applications side is needed.

This could also be a system/server-wide toggle, although that would prevent devices that can direct play hevc, from ever doing so.
The most versatile solutions would be to make this toggle user-specific or even better device-specific.
Where you can set this is a user option on the device in question, and make sure you get fed x264 content.
 

Footnote:

Now I'm not the one programming Emby, but have enough programming experience myself where this seems like a doable solutions without too much work to implement.
Therefor my suggestion is as described above.
There are fancier ways of doing this, but would also require much more work for not enough improvement.

I hope you'll consider this request and thanks in advance.
I'm hoping to hear back from you.

And of course if anybody has the golden tip on how to work around this issue, I'm open to trying stuff here.

[ebr 16184]

Hi.  Wouldn't correctly detecting the bitrate capability of the device be the better solution to your actual problem?

[MrSpaniard 2]

34 minutes ago, ebr said:

Hi.  Wouldn't correctly detecting the bitrate capability of the device be the better solution to your actual problem?

Unfortunately I don't think so, because the bitrate detection does not seem to be the root of the problem.
The problem is that devices report back they are capable of streaming certain codec, while they in reality cannot.
And the distinction between 8bit and 10bit hevc is a little janky for devices to report back what they can and cannot do.

Maybe if we're able to detect a device dropping a lot of frames, that could trigger a requirement for a transcode.
But I expect the user experience would become a little odd because of that, where your video starts out stuttery, then suddenly changes over to smooth.
If we want to detect properly at the beginning, it would mean we would have to test with something before we know for sure if the device is capable or not.

Not sure what you have in mind for doing that without causing delays with playing video or have the changeover like mentioned above.

I'd also say, that my solution would involve a lot less time and effort to implement than detecting device capability, since that detecting of device capabilities is exactly the reason for my issue. Since the device gives back incorrect information that we cannot control from the device side.
For my solutions, all it would have to do basically is tell the emby server to not bother figuring out what to do, and just transcode anyway if the toggle is checked for that device/user.

Maybe my logic is incorrect here, not sure.
If I misunderstood your idea, let me know.

[ebr 16184]

Hi.  Sorry, that's what I meant.  If we could determine (or even set) the bit depth capability on the device then that would be better than just summarily forcing transcoding.

[Luke 42078]

Quote

Whenever such a tablet client (for example, Samsung Galaxy Tab A6 10.1 2019 model) request to watch a video, the Emby Android App reports to the Emby server that the device support x265 hevc.

Does it transcode in chrome with the hosted web app?

http://app.emby.media

 

[Teshvier 1]

Hi, I am just wondering if this feature request would be implemented?

Because I have a similar issue. I am using reverse proxy and one of my devices only direct plays the video but this causes it to buffer. The content is x265 and the devices are the new Chromecasts connected to a very old Samsung TV.

[Luke 42078]

On 8/12/2023 at 7:08 PM, Teshvier said:

Hi, I am just wondering if this feature request would be implemented?

Because I have a similar issue. I am using reverse proxy and one of my devices only direct plays the video but this causes it to buffer. The content is x265 and the devices are the new Chromecasts connected to a very old Samsung TV.

@Teshvier

HI, yes it's certainly possible, but in your case it may not be the ideal solution. Please open a new topic and let's look at your issue in more detail:

How to Report a Problem

Thanks !

[Teshvier 1]

Thanks, I added a new topic.

[MrSpaniard 2]

On 8/3/2023 at 6:47 AM, Luke said:

Does it transcode in chrome with the hosted web app?

http://app.emby.media

 

Hi Luke,

Thanks for the suggestion and apologies for the late reply.

I've tried it out on a few browsers (Samsung Internet, Google Chrome and Opera) but unfortunately, the behavior through the hosted app is the same as going through a direct link to the webinterface for my server.

The server also sees the stream as a direct play one, so this method also get's fooled by the device into thinking 10bit hevc is possible.

I don't see a particular difference in the behavior.

Is there anything else you might want me to test?

 

[MrSpaniard 2]

On 7/28/2023 at 2:46 PM, ebr said:

Hi.  Sorry, that's what I meant.  If we could determine (or even set) the bit depth capability on the device then that would be better than just summarily forcing transcoding.

Hi ebr,

That might also work. I believe my particular device struggles most with 10bit, and 8bit might be doable.

When someone has a device where 8bit as well as 10bit are problematic, a full override for allowing hevc direct play would be a better lifesaver.

 

I appreciate you're looking for the neatest solution, but I would say to be careful and don't over-engineer it too much.
In the end, it's not Emby that's at fault in this scenario, it's the device reporting false information that can't be manipulated. (by the way, Apple TV HD's also suffer from this issue where 10bit hevc is struggling at times even though the device reports it up for the task and therefore triggers a direct play stream)

I would be extremely happy with a full hevc direct play disable button/switch.

Either way, thanks for sparring on ideas here, I appreciate it :)

[Luke 42078]

On 8/19/2023 at 6:36 PM, MrSpaniard said:

Hi Luke,

Thanks for the suggestion and apologies for the late reply.

I've tried it out on a few browsers (Samsung Internet, Google Chrome and Opera) but unfortunately, the behavior through the hosted app is the same as going through a direct link to the webinterface for my server.

The server also sees the stream as a direct play one, so this method also get's fooled by the device into thinking 10bit hevc is possible.

I don't see a particular difference in the behavior.

Is there anything else you might want me to test?

 

Can you supply a copy of the media info from the bottom of the web app detail screen? Thanks.