Log in

View Full Version : madVR - high quality video renderer (GPU assisted)


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 [877] 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329

Asmodian
21st May 2017, 21:30
Maybe, it's better to choose relative colorimetric then?

Well, I was addressing those artifacts in your test pattern.

I prefer perceptual myself, accuracy is not affected very much and the image looks better. I spent years using an absolute or relative (or luminescence axis) intent but once I got over my accuracy > all fixation I much prefer the image when using perceptual. And you never get clipping artifacts.

If the display's gamut is not very close to the source gamut then perceptual is not a good choice but when your display is already close to the source gamut then perceptual is my preferred choice.

I suggest testing the various intents and picking the one that looks best to you.

I would like to understand when I should use it. If I change the refresh to 24hz instead of 23hz I could use it? Who would win?

If you want to use 24Hz with Windows 10 or 8.1 you probably need to use it, otherwise no. I never need to use 24 or 60 Hz so I do not enable it. Nothing wins if you don't need 24 Hz. I understand there are some 24 Hz blurays but I don't think I have any. Personally, enabling smooth motion and not worrying about any of these refresh rate issues is my preferred technique.

Sideeffect
21st May 2017, 21:30
So you're saying your display still stays in SDR mode, even when you enable the "HDR and advanced color" switch in display settings? Your display only switches to HDR mode for the exact duration in which madVR is in fullscreen exclusive mode?

When I enable "HDR and advanced color" the display shows HDR enabled and the display enters HDR mode. If I open up a HDR video in windowed mode the colours are washed out.

Once I go to full screen the display shows HDR again like it detects it again and the colours display properly the same as if I would run them from a USB stick on TV.

I guessed this was because HDR is only working in directx 11 mode and even though the windows desktop is sending a HDR enabled signal to the display it still is actually only working in a directx 11 fullscreen aplication.

Some people are reporting that the Microsoft films and tv app is working with HDR in windowed mode but I disagree as I think it looks different more like HDR to SDR conversion and not as good as USB playback or madvr exclusive playback.

So madVR behaves the same way as HDR games, is that correct?

Yes MadVR behaves the same as Mass effect Andromeda and Shadow Warrior 2. But this is not a good thing as it's a pain to keep changing colour settings. I leave the Display in Nvidia colour 8-bit RGB Full for everything else. Enabling the Microsoft colours sets either RGB limited or 422 you can't really see the setting but either way it looks crap for general PC usage.

Are you using 382.19? For me this is no longer the case on this driver.

No I am still using 382.05 as the Prey hotfix didn't apply to me. What changed with HDR?

Oguignant
21st May 2017, 21:37
If you want to use 24Hz with Windows 10 or 8.1 you probably need to use it, otherwise no. I never need to use 24 or 60 Hz so I do not enable it. Nothing wins if you don't need 24 Hz. I understand there are some 24 Hz blurays but I don't think I have any. Personally, enabling smooth motion and not worrying about any of these refresh rate issues is my preferred technique.

Now I understand. I use 23hz (99% of the movies I have are 23,976 fps) and de-judder/de-blur options from the Tv. looks great.

cyber201
21st May 2017, 21:39
@madshi

Same issue of imhh11,
GTX1070, Win10 CU, latest nvidia driver, latest madvr, latest Lav Filter.
I use Kodi DSlayer v17.1. TV Samsung KS8000

If I turn on HDR slide in Windows 10, all videos are play in HDR mode.
If I turn off HDR slide in Windows 10, madvr don't turn on my TV into HDR mode. The only way is to turn on HDR slide manually when I need to play an HDR video.

Thanks madshi for your work.

igvk
21st May 2017, 21:42
Well, I was addressing those artifacts in your test pattern.

I prefer perceptual myself, accuracy is not affected very much and the image looks better. I spent years using an absolute or relative (or luminescence axis) intent but once I got over my accuracy > all fixation I much prefer the image when using perceptual. And you never get clipping artifacts.

If the display's gamut is not very close to the source gamut then perceptual is not a good choice but when your display is already close to the source gamut then perceptual is my preferred choice.

I suggest testing the various intents and picking the one that looks best to you.


Ok, I tried both relative colorimetric and perceptual.
Switched to D3D9 windowed, and both give these saturated color blotches on video.
I have wide gamut display, and certainly need to use 3dlut.
As far as I understand the problem, it's due to the fact that values 236-255 are not expected on input and simply not translated on output.
Is it correct? Or is there a way still to map them to the nearest color value that is in gamut for sRGB?

