Dolby Vision is transcoding to green

[FrostByte 5392]

I tend not to use TM myself because my poor little NAS can't handle it.  

[rbjtech 5284]

32 minutes ago, FrostByte said:

I tend not to use TM myself because my poor little NAS can't handle it.  

I was just curious tbh  - I don't Transcode or TM myself either - 4K is not 4K if it has been 'played with' ...   (imho of course..) 

[teddybear75 11]

Not sure if its the same issue, but im having some trouble with newer DV content to Emby LG tv app. (LG OLED B6 model)

The older DV contenct seems to be working fine, switching to DV on tv, but not the newer content (gets the green/purple color and tv does not switch to DV).

I see the LG tv app i use in Web-OS is more than 1.5 years old, maybe this will be fixed in the future?

PS: Nvidia Shield to tv, evenrything works fine.

[rbjtech 5284]

29 minutes ago, teddybear75 said:

Not sure if its the same issue, but im having some trouble with newer DV content to Emby LG tv app. (LG OLED B6 model)

The older DV contenct seems to be working fine, switching to DV on tv, but not the newer content (gets the green/purple color and tv does not switch to DV).

I see the LG tv app i use in Web-OS is more than 1.5 years old, maybe this will be fixed in the future?

PS: Nvidia Shield to tv, evenrything works fine.

It's likely a Dolby Vision 'Profile' issue - DV is not just one 'standard' but has many and they keep evolving it.  The older stuff is probably profile 5 - the newer stuff may be profile 8.

Unless LG support the latest profiles (unlikely on anything older than a year..) then you are out of luck (but luckily you have a Shield, so all is good)

[teddybear75 11]

On 23/11/2021 at 14:49, rbjtech said:

It's likely a Dolby Vision 'Profile' issue - DV is not just one 'standard' but has many and they keep evolving it.  The older stuff is probably profile 5 - the newer stuff may be profile 8.

Unless LG support the latest profiles (unlikely on anything older than a year..) then you are out of luck (but luckily you have a Shield, so all is good)

I have a newer LG CX model (2020) as well, same issue on that. Had to buy another Shield TV Pro...........

[RanmaCanada 494]

It can also depend on the container.  My TCL Roku TV won't play DolbyVision in MKV, but has no problem with it in MP4. DolbyVision is 100% proprietary and to get any type of tone mapping is currently not possible.  The metadata can be extracted and saved so you can encode it down and reapply the metadata, but that was created with specialized software and is not exactly easy to use and can't be done in real time.  Unless your hardware can play DolbyVision, stay away from it, and if it can play DolbyVision, check to see what profiles it can handle and understand that a profile that is not supported by your hardware, makes the file completely useless as tone mapping it is currently not possible.  I have a separate library for DolbyVision just to stop people from playing them on unsupported hardware.

[rbjtech 5284]

I would add that anything with a DV profile 5 (from streaming sources) is going to be DV only (with no possibility of tonemapping successfully as Ranma mentions above) but using a UHD disk source with DV profile 7 - it will also have a HDR encoding - and thus these transcode/tonemap perfectly well as they are no different to a normal HDR source.

DV profile 8 seems to be a new thing - I don't have any of these, so can't really comment, but I think they are the hacked UHD HDR sources re-encoded at lower bitrates with the DV encoding from other sources then re-added ?

[RanmaCanada 494]

11 hours ago, rbjtech said:

I would add that anything with a DV profile 5 (from streaming sources) is going to be DV only (with no possibility of tonemapping successfully as Ranma mentions above) but using a UHD disk source with DV profile 7 - it will also have a HDR encoding - and thus these transcode/tonemap perfectly well as they are no different to a normal HDR source.

DV profile 8 seems to be a new thing - I don't have any of these, so can't really comment, but I think they are the hacked UHD HDR sources re-encoded at lower bitrates with the DV encoding from other sources then re-added ?

I believe you are correct as this reddit post basically gave everyone the know how to do it "properly".  DV is a totally different animal, and we know from experience that 90+% of the users here are completely ignorant when it comes to codecs, profiles, etc and just expect whatever they throw at Emby to "Just F$#E%R#$ work".

[GWTPqZp6b 50]

On 11/18/2021 at 2:31 AM, FrostByte said:

You can see the DV profile of your stuff by using the open source app mediainfo.

DV profile 5 with no HDR10 layer

HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU 

DV profile 7 with the secondary HDR10 layer

HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible 

 

 

Could we get this listed in the transcode settings? I think it would be useful to know what profile is being used

[rbjtech 5284]

3 hours ago, GWTPqZp6b said:

Could we get this listed in the transcode settings? I think it would be useful to know what profile is being used

No because emby does not use mediainfo - it uses ffmpeg, which currently has many deficiencies on media detection - DV profiles being one of them (as well as other HDR types), but it also lacks the ability to identify common audio details such as Dolby Atmos / DTS:X.

tbh - these technologies have been around for years now - so I'm really not sure why ffmpeg has not added these heavily requested features.  If mediainfo can 'derive' the correct properties, then ffmpeg should be able to as well.  I use the word 'derive' as reading some 3rd party formats is proprietary and thus there is no publicly available standard method to do so.

[softworkz 5066]

4 hours ago, rbjtech said:

tbh - these technologies have been around for years now - so I'm really not sure why ffmpeg has not added these heavily requested features

The reason is pretty easy to explain: ffmpeg doesn't have a focus on detection (like MediaInfo). It only detects what it can decode or demux. So, as long as nobody adds a decoder for these formats, there won't be any detection. And even when these formats aren't new, there don't exist any open source decoder implementations for it. There is some ongoing work, though, and I think at some point ffmpeg will get support for these things - at least partial (while partial support might be sufficient to get full detection).

[Carlo 4560]

That makes total sense but still makes debugging harder when we see what's on the detail screen and it's not accurate. It would be cool if we could default to using media info instead for these types of files if it was user supplied and the location entered (assuming we can't distribute it).

That could be quite helpful for users with ever growing 4K collections.

Even though we may not be able to transcode such files, we still have some clients that can play them.

[FrostByte 5392]

2 hours ago, cayars said:

That makes total sense but still makes debugging harder when we see what's on the detail screen and it's not accurate. It would be cool if we could default to using media info instead for these types of files if it was user supplied and the location entered (assuming we can't distribute it).

That could be quite helpful for users with ever growing 4K collections.

Even though we may not be able to transcode such files, we still have some clients that can play them.

At one time Emby/Media Browser used mediainfo for detection

[softworkz 5066]

Yes, and at some time, transcoding only worked with every second or third file  

[FrostByte 5392]

26 minutes ago, softworkz said:

Yes, and at some time, transcoding only worked with every second or third file  

Sometimes you just can't have everything

[Carlo 4560]

Nope sure can't.  I forgot about that and the problems it brought with it.

I guess that's one of those things that sounds better than it is. LOL