MadVR in use with LG OLED Thread [Archive] - Page 41

aron7awol

13th September 2021, 01:49

you have to use bt709 in/source and bt 2020 destination.

this way madVR is forced to do the gamut conversation to bt 709 to feed the 3D LUT.

now you set send bt 2020 and that should be it.
i'M on AMD i can't send bt 2020 so i can't test this.
This is an interesting idea, and makes sense as an approach.

I just tried it, but where I am unsure is what type of profile and tone curve I should be using. I tried a bunch of different combos of icms and tone curve settings, but gamma ended up way off in each case I tried.

For example, I tried Rec709 2.2 for source profile, and BT2020 ST2084 10000nit for destination profile, and I tried gamma 2.2, unmodified, and 2084 hard clip at 10000 nits as options for tone curve. All ended up with bad gamma.

Do I need a BT2020 gamma 2.2 icm for this? If so, I'm not sure where to get one.

quietvoid

13th September 2021, 01:58

He noticed oversaturation doing this with mpv, which is the same I noticed when I tested the 3DLUT with madVR.

Is this expected? If not, what do we think is going wrong?

I think it is expected, converting to 709 is not the same as keeping 709 in 2020 container.

I've tested this out by reencoding the S&M benchmark but I don't know if the method is accurate to compare WCG.
The final video has the original WCG clip on the left, and the 709 on the right.

VapourSynth script:
src_path = Path("SM.mkv")
src = core.ffms2.Source(src_path)

src = src.resize.Spline36(width=1920, height=1080)

src2 = src.resize.Spline36(matrix_in_s="chromancl", matrix_s="chromancl", transfer_in_s="st2084", transfer_s="st2084", primaries_in_s="2020", primaries_s="709")
src2 = src2.resize.Spline36(matrix_in_s="chromancl", matrix_s="chromancl", transfer_in_s="st2084", transfer_s="st2084", primaries_in_s="709", primaries_s="2020")

src = core.std.StackHorizontal([src, src2])
src = src.std.AddBorders(top=540, bottom=540)

src.set_output()

Encoded with x265:
vspipe -y source.vpy - | x265_10 -D 10 --y4m --level-idc 5.1 --crf 12 --preset ultrafast --repeat-headers --aud --hrd --no-cutree --colorprim 9 --colormatrix 9 --transfer 16 --chromaloc=2 --hdr10-opt --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(100000000,50)" --max-cll=10000,1616 --input - --output default.hevc

You can find a snippet of the video here: https://mega.nz/file/MY9xVYxQ#1MJO-T7iCzMrTMjRCL8Jq4T6Gu5dRQoH0w066adsHB4
At least to me it makes sense when playing on the TV.

aron7awol

13th September 2021, 03:51

That S&M demo looks great! Thank you!

Balling

14th September 2021, 18:35

Especially the second is really amazing, no need to click around and wait to switch between PC and non-PC mode! Although it takes a second or so, just like when switching into/out from Game preset.

Does HDMI 2.0b banding happen there too? Or is that decoding correctly like in HDMI 2.1 FRL? As for colorGamut, you can change to BT.2020 for SDR BT.2020 primaries sources?

Balling

14th September 2021, 18:41

>converting to 709 is not the same as keeping 709 in 2020 container.

No, that is the same. LG will convert BT.2020 to 709 primaries by converting to whatever the display is (99% DCI-D65 or P3 or whatever including outside DCI for low luminance colors) for SDR. If we talking about HDR, of course better not to touch PQ.

Of course in practice keeping should be better unless LG really effed up somewhere with 3DLUT or BT.2087.

huhn

14th September 2021, 19:01

did you even try to understand what they are trying to do?

Balling

14th September 2021, 19:07

This is an interesting idea, and makes sense as an approach.

I just tried it, but where I am unsure is what type of profile and tone curve I should be using. I tried a bunch of different combos of icms and tone curve settings, but gamma ended up way off in each case I tried.

For example, I tried Rec709 2.2 for source profile, and BT2020 ST2084 10000nit for destination profile, and I tried gamma 2.2, unmodified, and 2084 hard clip at 10000 nits as options for tone curve. All ended up with bad gamma.

Do I need a BT2020 gamma 2.2 icm for this? If so, I'm not sure where to get one.
There is a lot of things that are wrong with this. First of all there is no such thing as 2.2 gamma. You are supposed to use 2.4 gamma on OLED. If you file is a screen recording, you were supposed to tag it with screen profile, if it is sRGB, then use BT.709 primaries, sRGB transfer and BT.709 matrix (matrix should be the same as primaries for optimal code points utilisation). sRGB is not 2.2 gamma. That is just wrong. AdobeRGB is 2.2 gamma, just like one of older tranfers from H.273. To set correct sRGB curve you are supposed to use parametric curve encoding introduced in ICC v4, 3rd type: gamma = 2.399994 (just 2.4 actually but no perfect round), a = 0.947861, b = 0.052139, c = 0.077393, d = 0.040451. https://github.com/saucecontrol/Compact-ICC-Profiles/blob/master/profiles/sRGB-v4.icc?raw=true Same about BT.709, but as I said here 2.4 gamma is supposed to be used since PQ is display referred.