Sideeffect
21st May 2017, 21:46
So you're saying your display still stays in SDR mode, even when you enable the "HDR and advanced color" switch in display settings? Your display only switches to HDR mode for the exact duration in which madVR is in fullscreen exclusive mode?

When I enable "HDR and advanced color" the display shows HDR enabled and the display enters HDR mode. If I open up a HDR video in windowed mode the colours are washed out.

Once I go to full screen the display shows HDR again like it detects it again and the colours display properly the same as if I would run them from a USB stick on TV.

I guessed this was because HDR is only working in directx 11 mode and even though the windows desktop is sending a HDR enabled signal to the display it still is actually only working in a directx 11 fullscreen aplication.

Some people are reporting that the Microsoft films and tv app is working with HDR in windowed mode but I disagree as I think it looks different more like HDR to SDR conversion and not as good as USB playback or madvr exclusive playback.

So madVR behaves the same way as HDR games, is that correct?

Yes MadVR behaves the same as Mass effect Andromeda and Shadow Warrior 2. But this is not a good thing as it's a pain to keep changing colour settings. I leave the Display in Nvidia colour 8-bit RGB Full for everything else. Enabling the Microsoft colours sets either RGB limited or 422 you can't really see the setting but either way it looks crap for general PC usage.

Are you using 382.19? For me this is no longer the case on this driver.

No I am still using 382.05 as the Prey hotfix didn't apply to me. What changed with HDR?

Asmodian
21st May 2017, 22:22
If it is simply that you have full range input then the source needs to say it is full range. If it doesn't you can use Crtl-Alt-Shift-I to toggle through the input levels, PC is full range where 255 is mapped to 100% instead of 235. With limited range content you cannot map 236-255 to in-gamut colors; they are, by definition, out of gamut.

Sorry, I am confused as to what you want and why you are looking at this test image. :o

