Jump to content

Transcode in H265


Snaaaake

Recommended Posts

I am probably repeating myself but this would be a blessing for all those on remote connections and limited bandwidth / data plan.

  • Like 3
Link to comment
Share on other sites

EricGRIT09

I am probably repeating myself but this would be a blessing for all those on remote connections and limited bandwidth / data plan.

 

Agreed - this is my #1 wanted feature.  Every time I update I look for case notes around this, lol.

Edited by EricGRIT09
  • Like 1
Link to comment
Share on other sites

I understand why some in this thread are getting agitated by the lack of response on this issue, my parents just cut the cable.. and not 75% through the month they used over 80% of their datacap, looks like its gonna cost them $50/mo extra.. even though I have HEVC encoding hardware and they have HEVC decoding hardware, we are unable to take advantage of it.

 

Actually.. what provider?? I know on AT&T I've went over my limit so far twice egregiously. Cuz when you go over the first 3 times they don't charge you. They just send you these courtesy notices telling you what a nice guy they are to waive the charges.. this time. but next time we may charge you.. blah blah. Ways to lock down your wifi. Stop people waste your bandwidth. Maybe some other advertisement junk too. Like hey I know this is about your internet.. but wanna buy another cellphone we have a great promotion right now? And.. no.. stop hassle me just take my money and waive the fee.. jeez.

 

They send you 3 of those and the 4th one they do charge you. And when you know you've gone over and are going to be waived.. go over big.. shoot for the moon... go to Jupiter even. That is how I got to 2.6TB for the 1st one. Then 1.8TB the 2nd. Haven't got the 3rd yet cuz that is truly my last one waived.. lol

Edited by speechles
Link to comment
Share on other sites

Agreed - this is my #1 wanted feature. Every time I update I look for case notes around this, lol.

Judging by this thread we aren't the only ones, I guess.

Link to comment
Share on other sites

It's not an issue of how to do it and in fact we've done the plumbing already. It's the user interface that is the most delicate part that is waiting until we're able to give it the amount of attention that it needs.

Link to comment
Share on other sites

Whats the user interface need other than a checkmark to enable x265 output? Client tells server it needs to transcode and it supports x265.. the rest should be automagic if the server is allowed to output in that format... maybe a client option to force x265 for those with low data caps would be all the users would need to be exposed too.

 

 

Mom went over her data cap, downgrading her internet speeds to offset the cost of more data blocks or else she's gonna hook the cable back up if streaming costs $100/mo.. guess I'll look into putting her onto Jellyfin. 

Link to comment
Share on other sites

Just to add my $0.02 to the discussion regarding HEVC vs. VP9.  The streaming devices that I have all support both codecs - NVIDIA Shield TV, Roku Streaming Stick+, Chromecast Ultra.  I have a 4K Roku TV that also supports both codecs.  But, my 2015 Samsung TV and my 2014 LG OLED TV (both 1080p) only support HEVC and do not support VP9.  I would be fine with either codec, but I would venture to say that there are many users that possess TVs of my vintage that are able to utilize HEVC, but not VP9.  And of those, a substantial portion might be unwilling to spend the money on either a new TV or a new device that includes VP9 capability.  Additionally, the Kaby Lake CPU in my server has slightly better capabilities for HEVC than for VP9 (cannot encode VP9 10-bit).  In a nutshell, there is more existing hardware on both the client and server side that can fully support HEVC than there is that can support VP9.

  • Like 1
Link to comment
Share on other sites

SikSlayer

Just to add my $0.02 to the discussion regarding HEVC vs. VP9.  The streaming devices that I have all support both codecs - NVIDIA Shield TV, Roku Streaming Stick+, Chromecast Ultra.  I have a 4K Roku TV that also supports both codecs.  But, my 2015 Samsung TV and my 2014 LG OLED TV (both 1080p) only support HEVC and do not support VP9.  I would be fine with either codec, but I would venture to say that there are many users that possess TVs of my vintage that are able to utilize HEVC, but not VP9.  And of those, a substantial portion might be unwilling to spend the money on either a new TV or a new device that includes VP9 capability.  Additionally, the Kaby Lake CPU in my server has slightly better capabilities for HEVC than for VP9 (cannot encode VP9 10-bit).  In a nutshell, there is more existing hardware on both the client and server side that can fully support HEVC than there is that can support VP9.

 

Exactly!

 

The simple fact is HEVC has had greater HW encoding and decoding support than VP9 does from the start. It's arguably better too. That's why transcoding to the codec is what was originally asked for in this thread!

I don't get what VP9 has to do with any of this. Sure, its a similar performing and open source codec. But it's not what was asked for!

 

If it's something that has to be implemented very carefully, as ebr says, and that the interface has to be tackled as Luke says, then then those should have been the answers in the first place. A lot of wasted discussion for nothing.

This is a thread two years in the making! Nvidia had cards that supported HEVC encoding for three! We still don't have this feature and only now are the developers capitulating. 

 