Next: you should set SDR white point. It is supposed to be 203 nits for 1000 nits container. Next, PQ should be correctly done. ICC only last year introduced PQ in ICC.

And last you need to color manage to BT.2020 primaries... matrix should also change from BT.709 to 2020-ncl and also you need to either present in RGB or YCbCr 444 or for the case of 420 change chroma siting from left to top left, using FIR.

Now after that you need to switch the display in HDR mode with BT.2020 primaries and output it.

huhn

14th September 2021, 19:39

so the answer is no...

huhn

15th September 2021, 06:17

Does HDMI 2.0b banding happen there too? Or is that decoding correctly like in HDMI 2.1 FRL?

it happens with 1.4 too

As for colorGamut, you can change to BT.2020 for SDR BT.2020 primaries sources?
yes and no LG does not use words like bt 709 or bt 2020.

>converting to 709 is not the same as keeping 709 in 2020 container.

No, that is the same. LG will convert BT.2020 to 709 primaries by converting to whatever the display is (99% DCI-D65 or P3 or whatever including outside DCI for low luminance colors) for SDR. If we talking about HDR, of course better not to touch PQ.
why would they? he wants to clip/convert the gamut and beeen able to switch between both wide "bt2020" bt709 because converting bt 709 or bt 709 in bt 2020 are not the same

Of course in practice keeping should be better unless LG really effed up somewhere with 3DLUT or BT.2087.
what has the EOTF to do with this if we just want to do gamut mapping?
There is a lot of things that are wrong with this.
we will see...
First of all there is no such thing as 2.2 gamma.
but there clearly is and that's actually needed for tone mapping.
You are supposed to use 2.4 gamma on OLED.
gamma is a choice usually based on room lightning not a presentation technology. BTW. LG correctly sets to gamma 2.2 (you will not get is but that a different story)
If you file is a screen recording, you were supposed to tag it with screen profile, if it is sRGB,...
no if he screen records or not this will not change the source characteristics in general if it is a video file with bt 709 it is even now sill bt 709 because nothing changed the sRGB in windows calibration is irrelevant for that.
...then use BT.709 primaries, sRGB transfer and BT.709 matrix (matrix should be the same as primaries for optimal code points utilisation). sRGB is not 2.2 gamma. That is just wrong.
so where did anyone claim sRGB is gamma 2.2 while it uses gamma 2.2 it's starts flat giving it an effective gamma of ~2.4 but why would that matter for anything here at all. this is about using a TV with a video player where comes sRGB into the player?

AdobeRGB is 2.2 gamma, just like one of older tranfers from H.273. To set correct sRGB curve you are supposed to use parametric curve encoding introduced in ICC v4, 3rd type: gamma = 2.399994 (just 2.4 actually but no perfect round), a = 0.947861, b = 0.052139, c = 0.077393, d = 0.040451. https://github.com/saucecontrol/Compact-ICC-Profiles/blob/master/profiles/sRGB-v4.icc?raw=true Same about BT.709, but as I said here 2.4 gamma is supposed to be used since PQ is display referred.
no gamma 2.2 is need if PQ tone mapping is needed because that's what is assumed as the source gamma. and if it would be any other gamma nothing would change because it's just for relativity as long as both the input and the assumption match the results is valid.
Next: you should set SDR white point. It is supposed to be 203 nits for 1000 nits container. Next, PQ should be correctly done. ICC only last year introduced PQ in ICC.
you really have no clue what we are doing here right? this is completely irrelevant.
And last you need to color manage to BT.2020 primaries... matrix should also change from BT.709 to 2020-ncl and also you need to either present in RGB or YCbCr 444 or for the case of 420 change chroma siting from left to top left, using FIR.
windows works in RGB so it doesn't matter what the chroma loc on the GPU driver is because the GPU driver is doing the chroma subsampling and as long as the GPU HDMI and the end device agree on the same chroma loc you are fine but you have no way to change this anyway.
Now after that you need to switch the display in HDR mode with BT.2020 primaries and output it.

maybe now is a good timing to tell you that windows "can't" gamut map using icc files.

huhn

15th September 2021, 07:23

took me a couple of mins but here is a 3D LUT that should work.

i just run into an unexpected issue a bt 2020 profile with a bt 709 tone curve is created with gamma 2.6 in displaycal while a bt 709 profile with a bt 709 tone curve is created with 2.2 i was expectign it to be the same so it doesn't matter what the number is if that would be the case.

after i matched them it works "perfectly" now.
if you play a bt 709 and set madVR to this device is calibrated to bt 2020 or you use this 3D LUT you will get the "same" results.
it's not perfect there still seems to be a gamma difference in the 0.0x range if not 0.00x

but here you go:
https://drive.google.com/file/d/1MpUyFI2v7BwFsg7oIGezGkWeBOGeCZj7/view?usp=sharing

not compressed i could not upload it for some reason if i do that.

Balling

15th September 2021, 19:06

"it happens with 1.4 too"

Do not have any hdmi 1.4 devices, only 2.0.

"and no LG does not use words like bt 709 or bt 2020."

On LG CX there is an override menu with it, so yes, they do.

"what has the EOTF to do with this if we just want to do gamut mapping?"

BT.2087 has indeed nothing to do with EOTF. Mostly. Though it indeed color manages on linear light.

"LG correctly sets to gamma 2.2"