Please continue to ask calibration questions in the Display Calibration thread (https://forum.doom9.org/showthread.php?t=172783) so we don't clog up madshi's thread with calibration.

igvk
21st May 2017, 22:43
If it is simply that you have full range input then the source needs to say it is full range. If it doesn't you can use Crtl-Alt-Shift-I to toggle through the input levels, PC is full range where 255 is mapped to 100% instead of 235. With limited range content you cannot map 236-255 to in-gamut colors; they are, by definition, out of gamut

Ok, possibly the source is wrong and it is full range, but not providing this.
Strange that in this case madVR doesn't clip these values, and it leads to wrong colors.
Seems that I need to manually switch this source encoding for each video in this case.

Sorry, I am confused as to what you want and why you are looking at this test image. :o

This is a screenshot from video, not an image actually. There are many examples of such wrong colors in several videos.


Please continue to ask calibration questions in the Display Calibration thread (https://forum.doom9.org/showthread.php?t=172783) so we don't clog up madshi's thread with calibration.

Didn't think that it was display calibration related question, just what madVR does with 3dlut mappings.
But ok, possibly it's bordering with calibration much.

P.S. Forgot to ask: does madVR support 3D LUT for full range content?
Because there is no way to select input or output encoding "RGB 0-255" when creating 3dlut for madVR.

Damien147
21st May 2017, 22:49
Questions:


3) If HDR switch does NOT work for you: Which GPU are you using? Does the OS show the "HDR and Advanced color" switch to you? Have you tried with the switch on and off? Does your display switch into HDR with the switch on or off? Or neither?


RX470.Yes,it shows the switch.I tried it on and off but it gets disabled all the time.The only time I've seen it enabled was with the installation of new drivers but it didn't last long.With previous madvr version I've seen it getting enabled at random times when opening a video(non hdr) but if I remember well it gets disabled when going fullscreen.Haven't tested a lot with v0.91.10 but the behavior seems like the past.Washed out image and hdr stays disabled.


Also did you change anything else?I think I found an occasion that I have dropped frames when in the past things seemed more stable.Not completely sure though.

hannes69
21st May 2017, 23:05
That sounds good. That's not the case for my Kaby Lake GPU, though. Maybe it's a driver issue, once more?

Seems like that, yes. Bad driver implementations and OS quirks like Creators Update may keep us all busy for the next decades:devil:
I recently made a clean OS install directly with Win 10 Creators Update included and didnīt have any major problems though like others reported... Some small things like a taskbar that didnīt like to disappear in FSE and things like that but nothing too critical.

BTW: Recently I had several use cases for 24.000 Hz. I often watch movies with Amazon Video and there are several with this frame rate (some months/years ago they were mainly 23.976fps, in the meantime the number of 24.000fps ones is growing). And of course I watch them with madVR (Kodi with MPC HC as external player). So the 23.976fps vs. 24.000fps topic has indeed some relevance (when using corresponding refresh rates and not smoothmotion of course).

kolak
21st May 2017, 23:42
If I have h265 files with HDR info in headers (added with --master-display option) will these be fully passed over HDMI?

mrcorbo
22nd May 2017, 00:25
Wow, that's weird. Totally different behaviour to what Sideeffect and oldpainlesskodi are reporting!

You're saying your display immediately switches into HDR mode when you flip the "use HDR and Advanced color" display settings switch on, even if no video is playing and no game is running?

Weird indeed! And that's correct, yes. And when the HDR switch is activated both madVR in windowed mode and the Win 10 Movies & TV app render the video correctly.

Strange. With these settings, how does fullscreen exclusive mode look?

With the HDR slider on or off videos in FSE look exactly the same and also look identical to what I get when I choose EVR as the renderer in MPC-HC.

Just to be sure I am being totally clear. In windowed mode with the Win 10 API HDR metadata is always being passed whether HDR mode is activated via the switch or not, but is only displayed correctly when the HDR switch is active. In FSE mode HDR metadata is never being passed regardless of the state of the HDR switch and, additionally, when FSE mode is activated it will take me out of HDR mode on my TV if it has been activated by the switch. As soon as I leave fullscreen, if HDR had been activated by the switch my TV will return to HDR mode and HDR metadata is passed again.

huhn
22nd May 2017, 00:37
P.S. Forgot to ask: does madVR support 3D LUT for full range content?
Because there is no way to select input or output encoding "RGB 0-255" when creating 3dlut for madVR.

it doesn't matter for the 3D LUT if the source is limited or full range.
it will always get a limited range signal as an input and outputs this in limited range.

changing the output/input encoding to something other than 16-235 will results in wrong colors.

if a file is full range but not flagged for full range it is broken!
and you should contact the creator to fix it because he made a huge mistake here.

igvk
22nd May 2017, 00:51
it doesn't matter for the 3D LUT if the source is limited or full range.
it will always get a limited range signal as an input and outputs this in limited range.

changing the output/input encoding to something other than 16-235 will results in wrong colors.

As far as I understand this, it's madVR feature, because it more tuned to movie playback, and these have limited range?

Won't it be better to just clip input BtB and WtW values to 16 and 235 respectively?

if a file is full range but not flagged for full range it is broken!
and you should contact the creator to fix it because he made a huge mistake here.

In my example it's video from Youtube, but I saw other video files with this problem.

huhn
22nd May 2017, 01:08
As far as I understand this, it's madVR feature, because it more tuned to movie playback, and these have limited range?

Won't it be better to just clip input BtB and WtW values to 16 and 235 respectively?

if this would be done it would be impossible to watch properly flagged full range content.

and i don't know why you think madVR more tuned for limited range. madVR is perfectly made for full range content
unlike other renderer that treat everything as limited range madVR is aware of full range videos and handles them correctly.

In my example it's video from Youtube, but I saw other video files with this problem.

that makes it easier to contact the creator. doesn't it?

igvk
22nd May 2017, 01:19
if this would be done it would be impossible to watch properly flagged full range content.

and i don't know why you think madVR more tuned for limited range. madVR is perfectly made for full range content
unlike other renderer that treat everything as limited range madVR is aware of full range videos and handles them correctly.


I mean - if the video is detected as limited range (even erroneously), why not clip WtW values?
And if it's full range - use range 0-255 and not clip.
The current implementation leaves colors of WtW wrong, and it has no sense to me.

As for contacting the author - is there a good and technical way to make sure that the video uses full range, even when tagged as limited?
Except for guessing looking at miscoloration?

huhn
22nd May 2017, 01:39
some videos have some informations in the WTWor BTB parts so no there is no easy technical way to check this.
i'm mean you have to check ALL frames in a video to be 100% sure.
it could even switch all the time.

maybe the creator wants it too look terrible clipped on top of it.

this video here is full range: https://www.youtube.com/watch?v=bzJDimvPW1Y but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.

are you even sure full range is the source of your issues?

i talked about BTB WTW handling of 3D LUT before and well it is still as it is: http://bugs.madshi.net/view.php?id=424

Oguignant
22nd May 2017, 02:04
I think I posted everything relevant in that post. I ran the tests on a i7-6700 at 4.7 GHz. Those are the individual times for NGU, not the total average rendering time. If you put an empty file called "ShowRenderSteps" in the madVR directory it will show you the rendering times for each filter individually in the OSD.

I just tried it. My times are similar to yours. NGU Sharp very high: 14.1 ms

oldpainlesskodi
22nd May 2017, 07:13
Re HDR....further digging...

With my GTX 1080 using driver 378.92, pass-through with nvidia api or win 10 api does nothing in dx 11 FSE. If using windowed dx11, nvidia api does nothing, but, if i select win10 api in non-fse dx11, it passes through the metadata, but does not switch the display into hdr mode.

Can anyone else confirm?

K

Update - tried the above on drivers past 378.92, and it doesn't work. From reading the nvidia forums, post this driver, nvidia handed over an important part of the render chain to the OS. So, to confirm, using nvidia driver 378.92, madvr set to hdr pass-through using win10 api and madvr set to non-fse dx11 passes through the metadata perfectly (no washed out colours and perfect blacks), but, the 8bit output is imposed, and the display doesnt switch to hdr mode (although it looks like hdr mode).

Madshi - hope this helps.

Update 2 -hmmmm. Even though madvr is in fullscreen window 8 bit mode, my receiver reports a 36bit (12x3) ouput with 10bit and 8bit 23.976 files (nv control panel set to 12bit for 23,24,25 and 30hz full range through the chain, apart from Lav set as untouched).

igvk
22nd May 2017, 09:04
some videos have some informations in the WTWor BTB parts so no there is no easy technical way to check this.
i'm mean you have to check ALL frames in a video to be 100% sure.
it could even switch all the time.

Provided there is a tool to check the color values of all the frames. Or should I convert every frame to image and check manually every pixel?

maybe the creator wants it too look terrible clipped on top of it.

The video looks ok when played without applying 3D LUT, just more saturated on the wide gamut monitor.
Also, there are no artifacts with 3D LUT when I switch input encoding to full range, it's just more washed out.

this video here is full range: https://www.youtube.com/watch?v=bzJDimvPW1Y but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.

are you even sure full range is the source of your issues?


That was actually a question from the very beginning.
And the best guess I could come to.

i talked about BTB WTW handling of 3D LUT before and well it is still as it is: http://bugs.madshi.net/view.php?id=424

ryrynz
22nd May 2017, 10:05
but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.


YT has a lot of PC content.. so it's all wrong? Why is it not fixed?

ph123uk
22nd May 2017, 10:59
Re HDR....further digging...

With my GTX 1080 using driver 378.92, pass-through with nvidia api or win 10 api does nothing in dx 11 FSE. If using windowed dx11, nvidia api does nothing, but, if i select win10 api in non-fse dx11, it passes through the metadata, but does not switch the display into hdr mode.

Can anyone else confirm?

K

Update - tried the above on drivers past 378.92, and it doesn't work. From reading the nvidia forums, post this driver, nvidia handed over an important part of the render chain to the OS. So, to confirm, using nvidia driver 378.92, madvr set to hdr pass-through using win10 api and madvr set to non-fse dx11 passes through the metadata perfectly (no washed out colours and perfect blacks), but, the 8bit output is imposed, and the display doesnt switch to hdr mode (although it looks like hdr mode).

Madshi - hope this helps.

Update 2 -hmmmm. Even though madvr is in fullscreen window 8 bit mode, my receiver reports a 36bit (12x3) ouput with 10bit and 8bit 23.976 files (nv control panel set to 12bit for 23,24,25 and 30hz.

I get exactly this.

In windowed mode using the windows 10 API I get HDR colours and representation, looks fantastic.

As soon as I double click for fullscreen I get washed out colours.

In either windowed or fullscreen it does not activate the "HDR" mode on my TV - but again, windowed mode looks correct!

So close!

ph123uk
22nd May 2017, 11:19
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.

Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.

very strange indeed haha!

https://youtu.be/adx8KVVBH5M

heiseikiseki
22nd May 2017, 11:25
Hey Madshi,
In previous build I have to limit the buffer and set to D3D9 mode, but In madVR v0.91.10 All Optimus Problem has gone here!!
Thanks a lot!!

huhn
22nd May 2017, 11:30
YT has a lot of PC content.. so it's all wrong? Why is it not fixed?

nothing wrong with PC content.
doing a proper RGB -> YCbCr conversation (to limited range 4:2:0) is not that hard and done by default by program like OSB.

@igvk

plz provide and sample and the 3D LUT i will have a closer look.

igvk
22nd May 2017, 11:57
@igvk

plz provide and sample and the 3D LUT i will have a closer look.

Here you are:
https://www.mediafire.com/folder/lnusmyaz3dlv6/madVR

Video sample in mkv format and rar-compressed 3dlut for madVR.

huhn
22nd May 2017, 12:33
EDIT: the clipping shader works perfectly i just had to untick "run custom video shaders in video levels instead of PC levels" and it works wonders on your 3D LUT fixing it completely. the ringing is fixed too.

shader:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return clamp(tex2D(s0, tex), 0.0, 1.0);
}

so this is the same out of gamut handling issue i reported before. nothing else.

worthless old post:this is >not< a video range problem.
the issue should be the 3D LUT in general and but...
my 3D LUT creates similar ringing and some banding artefacts.

kind of the same as issue 424: http://bugs.madshi.net/view.php?id=424
the clipping shader doesn't help here in this case. which is strange.
the ringing is there with both 3d lut mine and yours but yours goes crazy with saturated colors. could be the render intent not sure.

so here you go: http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms-153.html

i reported the ringing issue before. but well... nothing changed.

Ver Greeneyes
22nd May 2017, 12:42
I used to have problems with highly saturated colors too. Out of curiosity, are you creating the 3DLUTs using the flags "-eT -Et"? That makes it clip invalid input values. I was using "-et -Et" before that (note the lower case "t"), which doesn't do any clipping.

oldpainlesskodi
22nd May 2017, 12:59
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.

Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.

very strange indeed haha!

https://youtu.be/adx8KVVBH5M

AMD or Nvidia?

If you are using Nvidia, have you tried driver 378.92?

K

igvk
22nd May 2017, 13:28
EDIT: the clipping shader works perfectly i just had to untick "run custom video shaders in video levels instead of PC levels" and it works wonders on your 3D LUT fixing it completely. the ringing is fixed too.

shader:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return clamp(tex2D(s0, tex), 0.0, 1.0);
}

