Jump to content

Tone-mapping in transcoding HDR for playback on SDR screens??


griffindodd
Go to solution Solved by Luke,

Recommended Posts

Dear Emby Devs, the Key to bring the HDR to SDR Feature to work is not to server side transcode with tonemapping. The Server just have to transcode Videos including the HDR Metadata 1:1 as the original Video File. And on the Client side must be tonemapping active.. Kodi 18 will do this allready

 

I don't believe it is that easy. I think Kodi has their own player and even in that case, I don't think Kodi supports tone mapping on all devices. A quick google tells me that only devices with an AMlogic chip can do tone mapping because its built into the drivers.  And that is the problem. Many chips don't support tone mapping in hardware/drivers so in that case the Emby team will either need to depend on a media player that can do this in software (without requiring lots of processing power), wait for whoever's player they are using gets support for tone mapping, or support do the transcoding on the server side.

 

As more and more HDR capable devices are coming onto the market I don't think there is going to be much of a push to get tone mapping done in hardware/software. Especially not since all the commercial video providers can simply do device detection and service SDR content on devices that do not support HDR.

 

So doing it server side in Emby is probably the most practical way to get HDR working properly on ALL SDR devices.

Link to comment
Share on other sites

i think its mutch better to do tone mapping on the clients, for the server it still needs too much processing power. Tonemapping in Kodi 18 works on amlogic and windows versions.. thats enaugh for most cases. So the server can direct push HDR Meta Data to the clients. I belive even h264 files are HDR cabable so it dont needs too much power for transcoding

Edited by Gee1
Link to comment
Share on other sites

The problem with that is it will only serve a subset of users. Popular device such as the shield tv and Amazon sticks don't support tone mapping. So those users should buy an additional box? Or how about users that watch on a monitor through a browser? They should all buy new monitors?

 

 

For device that support it doing tone mapping on the client makes sense but a solution that works on every device would probably depend on the server.

 

 

4k hevc transcoding also seems to be doable for not so expensive GPU's from what I gather.

Link to comment
Share on other sites

Maybe a hybid solution is  the way to go.. Amazon Sticks are WAY TOO less powerfull. Amlogic boxes (S912 and S922X) with Coreelec Image are the best choices for moderate price. Absolutely best is an HTPC with Win10 with an nVIDIA GTX but very expensive in compared. Quick google: Firefox and Chroem Browsers are also capable to do HDR to SDR (but still not perfect). For all other unsupportet devices the server can do tone mapping with ffmpeg. In my opinion this is the best way

Link to comment
Share on other sites

Guest asrequested

You have to consider remote users with lower internet bandwidth which will require transcoding. Server tone mapping will be needed. While client tone mapping would be helpful, it's far away from being a good general solution. So many phones and tablets etc.

Edited by Doofus
Link to comment
Share on other sites

  • 2 months later...

Circling back on this topic, we are now at the 2 year mark since this post was first created. I understand there was a GitHub issue created for this feature but I haven't seen anything since then.

 

Would like a couple of questions answered.

 

1. Has there been any further discussion on how this feature will get completed?

2. Is this something that has been actively brought up and discussed amongst the team?

 

I am afraid this has been put in graveyard to die when I truly believes this would set emby way ahead of all of their competitors.

Link to comment
Share on other sites

they working on it for over TWO years now.

 

 

Yes unfortunately I am afraid it isn't a priority, when they state they "working on it" I would expect there is actual changes in progress not just a todo item laying around in their backlog. It doesn't appear the they want to share any additional information on the progress at this point, which is a bit disappointing but we will have to wait and see. 

Link to comment
Share on other sites

Jdiesel

Have you done any research into what it takes to getting tone mapping for transcoding? The reason it isn't being done by Emby, or anybody for that matter, is because it is a complicated beast. I suggest looking at @@softworkz post history for more information on the progress.

Link to comment
Share on other sites

Have you done any research into what it takes to getting tone mapping for transcoding? The reason it isn't being done by Emby, or anybody for that matter, is because it is a complicated beast. I suggest looking at @@softworkz post history for more information on the progress.

 

 

This is an interesting response, yes I actually do know how involved this feature would be, and honestly if it took them 5 years to implement it that would entirely acceptable however noting something as "being worked on" without any additional information isn't as helpful as perhaps, "it's in the queue, we haven't started it yet, we are looking at potentially picking this up in a few months". I guess I was more interested in knowing if it was being actively worked on or if it was just in a list of things to do.

 

Side note, even if they don't implement this that's fine as well, I wouldn't blame them, was just hoping for a little extra detail in where its at in the process even if that state is, "we haven't started it yet". 

 

To be fair perhaps "we are working on it" really does mean its actively being worked on, I'll just assume it is and revisit this thread in another year.

Link to comment
Share on other sites

thrillcat

I, for one, would LOVE to see server-side tone-mapping.

 