The fact that it greys out gamma 2.2 means nothing. Yes, there are some appearance of underlying hacks of 2.2 gamma, but that is not an argument. As for "gamma is a choice usually based on room lightning not a presentation technology" you cannot do such a choice with PQ, not really, it is absolute and is meant to be looked in dark room. So there is no point, 2.4 gamma must be applied. Also, BT.1886 depends on presentation tech.

"not this will not change the source characteristics in general"

You are wrong. Use mpv with target-trc=srgb and you will see.

"while it uses gamma 2.2 it's starts flat giving it an effective gamma of ~2.4 but why would that matter for anything here at all."

Because sRGB uses 2.4 gamma internally with linear spline that makes it almost 2.2. Just like BT.709 OETF that is 1/0.45= 2.2222... gamma, yet is 1.961 gamma since it has a linear spline.

"windows works in RGB so it doesn't matter what the chroma loc on the GPU driver is because the GPU driver is doing the chroma subsampling and as long as the GPU HDMI and the end device agree on the same chroma loc you are fine but you have no way to change this anyway."

It is hard to make Windows work in YCbCr, but possible. You cannot control HDMI sample location. What I was talking about was SDR convertion of a source to top left chroma.

huhn

15th September 2021, 20:07

Do not have any hdmi 1.4 devices, only 2.0.
HDMI is backwards compatible just disable deep what ever HDMI stuff in TVs for connection and they will use HDMI 1.4 and again completely pointless.
On LG CX there is an override menu with it, so yes, they do.
i have an CX here no. i can find bt 1886 which is absolutely pointless for this TV. and if you would try to follow what he wants to test what's your point?
BT.2087 has indeed nothing to do with EOTF. Mostly. Though it indeed color manages on linear light.

eotf... what has this to do with the topic?

The fact that it greys out gamma 2.2 means nothing. Yes, there are some appearance of underlying hacks of 2.2 gamma, but that is not an argument. As for "gamma is a choice usually based on room lightning not a presentation technology" you cannot do such a choice with PQ, not really, it is absolute and is meant to be looked in dark room. So there is no point, 2.4 gamma must be applied. Also, BT.1886 depends on presentation tech.
it doesn't gray it out it uses it by default. and that also doesn't mean you will get 2.2.
PQ does not care about the gamma and this is a madVR thread and madVR needs gamma 2.2 to tone map if you like it or not the TV doesn't care what you use because it'S all about relativity.
gamma is relative to room brightness if you have problem with that have a problem with that.
and about PQ is absolute dolby said no. looks like they found out that not everyone side in a dark room.

You are wrong. Use mpv with target-trc=srgb and you will see.
you just tell it to change it...
so it does. cool. so why am i wrong now?
you just tell mpv that your display is calibrated to sRGB instead of BT 709 is it?
Because sRGB uses 2.4 gamma internally with linear spline that makes it almost 2.2. Just like BT.709 OETF that is 1/0.45= 2.2222... gamma, yet is 1.961 gamma since it has a linear spline.
so now bt 709 is gamma 2.22 (which is mathematical correct) not 2.4? are you use we don't have to use gamma 2.22 now because you said so?
It is hard to make Windows work in YCbCr, but possible. You cannot control HDMI sample location. What I was talking about was SDR convertion of a source to top left chroma.
you can use what ever chroma loc you want and even if you convert to SDR it doesn't matter because the GPU driver is still doing the conversation so what's your point?
you know you can define it while encoding...

so because windows can work in ycbcr what has this to do with anything here why would you chroma subsample in the first place why would you even mention it?

aron7awol

15th September 2021, 20:21

took me a couple of mins but here is a 3D LUT that should work.
Thanks! I'll give it a try.

Since you obviously have a MUCH better handle of this stuff than I do, can you think of a way to go a step further and compare something like 90% of P3 with 100%? Obviously "90% of P3" doesn't tell you exactly where the coverage is falling short, but it's just an example. One might choose to hit ~90% by simply pulling the green primary back while leaving red and blue at the limits, or something else. Essentially, I think I'm asking if it's possible to set arbitrary primaries rather than do a full gamut?

I looked into doing similar with VapourSynth but it seems it only has specific presets, and it would require modifying the source and recompiling, which I'm afraid I am not set up for. I did manage to get VapourSynth working and use the script from @quietvoid which was very helpful! I was actually surprised and how subtle the differences often are even between 709 and P3, which makes me wonder even more how subtle the difference must be between 90% of P3 and 100% or similar.

Balling

16th September 2021, 07:50

"so now bt 709 is gamma 2.22 (which is mathematical correct) not 2.4? are you use we don't have to use gamma 2.22 now because you said so?"

No, bt.709 is gamma 1.961. The inverse of 1.961 is also called 1.961. Yet, BT.709's EOTF is not an inverse. Okay? Oogh. It is different because camera is supposed to be in much lighter environment! It is called dim surround compensation.

"i have an CX here no. i can find bt 1886 which is absolutely pointless for"

That is how you are supposed to watch video, BUT NOT WEB PAGES. Okay? There is a secret menu where you can override stuff on a CX.

"it doesn't gray it out it uses it by default"

No, it does not. It uses PQ or HLG, which is not gamma. BT.709 and sRGB are also not gamma, only BT.1886 can be called gamma, but only on perfect display like OLED.