so this is the same out of gamut handling issue i reported before. nothing else.

worthless old post:

So, is it indeed the way madVR handles WtW values when using 3dlut?
And the video is really full range (but interpreted as limited)?

igvk
22nd May 2017, 13:38
I used to have problems with highly saturated colors too. Out of curiosity, are you creating the 3DLUTs using the flags "-eT -Et"? That makes it clip invalid input values. I was using "-et -Et" before that (note the lower case "t"), which doesn't do any clipping.

I tried both: "-eT" and "-et", the situation didn't change.
Actually, it was GUI frontend, the options are called "Input encoding: TV RGB 16-235" with and without "(clip WTW)".

ph123uk
22nd May 2017, 13:41
AMD or Nvidia?

If you are using Nvidia, have you tried driver 378.92?

K

Nvidia for me, using the latest 382.05, haven't tried 378.92 - will it make a difference? I'm not using the colour options in the NVidia control panel, I'm using "system controlled" option.

using the windows 10 API option.

huhn
22nd May 2017, 13:44
So, is it indeed the way madVR handles WtW values when using 3dlut?
And the video is really full range (but interpreted as limited)?
nope.

the 3D LUT can't handle out of gamut information properly.

out of gamut information can be easily be created by scaling (and you are "always" scaling chroma).