In the next year or two when AV1 (a codec that almost the ENTIRE industry is getting behind) starts making its mark, are we gonna have to go through this whole debate game again?

I hope this is taken as a lesson.

  • Like 1
Link to comment
Share on other sites

Happy2Play

In the next year or two when AV1 (a codec that almost the ENTIRE industry is getting behind) starts making its mark, are we gonna have to go through this whole debate game again?

 

 

Why yes as you have already stated your legacy devices will not support AV1 so when should it actually be added?  Lets say +5 years from when it is more accepted. :)

Edited by Happy2Play
Link to comment
Share on other sites

If it's something that has to be implemented very carefully, as ebr says, and that the interface has to be tackled as Luke says, then then those should have been the answers in the first place. A lot of wasted discussion for nothing.

This is a thread two years in the making! Nvidia had cards that supported HEVC encoding for three! We still don't have this feature and only now are the developers capitulating. 

 

I don't understand this statement.  We are not "capitulating" and we are also not "only now" doing anything.

 

We responded to this request the day it was originally posted and have tried to explain why it hasn't happened yet.

 

I'm afraid it just isn't as simple as adding a checkbox somewhere.

 

We are a lot closer now though.

Link to comment
Share on other sites

Why yes as you have already stated your legacy devices will not support AV1 so when should it actually be added?  Lets say +5 years from when it is more accepted. :)

 

Why not as soon as possible? Let early adopters take the hit.. I dont see the point in letting the dust settle then adopting it.. there is an advanced transcode toggle that hides stuff, and you can label options EXPERIMENTAL/UNSUPPORTED and let the community them selves deal with it.

 

There are methods of keeping less mature features out of the hands of plebs, usually something as simple as enabling a hidden option in a config file is more than adequate, which would remove much of the UI burden until such features are ready for mainstream.

 

If you cant implement highly desirable features w/out creating too much of a support burden, then I'd suggest some effort be put into the documentation.. otherwise that excuse will cripple further progress until the end of time.. there's already countless ways to configure your server such that performance is terrible, is the plan to start yanking all that stuff out too and regress?

  • Like 1
Link to comment
Share on other sites

Happy2Play

Why not as soon as possible? Let early adopters take the hit.. I dont see the point in letting the dust settle then adopting it.. there is an advanced transcode toggle that hides stuff, and you can label options EXPERIMENTAL/UNSUPPORTED and let the community them selves deal with it.

 

There are methods of keeping less mature features out of the hands of plebs, usually something as simple as enabling a hidden option in a config file is more than adequate, which would remove much of the UI burden until such features are ready for mainstream.

 

If you cant implement highly desirable features w/out creating too much of a support burden, then I'd suggest some effort be put into the documentation.. otherwise that excuse will cripple further progress until the end of time.. there's already countless ways to configure your server such that performance is terrible, is the plan to start yanking all that stuff out too and regress?

 

Because users will expect it to work and don't understand just because a option is available it will not work on every system.  But I have absolutely no say when of if a feature is implemented.  I am just stating what has already happened.  

 

So this is a feature that will not work on I would guess close to half of Emby users currently. (Just a guess) as I know it would not work on at least half of the systems I own.

Edited by Happy2Play
Link to comment
Share on other sites

Implications that can evolve would include missing options in the config interface causing issues. Hence the wait til that is designed is reasonable. There is no games. There is honesty. The framework is the harder part to code, but the interface is the harder part to think. You have to think of everything at once and how to present it. You have to make it appeal to both grandma who possibly uses Emby for her grandkids and runs a server and at the time for everyone here who is a power user. You have to bridge that gap with the UI and make what isn't outright intuitive into icons, words and text a user reads to understand what they are doing.

 

The implications that can evolve from multiple HEVC encodes on a normal Emby server would be not normal. It would be several times more crushing and harder to complete and much lower FPS. The problem is how to present the interface to a user without them feeling overwhelmed, stupid, or not given enough information to use the feature. This is the holdup entirely. You must think this through and maybe 2 years is enough time for this, but maybe it isn't. It is an endeavor. It is not just build a checkbox and logic to tell when the box is checked. It is hold the users hand through the entire process so they understand it. This "hand holding" is the UI/checkboxes/etc required to get there and have users read these things not just blindly press OK through them.

Edited by speechles
Link to comment
Share on other sites

am I mistaken that the clients already know what codecs it supports? otherwise how does on the fly transcoding work at all? If your device does not support HEVC, then clearly the server should not be feeding it that codec.. From Grandma's standpoint at the Emby client, nothing at all should be any different than today.

 

I just checked my device list, about 16 of em I know for a fact support HEVC.. minus the browser sessions, there is one lowly old FireTV that dont support it.. so 16 out of 17 in my sample and if I had HEVC output I'm 100% sure that lone user would go upgrade his device asap.

 