"gamma is relative to room brightness if you have problem with that have a problem with that."

The correct term is scene referred. AND NO, PQ IS DISPLAY referred. You cannot manipulate it, Dolby IQ being an exception. But if you will read the patent on it, it is insane. https://patents.google.com/patent/WO2018119161A1/en

"you just tell mpv that your display is calibrated to sRGB instead of BT 709 is it?"

Instead of BT.1886, yes. The fact of the matter it is the only player that can do correct change of transfer, except Apple of course. Absolutely the same result you can get by just changing to BT.1886 in LG TV display. The result is darker and removes blooming.

Balling

16th September 2021, 08:21

@aslar42 "By opening CRU I see no trace of 2160p23 and 2160p59 resolutions, only 24, 25, 30, 50 and 60 (plus 100 and 120)."

Well, open your eyes. There is no such thing as 23 or 59. There is only 24/1.001 and 60/1.001 or 24.000 and 60.000 and it is almost perfectly refered to as such in new windows 10 display menu. Same about 30, 120. THOSE are included in TV resolutions (VICs) integer rate, PC must switch the alternate clock! DTD only support 3 decimals so they are useless.
Do not play with CRU, it corrupts EDID. Yes, even after the update. Also, you will have to apply the change in registry by hand.

An example:

Video Data Block:
VIC 96: 3840x2160 50.000 Hz 16:9 112.500 kHz 594.000 MHz
VIC 95: 3840x2160 30.000 Hz 16:9 67.500 kHz 297.000 MHz
VIC 94: 3840x2160 25.000 Hz 16:9 56.250 kHz 297.000 MHz
VIC 93: 3840x2160 24.000 Hz 16:9 54.000 kHz 297.000 MHz
VIC 16: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz
VIC 5: 1920x1080i 60.000 Hz 16:9 33.750 kHz 74.250 MHz
VIC 4: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz
VIC 3: 720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz
VIC 2: 720x480 59.940 Hz 4:3 31.469 kHz 27.000 MHz
VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz
VIC 17: 720x576 50.000 Hz 4:3 31.250 kHz 27.000 MHz
VIC 18: 720x576 50.000 Hz 16:9 31.250 kHz 27.000 MHz
VIC 19: 1280x720 50.000 Hz 16:9 37.500 kHz 74.250 MHz
VIC 20: 1920x1080i 50.000 Hz 16:9 28.125 kHz 74.250 MHz
VIC 31: 1920x1080 50.000 Hz 16:9 56.250 kHz 148.500 MHz
VIC 14: 1440x480 59.940 Hz 4:3 31.469 kHz 54.000 MHz
VIC 15: 1440x480 59.940 Hz 16:9 31.469 kHz 54.000 MHz
VIC 29: 1440x576 50.000 Hz 4:3 31.250 kHz 54.000 MHz
VIC 30: 1440x576 50.000 Hz 16:9 31.250 kHz 54.000 MHz
VIC 6: 1440x480i 59.940 Hz 4:3 15.734 kHz 27.000 MHz
VIC 7: 1440x480i 59.940 Hz 16:9 15.734 kHz 27.000 MHz
VIC 21: 1440x576i 50.000 Hz 4:3 15.625 kHz 27.000 MHz
VIC 22: 1440x576i 50.000 Hz 16:9 15.625 kHz 27.000 MHz
VIC 97: 3840x2160 60.000 Hz 16:9 135.000 kHz 594.000 MHz

Here every 60.000, 24.000, 30.000 also support alternate clock of /1.001 (except VIC 1, 2, 3, 6, 7 and those that have 50 Hz). Simple as that!!

Same about those, BTW (except 100 Hz and 50 Hz, again).

YCbCr 4:2:0 Capability Map Data Block:
VIC 97: 3840x2160 60.000 Hz 16:9 135.000 kHz 594.000 MHz
VIC 96: 3840x2160 50.000 Hz 16:9 112.500 kHz 594.000 MHz
VIC 118: 3840x2160 120.000 Hz 16:9 270.000 kHz 1188.000 MHz
VIC 117: 3840x2160 100.000 Hz 16:9 225.000 kHz 1188.000 MHz
VIC 102: 4096x2160 60.000 Hz 256:135 135.000 kHz 594.000 MHz
VIC 101: 4096x2160 50.000 Hz 256:135 112.500 kHz 594.000 MHz
VIC 219: 4096x2160 120.000 Hz 256:135 270.000 kHz 1188.000 MHz
VIC 218: 4096x2160 100.000 Hz 256:135 225.000 kHz 1188.000 MHz

huhn

16th September 2021, 10:20

That is how you are supposed to watch video, BUT NOT WEB PAGES. Okay? There is a secret menu where you can override stuff on a CX.
we are in a thread about madVR and oled TVs let's talk about webpages...

No, it does not. It uses PQ or HLG, which is not gamma. BT.709 and sRGB are also not gamma, only BT.1886 can be called gamma, but only on perfect display like OLED.
but we are using madVR here to tone map it get it please.
on an oled bt 1886 is 2.4 making it pointless.

"gamma is relative to room brightness if you have problem with that have a problem with that."