now you can argue if madVR should never ouput out of gamut information input a 3D LUT (there are good reasons NOT to clip out of gamut information BTW.). or you can argue the 3D LUT should properly clip them. even with WTW clip this is not the case at least the last time i tested it.

at the end nothing changed.
you can try -eT but as far as i know this doesn't fix it. atleast not the ringing.
input encoding TV range 16-235 (clip WTW) is -eT AFAIK i think maybe...

the first think you should do know is making sure that the clipping script is fixing your issue.

igvk
22nd May 2017, 14:08
the first think you should do know is making sure that the clipping script is fixing your issue.

Yes, the clipping script fixes the problem.

I understand that 3D LUT cannot handle the out-of-gamut values. Perhaps, they can be extrapolated? But maybe it's more work than needed.

As for the range of the original video - I couldn't understand your answer on whether it's limited or not.

mrcorbo
22nd May 2017, 14:10
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.

Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.

very strange indeed haha!

https://youtu.be/adx8KVVBH5M

So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?

Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.

ph123uk
22nd May 2017, 14:11
Ok, by selecting

Convert HDR to SDR using pixel shader math

instead of passthrough

Seems to keep the HDR colours.

It still doesn't trigger the HDR flag on the TV but the colours certiainly look correct.

ph123uk
22nd May 2017, 14:22
So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?

Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.

