Missing Shadow Detail, nothing below 2.5% black.....now 4.1%

[davilla]

see https://github.com/MrMC/mrmc-private/bl ... ndation.mm

lines 357 to 372

start by assuming SDR,
if HEVC Main 10, kick to HDR
if special tags hinting Dolby Vision, kick to Dolby Vision

The check for "hints.codec_tag == 36" is wrong, this is just another way of saying it was the hevc codec. FFMpeg needs changes to support the other ways of detecting Dolby Vision.

So maybe I should also be looking at color table as well for HEVC Main 10 ?

EDIT:
also in debuglog, look for

Debug Print: fps: 23.976024, pwidth: 1920, pheight: 1080, dwidth: 1920, dheight: 1080, colorspace: bt709, colorrange: Limited

it will log the color space detected as well as the color range.

[davilla]

It would be helpful to understand what you guys know about HDR. I'm not the expert on it

1st thing is what exactly determines if something should be HDR, HEVC Main10 of course but what else ? Existence of a color range of bt2020 and above ?

I've made some changes, it will be in the next pushed out testflight.

First change is to vector (if allowed) everything that is HEVC Main10 or has a color range of bt2020 and above to AVFoundationCodec. VideoToolBoxCodec uses our GLES rendering which is subject to how we determine color range and levels. AVFoundation is a pure bypass of our GLES renderer so it's up to iOS/tvOS to do the right thing. The only option we have is to switch display rate and pick SDR, HDR or Dolby Vision. AVFoundationCodec will look at the color range, and pick HDR if bt2020 or above. Then make some guesses about Dolby Vision. Debuglog will show which it picked.

Dolby Vision is a problem child because FFMpeg does not pass up the right codec tag and we have to make some guesses. On the list is to patch FFMpeg to do the right thing and eliminate the guessing.

[wesk05]

Kodi shows information like this:
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

If we can get similar information, checking for the transfer characteristics (smpte2084) will be fail-proof for HDR10.

[cosmoxl]

Kodi shows information like this:
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

If we can get similar information, checking for the transfer characteristics (smpte2084) will be fail-proof for HDR10.

MrMC does show that info.. I'm looking at it right now.

[Golge77]

Kodi shows information like this:
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

If we can get similar information, checking for the transfer characteristics (smpte2084) will be fail-proof for HDR10.

MrMC does show that info.. I'm looking at it right now.

It would be nice to have a command or a button in the gui to get hold of that codec info.
As I understand it you have to use for example a computer and webbrowser to acess that info

[cosmoxl]

Kodi shows information like this:
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

If we can get similar information, checking for the transfer characteristics (smpte2084) will be fail-proof for HDR10.

MrMC does show that info.. I'm looking at it right now.

It would be nice to have a command or a button in the gui to get hold of that codec info.
As I understand it you have to use for example a computer and webbrowser to acess that info

yep, unfortunately some time ago the official kodi app (like for iphone) removed support for MrMC for bringing up codec info by long pressing "i". That was the easiest way without browsing to MrMC's web server.

I don't know what's behind adding to the OSD, that might be too difficult. But, perhaps a setting for expert users that, when enabled, will always show codec info upon playback is possible?

[davilla]

Please test using the (180125.1415) @20180125-d72c486 Testflight for v3.4.1.

Made some changes to HEVC/HDR color range detection.

Also, remember that bt709 will get assigned to VideoToolBoxCodec unless you disable it. VideoToolBox uses core GLES mappings for rendering. AVFoundationCodec bypasses core GLES rendering completely and uses native color range handling.

It would also help to say exactly what you expect for a given test video. Just saying it's clipped makes me guess what I should be seeing So something like "I expect to see gray lever 16 and I only see gray level 18" goes a long way in understanding.

[davilla]

yes/no/maybe ?

[Boris Blank]

Hi davilla,

Sorry davilla, been distracted a bit at home.

I'll defer to wesk05 on this, I have no idea of the finer details that may well be required to investigate and resolve this.

However, just to clarify, Wesk05 refers to this black level pattern https://mrmc.tv/forum/viewtopic.php?p=11819#p11819 when he says that;

This to me looks like another tvOS problem associated with HDR processing. The upper and lower 2% of the grayscale is being clipped. In the referenced test pattern, YCbCr digit value of 81 and lower are output as 64.

Similarly, everything above digit value of 922 (98%) is clipped. White clipping isn't going to be a problem because at present most HDR content have the maximum luminance of mastering display set to 4000 nits (855) or 1000 nits (723).

I don't have a picture of the contrast blown-whites at 98% and above, I'll try for one tomorrow. Having problems resetting MrMC's contrast back to default at the moment (don't ask)!

Just to confirm, I just checked 20180125-d72c486 Testflight for v3.4.1 and the black level error is the same as the post wesk05 refers to.

May I also thank yourself and wesk05 for all your help, very much appreciated!

[cosmoxl]

Hi davilla,

Sorry davilla, been distracted a bit at home.

I'll defer to wesk05 on this, I have no idea of the finer details that may well be required to investigate and resolve this.

However, just to clarify, Wesk05 refers to this black level pattern https://mrmc.tv/forum/viewtopic.php?p=11819#p11819 when he says that;

This to me looks like another tvOS problem associated with HDR processing. The upper and lower 2% of the grayscale is being clipped. In the referenced test pattern, YCbCr digit value of 81 and lower are output as 64.

Similarly, everything above digit value of 922 (98%) is clipped. White clipping isn't going to be a problem because at present most HDR content have the maximum luminance of mastering display set to 4000 nits (855) or 1000 nits (723).

I don't have a picture of the contrast blown-whites at 98% and above, I'll try for one tomorrow. Having problems resetting MrMC's contrast back to default at the moment (don't ask)!

Just to confirm, I just checked 20180125-d72c486 Testflight for v3.4.1 and the black level error is the same as the post wesk05 refers to.

May I also thank yourself and wesk05 for all your help, very much appreciated!

If you have contrast controls that means you're not using AVFoundation. AVF is the proper way to playback HDR material.