The correct term is scene referred. AND NO, PQ IS DISPLAY referred. You cannot manipulate it, Dolby IQ being an exception. But if you will read the patent on it, it is insane. https://patents.google.com/patent/WO2018119161A1/en
last time we do gamma here not PQ. a 3D LUT for PQ to PQ is no possible here. and we have to use 2.2 because that's expected
"you just tell mpv that your display is calibrated to sRGB instead of BT 709 is it?"

[qoute]Instead of BT.1886, yes. The fact of the matter it is the only player that can do correct change of transfer, except Apple of course. Absolutely the same result you can get by just changing to BT.1886 in LG TV display. The result is darker and removes blooming.[/QUOTE]

selecting bt 1886 is the same as selecting gamma 2.4 in them what has this to do with apple or any other source device.

the gamma selection after calibration and only if you aim for the same gamma will make sure that an untouched input image will be displayed with the selected gamma.
completely irrelevant for this topic here. even if i calibrated my TV to gamma 2.4 the 3d LUT has to be 2.2 for the destination if we want to tone map end of story.

Well, open your eyes. There is no such thing as 23 or 59. There is only 24/1.001 and 60/1.001 or 24.000 and 60.000 and it is almost perfectly refered to as such in new windows 10 display menu. Same about 30, 120. THOSE are included in TV resolutions (VICs) integer rate, PC must switch the alternate clock! DTD only support 3 decimals so they are useless.
Do not play with CRU, it corrupts EDID. Yes, even after the update. Also, you will have to apply the change in registry by hand.

23, 29, 59 and much more exist they are synonymous.

flaviowolff

16th September 2021, 17:58

Quick question, guys:
Is motion messed up somehow if Real Cinema is off (like in PC mode) but the PC output is set to 23.976 or 119.88 Hz?
It's kind of confusing to me whether the 5:5 pulldown from Real Cinema is necessary when the source is already outputting an integer multiple of the content frame rate.
(not talking about smooth motion)
Ty

huhn

16th September 2021, 22:03

120 is without a doubt not doing a 3:2(6:4) 23p in and out side of PC mode are also perfect on my device but i have also a flawless PC mode so that'S not worth a lot.

flaviowolff

16th September 2021, 23:24

120 is without a doubt not doing a 3:2(6:4) 23p in and out side of PC mode are also perfect on my device but i have also a flawless PC mode so that'S not worth a lot.

According to my quick testing (running a judder hdr10 23.976fps pattern test), pc mode at both 119.88 or 23.976hz are perfect. zero judder. Looks the same as moving out of pc mode and turning real cinema (actually, "cinema screen" on my C1) on.

Thats why I'm questioning here. It got me curious. Is Real Cinema unnecessary if the source is already at the correct refresh rate?

The standard recommendation on this thread is to always turn it on, regardless of the refresh rate, except when using smooth motion.

VBB

16th September 2021, 23:57

We've discussed this before, and like you said, with PC mode there is zero judder, even though RC is forced off. The same is not the case in normal HDMI mode, where you will get judder if you disable RC. Fact is that nobody outside of LG knows exactly what RC does and why it is necessary to enable it in normal mode, where it also creates a ton of input lag (at least on the older models). Frustrating for those of us who can't use PC mode... ;)

SamuriHL

17th September 2021, 00:21

You ain't kidding about that. PC mode would be nice. RC most likely compensates for the delay caused by all the processing in normal HDMI mode to the best of its ability. With PC mode, there isn't any of that processing stuff going on.

Balling

17th September 2021, 04:30

"23, 29, 59 and much more exist they are synonymous."

No, they are not. It is also just a mistake Microsoft did that they fixed in Windows 10 20H2, it is still not perfect notation, yet better than nothing. Best notation is in xrandr of course. https://en.wikipedia.org/wiki/24p#Confusion_with_23p,_29p,_59p,_119p_in_Windows

"120 is without a doubt not doing a 3:2(6:4) 23p"

It is doing 5:5 pulldown. And no. 23 cannot be presented in 120. Only 24 in 120 or 24/1.001 in 120/1.001. All of those are supported on LG C9 and higher.

"let's talk about webpages"

You all started it when you mentioned 2.2 gamma, which is actually almost sRGB!

"even if i calibrated my TV to gamma 2.4 "

You do not need to with LG C9 and higher. /facepalm There is a seperate option for that.

"pc mode at both 119.88 or 23.976hz are perfect. zero judder"

Of course it is perfect. But again! There is no 23.976 or 119.88, only 120/1.001 and 24/1.001. Just yesterday I saw a dolby vision mp4 with 23976/1000 inside, yet there is NO such thing.

"outside of LG knows exactly what RC does"

It is extracting the whatever pulldown cadence is there. Be it 2:3, be it 2:3:3:2, be it 2:2:2:2:2:2:2:2:2:2:2:3, etc.

"selecting bt 1886 is the same as selecting gamma 2.4 in"

No. mpv with target-trc=srgb will have to change the nonlinear R'G'B' to different transfer while with BT.1886 it will not have to touch it, as it does without any options. Same about Chrome, BTW. Only apple devices do that first thingy by default in Quicktime and Safari.

Asmodian

17th September 2021, 04:43

There is no 23.976 or 119.88, only 120/1.001 and 24/1.001.

LOL Pedantic much? :rolleyes:

We all know that 23p really means 24/1.001, it is just short hand so you don't have to write fractions all the time.

You all started it when you mentioned 2.2 gamma, which is actually almost sRGB!

Or what you would use for a bright room calibration? What are you actually trying to say? :confused:

Balling

17th September 2021, 04:47

"Or what you would use for a bright room calibration?"

Unfortunately you will have to use sRGB, of course it is not perfect, TrueTone is required for this. The most important part is not 100-120 nits but more for bright room though, not gamma.

Balling

17th September 2021, 04:51

"that 23p really means 24/1.001"

Yet you do not know somehow that 24.000 modes in VIC support /1.001 modes too that you switch for on the fly, no new handshake needed. Read the standard.

Asmodian

17th September 2021, 04:51

Unfortunately you will have to use sRGB, of course it is not perfect, TrueTone is required for this.

What are you talking about? Care to elaborate, because this line means absolutely nothing to me.

If I calibrate to 2.2 it looks better in a bright room than if I calibrate to 2.4. What about this situation requires me calibrating to sRGB instead?

Yet you do not know somehow that 24.000 modes in VIC support /1.001 modes too that you switch for on the fly, no new handshake needed. Read the standard.

Again, a totally meaningless line to me. When I set 24 Hz in Windows I get 24 Hz, and it does not support 24/1.001. My TV does not support 24/1.001 when I send it 24.000 Hz video. What are you talking about?

Edit: How was this a response to 23p = 24/1.001? What does 24.000 modes in VIC have to do with what we all mean when we say 23p or 23Hz.

Please explain better; you seem to know the standards but you also seem to be posting only to say we are wrong and you know better, not to help anyone understand anything. :(

Balling

17th September 2021, 06:53

"When I set 24 Hz in Windows I get 24 Hz, and it does not support 24/1.001"

It does, LG C9 and higher support 24/1.001. That is what Microsoft calls 23p, you can check that in new windows 10 display menu, it will print 23.976, which is actually 24/1.001.

>TV does not support 24/1.001 when I send it 24.000 Hz video

It does, it will drop every 1001 frame though in that case. You must set to 24/1.001 if you play 24/1.001 content and to 24.000 if you play 24.000. Same about 30 fps, 60 fps and 120 fps. There is no simple way to convert between the two.

What you also do not seem to understand that DTD (detailed timing) of 23.976 is not the same as that alternate mode of 24/1.001! Sigh. Why?? I understand that windows really effed up with this, but still.

>What are you talking about?

1 integer mode in EDID actually is two different modes. Okay?

>2.2 it looks better in a bright room than if I calibrate to 2.4.

Yes, but that is not perfect. Perfect way is to adapt to ambient light and illuminant. An example: Japan anime is often done in D93, not D65 ambient illuminant. What is supposed to happen is Netflix chromatically adapts video to look the same under D65 as it was looking under D93. Simple. Same about light, you apply different EOTF depending on whether it is a bright room or dark room and how broght that is. Even some crazy stuff like red light light or ultraviolet can be supported. Please read the patent, LOL.

huhn

17th September 2021, 07:49

It does, LG C9 and higher support 24/1.001. That is what Microsoft calls 23p,...
and call it 23p too.

should we tell him that nvidia uses 23 too?
and that windows 11 still uses 23 in the display adapter properties it's just synonymous to 24000/1001

Yet you do not know somehow that 24.000 modes in VIC support /1.001 modes too that you switch for on the fly, no new handshake needed. Read the standard.
tell that the desktop composition.
no one ask about vic modes here.

No. mpv with target-trc=srgb will have to change the nonlinear R'G'B' to different transfer while with BT.1886 it will not have to touch it, as it does without any options. Same about Chrome, BTW. Only apple devices do that first thingy by default in Quicktime and Safari.

the TV has no clue about any of that and even if i do a 3d LUT with bt 1886

You all started it when you mentioned 2.2 gamma, which is actually almost sRGB!

madVR needs gamma 2.2 as the destination for a 3D LUT if tone mapping is done not sRGB it's completely irrelevant here completely pointlessly taking out of the air by you. followed by you have to use gamma 2.4 on a OLED which wow...

You do not need to with LG C9 and higher. /facepalm There is a seperate option for that.
your "options" mean nothing to my colorimeter.

Unfortunately you will have to use sRGB, of course it is not perfect, TrueTone is required for this. The most important part is not 100-120 nits but more for bright room though, not gamma.
no i have to use gamma 2.2 if tone mapping is used in madVR else i can aim at what ever i want 2.35 be my guest.

Of course it is perfect. But again! There is no 23.976 or 119.88, only 120/1.001 and 24/1.001. Just yesterday I saw a dolby vision mp4 with 23976/1000 inside, yet there is NO such thing.

a file does not have to follow any refreshrate so it exists.
it's just someone using a source filter that read the wrong frame interval. and why would you go from a TV to a random file spec? why...

No. mpv with target-trc=srgb will have to change the nonlinear R'G'B' to different transfer while with BT.1886 it will not have to touch it, as it does without any options. Same about Chrome, BTW. Only apple devices do that first thingy by default in Quicktime and Safari.
but why would you even care about a sRGB...

i'm talking about the TV an OLED to it doesn't know and doesn't care what you do on your PC.

Balling

17th September 2021, 10:55

"should we tell him that nvidia uses 23 too?
and that windows 11 still uses 23 in the display adapter "

These are the same menu, nvidia control panel just uses same API device manger does. Again, in the new menu there is a direct 23.976 written, so it is just a bug. Do I need to give a screenshot? LOL, what? Here: old menu shows 119 Hz yet the new one shows 120/1.001
https://forum.ixbt.com/post.cgi?id=attach:10:56858:3621:2.png

huhn

17th September 2021, 11:48

glad that you are not the person that makes the decision what a bug is...

will they change it one day maybe will the synonymous meanings stay you better believe that.

ashlar42

17th September 2021, 13:38

Troll added to ignore list. Know-it-alls have no use for me.

flaviowolff

17th September 2021, 14:12

"When I set 24 Hz in Windows I get 24 Hz, and it does not support 24/1.001"

It does, it will drop every 1001 frame though in that case. You must set to 24/1.001 if you play 24/1.001 content and to 24.000 if you play 24.000. Same about 30 fps, 60 fps and 120 fps. There is no simple way to convert between the two.

Regarding 23.976 (24.1001) fps content, is there an advantage in setting Windows to 23.976(24.1001) instead of 119.88(120.1001), in pc mode?

biship

17th September 2021, 16:56

Don't you want madvr to switch to the fps of the content regardless?

flaviowolff

17th September 2021, 17:06

Don't you want madvr to switch to the fps of the content regardless?

yes, but if 119.88 gives the same result as 23.976, i'd prefer it, so I can go in and out of fullscreen seamlessly.
Besides, I don't always use madvr. I also watch netflix on my pc, to benefit from spatial audio with headphones.
as a bonus, 119.88 would be nice to toggle smooth motion on/off on the fly.

so, is there any benefit from using 24.976 instead of 119.88 in Windows?

according to my quick testing, it's the same, but i'd like to know if there is a theoretical difference.
ty

huhn

17th September 2021, 19:27

you can not frame interpolate on the TV side but that'S a bonus in my book.

flaviowolff

17th September 2021, 19:35

yep, i'm not willing to.

summing up my question: when watching 23.976fps movies in pc mode (Windows), smooth motion off, is there any difference in motion quality between setting Windows' output to 23.976 or 119.88hz?

Asmodian

17th September 2021, 22:18

summing up my question: when watching 23.976fps movies in pc mode (Windows), smooth motion off, is there any difference in motion quality between setting Windows' output to 23.976 or 119.88hz?

No, no difference even theoretically. I always use 119 instead of 23 for 23.976 content. The mouse is still smooth and everything. ;)