Certainly seems that way, as I just put, if you click convert hdr to sdr using pixel shader maths, instead of passthrogh it keeps the HDR colour.

huhn
22nd May 2017, 14:24
I understand that 3D LUT cannot handle the out-of-gamut values. Perhaps, they can be extrapolated? But maybe it's more work than needed.
it could be clipped.
there are for sure mathematical ways to ignore 0-16 and 236-255 or they could be mapped to 16/235.

of cause i have no clue how much work that is.
[qoute]As for the range of the original video - I couldn't understand your answer on whether it's limited or not.[/QUOTE]

should be limited(a normal video). it is not worth to check it with a histogram and the issue has nothing to do with the range anyway.

igvk
22nd May 2017, 14:40
should be limited(a normal video). it is not worth to check it with a histogram and the issue has nothing to do with the range anyway.

If it's limited and still produces values that are out of range 16-235, then I think the problem should be fixed.
For now, thank you very much for the shader script!

But really, I would prefer this built in - because the way it works now leads to highly oversaturated colors on wide gamut monitor.
Instead of clipping, it would be better to have information on these out of gamut values in 3dlut, or extrapolate them - if it's possible.
But not keep the original values - they are plain wrong, as far as I see.

imhh11
22nd May 2017, 15:26
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.

Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.

very strange indeed haha!

https://youtu.be/adx8KVVBH5M

Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.
And I'm experiencing the exact opposite of you, but i'm setting the hdr slidder to ON... i dont know why you dont.
Windowed give me black screen
FSE give me proper playback
https://s17.postimg.org/amanj78bz/2017-05-22_10.23.04.jpg

moving my mouse to the search bar give me this
https://s12.postimg.org/u476s5qbx/2017-05-22_10.23.28.jpg

XMonarchY
22nd May 2017, 15:45
Just FYI, I could not solve my madVR Creator's Update problem with madVR no matter how I tried, even with the latest version - 23.976Hz refresh rate still produced problems. The latest LTSB version of the OS or just updated Anniversary Edition of - a whole different story (in a good way!).

Sideeffect
22nd May 2017, 17:39
@madshi
I reinstalled display drivers and MadVR and now I am getting behavour like mrcorbo.

The send HDR metadata has an effect as in showing what looks like HDR colors using Windows 10 API but it doesn't toggle HDR mode for my display.

I still need to enable HDR and advanced color in order for the display to go into HDR mode.

The send metadata does seem to work in both Nvidia or default colour settings when in windowed mode but colours become washed out when I enter FSE mode.

If default color settings and the HDR and advanced color is enabled then it works in FSE mode.

ph123uk
22nd May 2017, 17:43
Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.
And I'm experiencing the exact opposite of you, but i'm setting the hdr slidder to ON... i dont know why you dont.
Windowed give me black screen
FSE give me proper playback
https://s17.postimg.org/amanj78bz/2017-05-22_10.23.04.jpg

moving my mouse to the search bar give me this
https://s12.postimg.org/u476s5qbx/2017-05-22_10.23.28.jpg


When I click the HDR slider in windows it messes with the colour and makes it almost fluorescent, it does indeed play correctly as you state, but I don't want to have to go and click the slider everytime I want to watch a HDR movie and turn it off when it's finished.

Using the "convert hdr to sdr using pixel math" works flawlessly for me now, it is however not triggering the HDR "mode" on my TV, but the colours are spot on the same as when I plug an external hdd into my TV and play from there.