I bet if sampled, a rather large population of users here already is serving HEVC content directly out of libraries.. Pretty much everyone into Anime or UHD content.

Edited by nayr
Link to comment
Share on other sites

Because users will expect it to work and don't understand just because a option is available it will not work on every system.  But I have absolutely no say when of if a feature is implemented.  I am just stating what has already happened.  

 

So this is a feature that will not work on I would guess close to half of Emby users currently. (Just a guess) as I know it would not work on at least half of the systems I own.

 

How about this:  As part of the installation routine, a query is run to see which CPU and GPU are installed.  That is checked against a database for HW encode/decode capabilities.  If not HW capable, then either don't enable it or, to satisfy those few who have a machine that is brawny enough to do it in software, a short test file is encoded/decoded and timed.  Fast enough, enable it - too slow, disable it.

Link to comment
Share on other sites

Happy2Play

How about this:  As part of the installation routine, a query is run to see which CPU and GPU are installed.  That is checked against a database for HW encode/decode capabilities.  If not HW capable, then either don't enable it or, to satisfy those few who have a machine that is brawny enough to do it in software, a short test file is encoded/decoded and timed.  Fast enough, enable it - too slow, disable it.

 

It takes time, thought and development.  As the Devs have already stated they have a plan and we will see it when it becomes available.  It is on the radar but everything else will not stop just for to implement this feature.

Link to comment
Share on other sites

all these same problems are encountered today from a support/UI perspective when HEVC input was allowed.. Imagine the number of users migrating to something else by now if Emby did not permit HEVC media in the least bit by now.

 

I understand there's a ton of users on here bitching about UHD4k troubles already, there's no checking to see if your system is sane enough to do it.. it'll just try to transcode a UHD HDR Remux in realtime w/software alone on an arm64 hardware gladly right now, and fail spectacularly... but I can say this much for sure, if emby didnt direct stream HEVC right now.. I'd be using another piece of software without a doubt.. and eventually I'll prioritize HEVC Transcoding output enough that would be a dealbreaker too.

Edited by nayr
Link to comment
Share on other sites

It takes time, thought and development.  As the Devs have already stated they have a plan and we will see it when it becomes available.  It is on the radar but everything else will not stop just for to implement this feature.

 

Yep.  Understood.  Just want to keep prodding and poking to let you know the level of interest.  Doing a great job so far.

Link to comment
Share on other sites

Happy2Play

Any the same response will happen it will be here when it gets here.

 

Having a feature that doesn't work is more damning then not having a feature at all.

Link to comment
Share on other sites

am I mistaken that the clients already know what codecs it supports? otherwise how does on the fly transcoding work at all? If your device does not support HEVC, then clearly the server should not be feeding it that codec.. From Grandma's standpoint at the Emby client, nothing at all should be any different than today.

 

Grandma runs her Emby server for her grandchildren to use on the Roku they have in each of their respective bedrooms when they stay at her house. Server must support it and grandma must understand what HEVC even is. Understand?

 

The ability to play a given codec is 100% up to the capabilities Emby receives from that device. The app must honestly support what is there. On Roku I guarantee we honestly do this. The server is given the true abilities of that Roku at any given moment not just what it was when it booted up. The device reporting accurately and honestly all the capabilities it can really play at the moment that user goes to play something. Not just reading and reporting these capabilities at boot. This is harder to do on some platforms as developers aren't given full access to some things making it guess work and trial-by-error. Also, some devices lie. When they lie the honesty in the capabilities goes out the window and you gain issues. Firmware issues, OS software bugs, poor quality control, poorly built devices. All of these are out of control of Emby. We must also be smart enough to know when the device is lying to us. There are some Roku devices that lie and we keep track of these lies and when to correct them.

Edited by speechles
Link to comment
Share on other sites

Happy2Play

 

playback, Emby for android TV with Shield with a poor connexion could use it.

 

If you put an option on

                                    Client side "Use H265"

                                    Server side "Allow users to use H265" 

 

like that you don't care if devices are compatible or not, User have the choice.

like that you don't care if devices are compatible or not, User have the choice.

 

 

Just because a client is capable of using the codec really is pointless to this request as the server will already delivery this content to the device if it is capable.  When it comes to converting/trancoding media it is another story and as quoted online can need up to 10X more power to convert the media.  So usually hardware is required.  

Edited by Happy2Play
Link to comment
Share on other sites

Grandma runs her Emby server for her grandchildren to use on the Roku they have in each of their respective bedrooms when they stay at her house. Server must support it and grandma must understand what HEVC even is. Understand?

 

Nope not at all, Grandma is going to have to understand what codecs are as-is because there's nothing stopping her from dropping files into a library currently that her server needs to support, today.

 

seems to me, that grandma finds an advanced transcoder feature on her server and decides to start dicking around w/stuff she dont understand is a whole ado about nothing when grandma can easily drop readily available files into her libraries that her server dont support right out of the box running all default settings.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...