It does, LG C9 and higher support 24/1.001. That is what Microsoft calls 23p, you can check that in new windows 10 display menu, it will print 23.976, which is actually 24/1.001.

Shocking! :rolleyes:

Did you seriously think my post meant that I thought my TV did not support 23.976024 Hz? You sound like you have read the specs but never used an HTPC before.

Almost all 24 and 30 fps content is drop-frame timecode, you need to understand this before you can get smooth motion on any display.

Here: old menu shows 119 Hz yet the new one shows 120/1.001

I don't see a 120/1.001 anywhere in your screenshot. 119.880 is not correct, it is 120/1.001 after all. :p

Edit:
1 integer mode in EDID actually is two different modes. Okay?

No, not okay, I still don't understand what you are trying to say. How does that work? My EDIDs have separate modes for 23.976 and 24.000 Hz, I see no packing of both into one mode or anything.

What you also do not seem to understand that DTD (detailed timing) of 23.976 is not the same as that alternate mode of 24/1.001!

You are saying there is a 23.976 time base that is not the same as 24/1.001? How would I use it? I don't understand this alternate mode stuff at all, alternate modes for a refresh rate don't make any sense to me. If it is sending 24.000 Hz what is 24/1.001 about it?

Balling

18th September 2021, 08:29

"Regarding 23.976 (24.1001) fps content, is there an advantage in setting Windows to 23.976(24/1.001) instead of 119.88(120/1.001), in pc mode?"

No. Mpv player will apply 5:5 pulldown in second case and in first TV will apply 5:5 pulldown. In both cases result is the same and is the same as if 24/1.001 was used, but you may want to turn off interpolation in mpv. Of course in the second case you will be able to do some stuff with BFI and HFR upscaler in TV itself...

P.S. also there is a very bad latency with 24 fps and even worse input lag due to how windows 10' window renderer works.

Balling

18th September 2021, 08:32

"My EDIDs have separate modes for 23.976 and 24.000 Hz, I see no packing of both into one mode or anything."

Then you TV cannot do 24/1.001. Sorry. But you should look into edid, not just saying what you see somewhere in the menu... it may be that your TV only has 23.976 DTD, which is not 24/1.001. You can use moninfo with edid-decode.

"Almost all 24 and 30 fps content is drop-frame timecode, you need to understand this before you can get smooth motion on any display."

Drop frame timecode becomes wrong after 9 hours 15 minutes, so I do not understand what it has to do with 24/1.001. Nothing. It is also not /1.001, it is 1000/999, that is why it breaks after 9 hours 15 minutes.

Oh and also SMPTE DF timecode is technically not applicable to 24. Only to 30/1.001 fps and its multiples.