Will do for now :)

imhh11
22nd May 2017, 18:15
When I click the HDR slider in windows it messes with the colour and makes it almost fluorescent, it does indeed play correctly as you state, but I don't want to have to go and click the slider everytime I want to watch a HDR movie and turn it off when it's finished.

Using the "convert hdr to sdr using pixel math" works flawlessly for me now, it is however not triggering the HDR "mode" on my TV, but the colours are spot on the same as when I plug an external hdd into my TV and play from there.

Will do for now :)

for me there is black crush using '' convert hdr to sdr using pixel math ''.
picture look a lot better on real hdr passthrough even if i have to manually activate the OS slider.

mitchmalibu
22nd May 2017, 20:57
@madshi
Here are my findings. Interesting thing : the HDR switching behaviour differs if I use a 32 or 64bit player using the Nvidia API (still using reclock ...).

Setup :
LG 2016 OLED
GTX 1070
Nvidia drivers : 382.05
MPC-BE : 1.5.1 (build 2548) (32 and 64bit)
LAV Filters : 0.69
madVR : 0.91.10

The OK / KO results reflects the state of the ouput in fullscreen mode.

32 bit mpc

Nvidia HDR API fullscreen exclusive d3d9 : KO (switch out from hdr when I go fullscreen)
Nvidia HDR API fullscreen exclusive d3d11 : KO (switch out from hdr when I go fullscreen)
Nvidia HDR API windowed d3d9 : OK (TV switches to HDR, output looks ok)
Nvidia HDR API windowed d3d11 : OK (TV switches to HDR, output looks ok)
Windows 10 HDR API fullscreen exclusive d3d11 : OK but have to manually switch to HDR in the display settings
Windows 10 HDR API windowed d3d11 : KO (black screen when I switch to fullscreen)


64 bit mpc

Nvidia HDR API fullscreen exclusive d3d9 : KO (TV never switches to HDR)
Nvidia HDR API fullscreen exclusive d3d11 : KO (TV never switches to HDR)
Nvidia HDR API windowed d3d9 : KO (TV never switches to HDR)
Nvidia HDR API windowed d3d11 : KO (TV never switches to HDR)
Windows 10 HDR API fullscreen exclusive d3d11 : OK but have to manually switch to HDR in the display settings
Windows 10 HDR API windowed d3d11 : KO (black screen when I switch to fullscreen)


Hope this helps !

@imhh11
I see that you're using the Sony 4K HDR demo. Any luck decoding those efficiently on your system ? Mine struggles and can't keep up with the framerate (GPU and CPU decoding alike).

mrcorbo
23rd May 2017, 01:47
So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?

Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.

Still crashes on 382.05. And for me, choosing system-managed vs. Nvidia color settings has no effect on FSE being able to put or keep my TV in HDR mode or on HDR metadata being transferred in FSE mode.

mrcorbo
23rd May 2017, 01:55
Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.

ph123uk has FSE disabled, so is never in FSE mode during any part of that video. Didn't say if they're using windowed overlay or not.

baii
23rd May 2017, 03:50
GTX 1060 via nvidia api hdr passthrough work on .9. I just open up hdr video(windowed player) and tv go into hdr mode. didnt test windows 10 api.

Samsung TV set up for 444RGB to work as monitor daily.

I believe the creator update was not installed.

70MM
23rd May 2017, 10:48
Can someone help me set this up please...
I have all my ripped BDs set to play back at 4K upscaling via JR and madvr using the 1080Ti card.
As I have only a handful of BDs that are 50Hz and DVDs that are 50 and 60, when they switch across at 4K they drop frames etc etc...
As most of my 900 ripped BDs are 23.97 I have my settings fairy high on madvr since I have the 1080Ti card...
Can I make just the ripped DVDs and BDs that are 50Hz just playback in 1080P rather than 4K so the madvr settings can remain high?

Many thanks...

ph123uk
23rd May 2017, 10:59
ph123uk has FSE disabled, so is never in FSE mode during any part of that video. Didn't say if they're using windowed overlay or not.

Yea, apologies, I'm NOT using windowed overlay, this is my basic renderer settings.

Have MADVR setup to switch to the native Hz at 2160p upscaling, but that's about it (and NGU AA med / High dependant on source)