As a user who isn’t worried about all my external users (I’m not selling access to my server or abusing the capabilities of Emby in any way), and as someone with a decently powered server setup, this makes by far the most sense of any of the options.

 

I don’t know how MadVR functions, but if possible, the ideal setup would be a server option to run a side chain through MadVR, then back into Emby where the signal is then distributed to whatever client is requesting it.

 

I know development of Emby tends to lean less toward high-end users and more toward the masses, so I expect this will be acknowledged and politely declined so development can focus on users with more legally questionable implementations of Emby, but I’m just putting it out there.

 

There are plenty of people out there who have dropped more on their theater rooms than many users have spent on their entire houses, and to pay $130 for a lifetime membership, even $500-1000 for a lifetime membership for a tier of Emby with higher-end options, would be chump change, an afterthought.

 

These are people who are considering dropping $7K on a Lumagen or a MadVR Envy Vox to essentially do the same thing.

 

You’re leaving money on the table.

 

 

PS: I will always give you kudos for at least listening, which your primary competitor does not ever do. I’m merely trying to open your eyes and help you open up another lucrative market.

 

Sent from my iPhone using Tapatalk

Edited by thrillcat
Link to comment
Share on other sites

thrillcat

You will never get madVR in conjunction with Emby because of the simple fact: madVR is Windows only!

And my server is Windows. What’s your point?

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Guest asrequested

Madvr is for rendering to a display. Transcoding and rendering to a file is very different. Madvr can't be used in this way. Also, ffmpeg and madvr are entirely different platforms. You could however use mpv's algorithms, as that is built on ffmpeg.

Link to comment
Share on other sites

thrillcat

Madvr is for rendering to a display. Transcoding and rendering to a file is very different. Madvr can't be used in this way. Also, ffmpeg and madvr are entirely different platforms. You could however use mpv's algorithms, as that is built on ffmpeg.

Like I said, I don’t know how MadVR works.

 

I still think it would be more efficient for development and offer greater parity between the various client apps to offer server-side tone-mapping.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Guest asrequested

Server tone mapping is in progress. The 10 to 8 bit conversion is already in testing. Once that's dialed in the tone mapping of the metadata is less work, and should be a little easier to implement. Softworkz is a perfectionist, we're in good hands.

  • Like 2
Link to comment
Share on other sites

A few comments:

 

Of course "is being worked on" didn't mean permanent ongoing work. But there has been a long chain of prerequisites, like: before doing X, we need Y and before Y, we need Z, but we can't do Z without doing Q as well and that depends on ....

 

But where I don't really agree much is declaring tone-mapping as an inevitable feature. Wherever people get their content from these days: There's typically a choice between getting regular (SDR) and HDR content. Hence it's easy to follow a simple rule:

  • When you have HDR displays, get HDR content
  • When you have SDR displays, get SDR content
  • When you have both, well - ideally get both

The only valid use case I see for a server-side tone-mapping feature is the third case: You primarily have HDR displays and sometimes you want to watch the same content on SDR displays without duplicating content in your library.

 

But all of you asking for server-side tone-mapping need to be aware that this is not (and will never be) a high-end feature. It's a workaround only to make things appear less bad. It will never achieve the same quality of the original 8 bit content that you can get in the first place.

 

Emby's mission is "your media anywhere" and that's why we try to handle this situation as good as possible....

 

...but if somebody's library and Emby server setup strongly depends on having a tone-mapping feature in place for regular use, then I must clearly say that this is not a very good plan.

Edited by softworkz
  • Like 5
Link to comment
Share on other sites

A few comments:

 

Of course "is being worked on" didn't mean permanent ongoing work. But there has been a long chain of prerequisites, like: before doing X, we need Y and before Y, we need Z, but we can't do Z without doing Q as well and that depends on ....

 

But where I don't really agree much is declaring tone-mapping as an inevitable feature. Wherever people get their content from these days: There's typically a choice between getting regular (SDR) and HDR content. Hence it's easy to follow a simple rule:

  • When you have HDR displays, get HDR content
  • When you have SDR displays, get SDR content
  • When you have both, well - ideally get both

The only valid use case I see for a server-side tone-mapping feature is the third case: You primarily have HDR displays and sometimes you want to watch the same content on SDR displays without duplicating content in your library.

 

But all of you asking for server-side tone-mapping need to be aware that this is not (and will never be) a high-end feature. It's a workaround only to make things appear less bad. It will never achieve the same quality of the original 8 bit content that you can get in the first place.

 

Emby's mission is "your media anywhere" and that's why we try to handle this situation as good as possible....

 

...but if somebody's library and Emby server setup strongly depends on having a tone-mapping feature in place for regular use, then I must clearly say that this is not a very good plan.

 

 

 

I am sorry for my previous comment, it is clear that I was being passive aggressive and that was uncalled for.

 

I do like where you are going with this discussion, if you really dig down into the core of what user's want then I think there may be a good compromise. I am going to be a little bit selfish here and assume my reasons are the same as the others requesting this feature.

 