Also a lot of content I work with is 24.000. And watch too: Loki, Falcon, What if... are all 24.000.

""If it is sending 24.000 Hz what is 24/1.001 about it?"
It does not send 24.000. It changes to alternate clock (/1.001), what to not understand there? :) https://github.com/torvalds/linux/commit/304a94a2e6debadd55c4e73cbec432dd57832856#diff-f1b0089a97dd0195eb24305ab63a79e3

"You are saying there is a 23.976 time base that is not the same as 24/1.001?"

Yes. That is precisely what I am saying.

Asmodian

18th September 2021, 10:20

Drop frame timecode becomes wrong after 9 hours 15 minutes, so I do not understand what it has to do with 24/1.001.

I see. :D

I think you are confusing timecodes with the real time rate video frames are processed by the video player and sent to the display. The timecodes go out of sync after 9h 15min because the video is really played at 23.97602398 fps, not 23.97600000 fps.

Or are you saying there are video files I could try to play where LAV Video would send the frames at 23.97600000 fps synced to the audio? I have only ever seen 23.97602398. None of my display modes are 23.976000000 Hz and none of the video tools I use have a "23.97600000" option for frame rate.

Or maybe I have seen a video with that framerate, but no one cares because they are all <5h long anyway?

Oh and also SMPTE DF timecode is technically not applicable to 24. Only to 30/1.001 fps and its multiples.

By "drop frame" I mean XX/1.001 fps, it is about the rate frames are sent to the display, not what the timecodes are. I don't care what the timecodes are, I use frame number when doing subtitles anyway.

I also still don't know why you are bringing any of this up, but it is interesting trying to figure out what you are talking about. :)

It does not send 24.000. It changes to alternate clock (/1.001), what to not understand there? :)

I think I see what you mean, when looking at the EDID entries in CRU they look like they are just 24, 25, 50, 60, 100, and 120 Hz, but Windows gives the separate 23.976, 59.940, and 119.880 options too. Are there really other 23.9760000 modes on some displays? That would be weird.

Or maybe I have seen video modes that were specified as 23.97600000 Hz, but the clocks have never been accurate enough to tell?

Untuned my 23p option runs at ~23.97573xxx Hz anyway, so who knows what it is specified as. That you think there might be a meaningful difference between the two on a PC is cute. :o

One drop/repeat every 9h would be a very well tuned refresh rate for madVR, anyone would be happy with that. You have to pee sometimes. :devil:

ashlar42

18th September 2021, 16:41

It's so frustrating that no Dolby Vision for HTPC use exists yes... so effing frustrating, damn...

(sorry for the useless post, I needed to vent with somebody that can undertand the frustration)

Balling

18th September 2021, 19:21

"That you think there might be a meaningful difference between the two on a PC is cute. "
Main clocks on a PC have nanosecond precision while internal clocks in PCH have picosecond precision, those last ones are used for HDMI stuff. You can use GNSS-SDR to get to those nanoseconds from GNSS sattellites and remove judder. It is very much possible. Cinema VRR requires 5 digits after decimal point!

"I think I see what you mean, when looking at the EDID entries in CRU they look like they are just 24, 25, 50, 60, 100, and 120 Hz, but Windows gives the separate 23.976, 59.940, and 119.880 options too. Are there really other 23.9760000 modes on some displays? That would be weird."

It was very weird to me too once. Yet that is precisely what happens, except those are 24/1.001 modes, AS I said. 23.976 is what DTD is, that is not VIC. Also not on some displays only: all displays ARE mandated to support both if such a VIC is there... 50 obviously does not support such an alternate clock. Again, HDMI standard 2.0 is freely available, it was leaked eons ago.

"One drop/repeat every 9h would be a very well tuned refresh rate for madVR"

There will not be any such drop. Sigh. It is perfect 24/1.001, just like video. 23976/1000 is just wrongly tagged video.

"Untuned my 23p option runs at ~23.97573xxx Hz anyway, so who knows what it is specified as"

Look into EDID. Moninfo for windows, cat for linux.

"The timecodes go out of sync after 9h 15min because the video is really played at 23.97602398 fps, not 23.97600000 fps."

Yep. 24*999/1000. Nobody uses it anymore though. There is PTS/DTS/timebase in containers and teeks in HEVC/AVC/VVC bitstreams.

aron7awol

18th September 2021, 20:38

All of this is all well and good, but you essentially came into this thread suddenly and started parading around as condescendingly as possible saying "I know more than everyone else about these topics totally unrelated to everything being discussed in this thread! Look at me!"

Asmodian

19th September 2021, 01:35

The only thing that is new to any of us (me) is that the 23Hz mode is defined as an alternative of the 24Hz mode instead of as its own mode. Of course, this is just an interesting technical detail, it is presented to us as a separate mode either way. It does make all the trouble defining custom 23Hz modes, such as having it get labeled 24Hz, make a lot more sense, so I am happy to know. :)

There will not be any such drop. Sigh. It is perfect 24/1.001, just like video. 23976/1000 is just wrongly tagged video.

There would if I had a video mode for 23.9760000000 available in my EDID.

Do you have any idea how to actually play video using madVR on a PC? :mad:

I have no idea why 24*(999/1000) was even brought up. I will stop with the off topic. :o