User Story - "As an emby server user I want to be able to maintain a single movie file within a single library and serve that movie to multiple client users with varying display and bandwidth requirements"

 

Prior to HDR the above user story was supported. The focus of the feature is not actually on the quality but on the other requirements. That is why any half decent tone mapping would satisfy my use case. The current result of a completely washed out screen is so jarring/detracting that it isn't worth doing.

 

This is where a potential compromise could come into play, currently you are suggesting that emby users maintain 2 libraries and 2 sets of files. This workaround trickles all the way back down the stack affecting every piece of the user's workflow for making content available. This unfortunately causes a lot of pain / frustration where many of us are not willing to implement it. 

 

To meet in the middle emby could add support for MKV files with 2 video streams. It would also need to implement some way to expose to the user a way of telling emby how/when to choose which stream. There are many ways this choice could be exposed / implemented but the end result would be a single file in a single library that can support HDR and SDR screens and would always give satisfactory transcoding results.

 

I am probably far off in left field here, and I totally understand that this is not a "standard" way of doing things. The burden of obtaining an mkv with 2 streams, one HDR and one SDR would solely be placed on the users and perhaps with enough popularity emby could support preprocessing HDR streams into this new format. 

 

If this is not acceptable we could take another step back and emby could symbolically merge 2 separate files into one movie within a library, exposing some of the decision making options to the server users. This would probably be easier to implement and perhaps the better "middle ground" solution. 

 

Thoughts?

Link to comment
Share on other sites

Guest asrequested

Here's one thought on this. We have the option of multiversioning, so we can have both HDR and SDR versions. But having the server intelligently choosing which to play in any given scenario, is not really in place. Example: if transcoding due to bandwidth is required, I believe what is presently happening is the server chooses the highest quality version to transcode from. If that is the HDR, then problem. But if when transcoding is needed with those versions available, I think the server should ignore the existence of an HDR version, and pick the closest SDR version to the requested output. Ignoring the HDR version would be best, because sometimes the 1080 version can have a higher bitrate than the HDR, and/or you have a 1080 HDR version. Of course, if there only exists an HDR version, then that would be the default choice. The other caveat is that I have more and more TV shows in HDR, and I have no intention of having both SDR and HDR versions. That would be a massive amount of data to store. For movies, I maintain both versions.

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

Here's one thought on this. We have the option of multiversioning, so we can have both HDR and SDR versions. But having the server intelligently choosing which to play in any given scenario, is not really in place. Example: if transcoding due to bandwidth is required, I believe what is presently happening is the server chooses the highest quality version to transcode from. If that is the HDR, then problem. But if when transcoding is needed with those versions available, I think the server should ignore the existence of an HDR version, and pick the closest SDR version to the requested output. Ignoring the HDR version would be best, because sometimes the 1080 version can have a higher bitrate than the HDR, and/or you have a 1080 HDR version. Of course, of there only exists and HDR version, then that would the default choice. The other caveat is that I have more and more TV shows in HDR, and have no intention of having both SDR and HDR versions. That would be a massive amount of data to store. For movies, I maintain both versions.

 

 

I didn't realize multi version support was already baked in, so like you said what currently exists is almost there. Emby would just need to either expose the HDR vs SDR decision to the users, or just make the choice knowing that transcoding SDR would always be superior. This would compliment the tone mapping work as users could in your case decide to keep both copies for different reasons and then keep a single HDR copy and be happy with whatever quality the tone mapping work ends up being able to produce. This would be a really high quality solution that would appease both sides, if you want "the best" keep both, if you want broad single copy support than use the tone mapping.

Link to comment
Share on other sites

I am sorry for my previous comment, it is clear that I was being passive aggressive and that was uncalled for.

 

I do like where you are going with this discussion, if you really dig down into the core of what user's want then I think there may be a good compromise. I am going to be a little bit selfish here and assume my reasons are the same as the others requesting this feature.

 

User Story - "As an emby server user I want to be able to maintain a single movie file within a single library and serve that movie to multiple client users with varying display and bandwidth requirements"

 

Prior to HDR the above user story was supported. The focus of the feature is not actually on the quality but on the other requirements. That is why any half decent tone mapping would satisfy my use case. The current result of a completely washed out screen is so jarring/detracting that it isn't worth doing.

 

I understand that story and that's the reason why we had put tone-mapping on our agenda - quite a while ago actually. But it was also clear that - when we'd do it - it needs to happen in hardware alongside all the other processing we're doing in hardware today. We've done a lot of preparation for this and it will be added soon.

 

But @@cryzis - how you set up your library is all your own decision of course, but considering movies and HDR: It's really not a necessity to have HDR versions for any video in your library. In fact there's just a small percentage where HDR really provides a significant visual benefit. 

 

I can only recommend to think twice regarding the selection of source videos - 10bit is not necessarily better than 8bit just because 10 is more than 8....

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...