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

leeperry
12th July 2016, 07:17
I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening. (..)

Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)
AB100% is too high of a value IME and I rest my case that there is no such thing as "valid sharpening" to my eyes(especially with sxbr100 which is too sharp to me and so is SR3), for instance I prefer the "Nie" characters written on the left button of the guitar with AB than without. You also didn't mention whether picture was refined after every 2X upscale and what downscaler was used(I ran SSIM 2D 100%).

Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293

This is what AB does, it cleans edges for smoother movements. Either way there is no free lunch to be expected from upscaling, it's all about compromises and I find the AB75% compromise more than worth it as picture doesn't look harsh and oversharpened anymore.

ryrynz
12th July 2016, 07:51
T
The rest of the lettering, especially on the lower part of the guitar shows the same improvement and then degradation when anti-bloating is enabled.

Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)


Improvement? Anti-bloating is doing wonders here. The SuperRes only pic looks pretty nasty.


Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293


The difference there is so subtle I doubt anyone would notice it.. how large is that zoom? :D

burfadel
12th July 2016, 09:18
Maybe try using a lower SuperRes number instead :). The SuperRes by itself is oversharpened, with anti-bloating it's slightly blurred.

ryrynz
12th July 2016, 09:24
Maybe try using a lower SuperRes number instead :). The SuperRes by itself is oversharpened, with anti-bloating it's slightly blurred.

It's not blurred, it just doesn't have crazy amounts of haloing all over the place.

chros
12th July 2016, 11:27
What changes happened between 0.90.20 and 0.90.22 that would hurt performance? As I have said in the past, I like pushing my GPU to the max and my 720p24 profile is right on the edge (so much so that even a chroma superres of just 1 pushes it over the edge). When I tried 0.90.22 the first file I watched at 720p was actually 718 and I thought the performance hit was because of that... however later I watched one that was 720 and I could no longer maintain render queue. I rolled back to 0.90.20 and all is well again. Just curious what could have changed since I didn't see anything is the changelog for either 21 or 22. Something deeper under the hood?
Interesting, I haven't noticed anything like this on my really restricted system (though I haven't tried out all my profiles yet). I'll keep an eye on it and report back.

leeperry
12th July 2016, 12:30
The difference there is so subtle I doubt anyone would notice it.. how large is that zoom? :D

That was with SR1+AB25, difference is a lot more obvious with SR2+AB75. It's called a "proof of concept" :p

Sunset1982
12th July 2016, 13:43
what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?

s4nder
12th July 2016, 13:53
what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.

Shiandow
12th July 2016, 14:25
I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening.

[...]

Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)


Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.

Sunset1982
12th July 2016, 14:27
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.

chroma upscale or luma image doubling?

For chroma I yould suggest NNEDI32, and Luma image doubling at 64 neurons.

But I would like to know is, what settings the other guys here prefer when using NNEDI or superXBR. Are you using SR with both? Any other suggestions?

leeperry
12th July 2016, 15:57
I would like to know is, what settings the other guys here prefer when using NNEDI or superXBR. Are you using SR with both? Any other suggestions?

SR for both, reconstruction soft for chroma & sxbr75/jinc for luma + SSIM 2D 100%.

Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.

Ouh, touché!

Iznogūd
12th July 2016, 16:20
madshi,

What changes happened between 0.90.20 and 0.90.22 that would hurt performance? As I have said in the past, I like pushing my GPU to the max and my 720p24 profile is right on the edge (so much so that even a chroma superres of just 1 pushes it over the edge). When I tried 0.90.22 the first file I watched at 720p was actually 718 and I thought the performance hit was because of that... however later I watched one that was 720 and I could no longer maintain render queue. I rolled back to 0.90.20 and all is well again.


QB

I'm experiencing the same issues as well, running a GTX750ti against a 1440x900 display.

jerryleungwh
12th July 2016, 19:02
I'm trying to use the debug mode to find out what's preventing me from using D3D11 exclusive mode but I don't quite understand what the log says. These two lines seem significant though

00006286.019 Window blocking WM_NCACTIVATE
00006289.356 Render prevented Direct3D from setting display mode 0x0, 0 Hz, progressive


Could this be the problem and how can I fix it? If no what should I look for in the log for such problem?

whitestar999
12th July 2016, 19:12
Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293

This is what AB does, it cleans edges for smoother movements. Either way there is no free lunch to be expected from upscaling, it's all about compromises and I find the AB75% compromise more than worth it as picture doesn't look harsh and oversharpened anymore.
I have to admit I didn't saw any change in top-left corner but I did saw a black spot diminishing(on mouse over with AB25) & then enlarging on mouse out on bottom right corner of small egg like structure below the antenna/rod at the top of building structure.If only ppl make their voting choices in general elections as diligently.:D

burfadel
12th July 2016, 19:17
The adaptive sharpen shader has been updated, thought I'd mention it since it's used under the upscaling refinement and image enhancements options.

http://forum.doom9.org/showthread.php?t=172131

Changelog:
2016-07-10 - Replaced lerp used for under/overshoot compression with a weighted power mean, reduces some ringing.
- Corrected minor error in the custom smoothstep function.
- Slightly improved weighting for nmax & nmin.
- Tweaked some parameters.

Sunset1982
12th July 2016, 19:45
is there any difference in motion clarity when using NNEDI instead of SuperXBR?

aufkrawall
12th July 2016, 23:28
That's impossible, there can be no difference between scaling one frame seperated or many in a row with the same algorithm.
If you want best motion clarity, let madVR feed a display that supports black frame insertion with the correct refreshrate without smooth motion.

ryrynz
12th July 2016, 23:32
Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.

Looks good, a bit too much sharpness and aliasing but likely you were using a different luma upscaler. I never got the impression SuperRes really helped much at all and have never enabled it. Might actually look at it when this updated version makes it way into madVR.

pirlouy
12th July 2016, 23:38
That's impossible, there can be no difference between scaling one frame seperated or many in a row with the same algorithm.
Well it looks possible to me. I guess lesser quality images might allow a better motion clarity than well defined images.

Anima123
12th July 2016, 23:47
Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.

Was this version of SuperRes already available to public?

Shiandow
13th July 2016, 00:17
Was this version of SuperRes already available to public?

It should be the same as the one here (https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/SuperRes).

SpoCk0nd0pe
13th July 2016, 01:13
Hey Madshi,

I've got a rather special request:

Could you implement changing 3d formats, allowing a change from frame packed 3d to frame sequential 3d?

or

Could you implement support for frame sequential 3d input?

digitech
13th July 2016, 01:28
does anyone know if i use the nvidia edge enhancement option with "use nvidia setting" selected on control panel if madvr really apply this setting or just ignore it?

huhn
13th July 2016, 01:59
does anyone know if i use the nvidia edge enhancement option with "use nvidia setting" selected on control panel if madvr really apply this setting or just ignore it?

should be ignored except with DXVA processing. it may work with deinterlancing or DXVA scaling.

Ironclad
13th July 2016, 05:51
Having to copy the image in high-bit-depth from the GPU to system memory and back after processing will take a significant part of the performance, so don't expect too much free magic.

Oh so more so than the GPU needing to process an additional 36 or more frames per second, it's the lag caused by storing in system memory that's slowing everything down. I'm probably oversimplifying it but 640x480 frames->1440x1080 frames should increase the traffic through system memory by like 5 both ways compared to the current method.

Even if the GPU is doing 2.5-6 times as much work, that's not comparable to the difference in speed between RAM and VRAM.
https://en.wikipedia.org/wiki/List_of_device_bit_rates#Dynamic_random-access_memory

Oh of course that's why already high framerate videos are no issue! The only solution would be if the interpolation is done entirely by a GPU. I guess using DDR4 will help somewhat. I'll see what the SVP developers think but I'm guessing it would require completely rewriting the filter.

ShiftyFella
13th July 2016, 20:59
Looks like HDR processing in .22 is kinda broken or maybe it's just me? LG Chess and Sony Camp videos play absolutely fine with hdr processing turned on and picture looks like it should but this (http://demo-uhd3d.com/fiche.php?cat=uhd&id=115) Samsung demo and files from this (http://forum.doom9.org/showthread.php?p=1765307#post1765307) post look totally wrong. HDR processing option turned on produces color shifted image. Playing with any of the options doesn't help and only turning it off helps. Using .20 or older produced no such issues, I skipped .21 and updated straight to .22 from .20 tho


samsung hdr demo:
hdr processing turned on:
http://i.imgur.com/NNGRKOgl.jpg (http://i.imgur.com/NNGRKOg.jpg)

hdr processing off:
http://i.imgur.com/QQ84Tsil.jpg (http://i.imgur.com/QQ84Tsi.jpg)


sony camp:
hdr on:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)
hdr off:
http://i.imgur.com/ijQpbjrl.jpg (http://i.imgur.com/ijQpbjr.jpg)

pose
13th July 2016, 21:35
madshi, i was always curious as of what settings and scaling algorithms you prefer yourself. Can you tell me please? Also thank you for the madVR! My chinese cartoons look amazing! :thanks:

zoyd
13th July 2016, 23:02
Looks like HDR processing in .22 is kinda broken or maybe it's just me?

I'm not seeing any color shifting of that image here. Note that the text and image overlay is encoded with peak white at 255 (10,000 nits).

350 nit display (madVR set to 400 nits HDR on, preserve hue on)
https://dl.dropboxusercontent.com/u/2621383/20160713174711_HDMI1.jpg

mastrboy
13th July 2016, 23:15
Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)

ryrynz
13th July 2016, 23:40
HDR processing option turned on produces color shifted image.
sony camp:
hdr on:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)


I've watched this HDR test video quite a lot at work on HDR & non HDR TV's, and that's exactly how it looks.

leeperry
13th July 2016, 23:58
Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)

PotPlayer has fully skinnable GUI's and also a mode that doesn't break FSE :)

zoyd
14th July 2016, 00:37
I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:

hue preserve off
https://dl.dropboxusercontent.com/u/2621383/desat1.jpg

hue preserve on
https://dl.dropboxusercontent.com/u/2621383/desat2.jpg

CalMAN LUT
https://dl.dropboxusercontent.com/u/2621383/desat3.jpg

Without hue preserve the madVR image luminance is too low and appears oversaturated - with hue preserve you lose all of the amber light and a good portion of the red tent.

The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.

ryrynz
14th July 2016, 01:03
The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.

That's more than just mild desaturation, but yes the lights do look right to me but the rest if quite off. What are you basing you comparison on for things being accurate/not accurate?
I might be tempted to take a photo of one of the HD sets at work with this scene for comparison although it wouldn't be calibrated.

ShiftyFella
14th July 2016, 01:46
I'm not seeing any color shifting of that image here. Note that the text and image overlay is encoded with peak white at 255 (10,000 nits).

350 nit display (madVR set to 400 nits HDR on, preserve hue on)
https://dl.dropboxusercontent.com/u/2621383/20160713174711_HDMI1.jpg
After resetting my setting and nuking all of my profiles, I figured out the culprit. It was SuperRes turned on for chroma upscaling. When both SuperRes and HDR procesing turned on, it produces weird color shift and it changes depending on the SR level. Turning SR off brings picture back to normal, apparently i had SR on in some profiles but not in others, that's why it was only showing up with different files. I'm not sure what's going on or why it's doing this.

HDR on, SR off:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)

HDR on, SR@1:
http://i.imgur.com/my9I3Zvl.jpg (http://i.imgur.com/my9I3Zv.jpg)

HDR on, SR@4:
http://i.imgur.com/nSZwDBel.jpg (http://i.imgur.com/nSZwDBe.jpg)

HDR off, SR on
http://i.imgur.com/Cw0JOYSl.jpg (http://i.imgur.com/Cw0JOYS.jpg)

zoyd
14th July 2016, 01:55
That's more than just mild desaturation, but yes the lights do look right to me but the rest if quite off.

The point was that the CalMAN LUT generated image is significantly less desaturated than what madVR is doing with preserve hue.


What are you basing you comparison on for things being accurate/not accurate?

The display is calibrated via the LUT so what I am seeing is correct in an absolute sense for in-gamut colors. For the out-of-gamut colors there is no way to assess "correct" because each display needs a different compromise depending on it's peak luminance. All I can say is that the CalMAN LUT mapping of out-of-gamut colors for my display appears to do a better job with these red/orange highlights than the current madVR algorithm.

James Freeman
14th July 2016, 04:43
I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:
I have to agree, the CalMAN LUT preserve the color gradations more, while in madVR the colors turn to white very fast.

Moreover, when changing the "display calibrated to gamut" to BT.2020 in madVR it should preserve more of the color saturation gradations than BT.709 no?
It looks like it does not even on BT.2020.

StinDaWg
14th July 2016, 08:40
Can anyone else confirm these D3D11 bugs...

When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.

This also happens for all videos when the video is paused in D3D11 FSE and Windows screen saver comes on. Once you resume play all the queues drop and they never recover.

This does not happen in D3D11 windowed or D3D9 (either mode). It seems to be a D3D11 FSE only issue. Using AMD card/drivers and Win10.

I would like to use D3D11 FSE as it offers the best performance and 10 bit mode, but these issues make it kind of unusable for me.

wolfman2791
14th July 2016, 09:36
I'm having an issue: I get a OpenCL error on the x64 version of MPC-HC. Causes MPC-HC to crash. I don't get it on the x86 version. Is this a known issue?

I have a AMD R9 390 8GB GPU. So it can't be a memory issue.

zoyd
14th July 2016, 10:42
Moreover, when changing the "display calibrated to gamut" to BT.2020 in madVR it should preserve more of the color saturation gradations than BT.709 no?
It looks like it does not even on BT.2020.

No, BT.2020 just means wide gamut encoding. The colors in that clip do not exceed DCI/P3 gamut and the problem is with high luminance throwing these colors out-of-gamut, not high saturation.

ShiftyFella
14th July 2016, 11:16
Can anyone else confirm these D3D11 bugs...

When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.

This does not happen in D3D11 windowed or D3D9 (either mode). It seems to be a D3D11 FSE only issue. Using AMD card/drivers and Win10.

I would like to use D3D11 FSE as it offers the best performance and 10 bit mode, but these issues make it kind of unusable for me.
Do you use hdmi port for your tv\monitor? I can confirm this weird behavior occurs over hdmi but not over display port, everything is like it should there. I have 290x with latest crimson drivers(16.7.2) and win10(64bit). Personally I don't use FSE that much as I don't see any performance gain and it sometimes messes with my multi monitor setup

http://i.imgur.com/DE3ee4dl.jpg http://i.imgur.com/p85gYe7l.jpg http://i.imgur.com/gZRtwj3l.jpg

madshi
14th July 2016, 11:27
OK, here goes
Ok, thanks, will have a look at that when I find some time, maybe next weekend.

What changes happened between 0.90.20 and 0.90.22 that would hurt performance?
Three things:

1) Bilateral chroma upscaling is slower now (when using the new algo).
2) HDR handling is slower now.
3) Fixed a couple of bugs in deciding when image doubling and upscaling refinement becomes activated.

If you don't use Bilateral chroma upscaling, and if we're talking about SDR content, and you still get slower performance, then it might have to do with image doubling and/or upscaling refinement now maybe becoming active when it didn't before?

What does it mean if 1080p/720p MKV movies have present queue 0-2/3 in Windowed Mode but FSE it works fine.

Asus G751JT

Windows 8.1 x64 + Potplayer x64 + Lavfilters 0.61 + DXVA2 CopyBack or CUVID + 970M + 368.69 Drivers + Potplayer Profile set to Maximum Performance - 3 Pre-rendered frames - Gsync Disabled Fixed Refresh

How can I fix it ?
The render queue is the first queue in the list which is nearly empty, so that's the bottleneck. It seems that your GPU can't keep up. Might have to do with the high refresh rate (100Hz). You may have to lower your scaling settings. E.g. use 16 neurons instead of 32 for chroma upscaling.

what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.
madshi, i was always curious as of what settings and scaling algorithms you prefer yourself. Can you tell me please? Also thank you for the madVR! My chinese cartoons look amazing! :thanks:
For chroma upscaling I like super-xbr AR or Reconstruction Soft, which are both decent allround algorithms, which work fine for most content. The best quality can be achieved with Bilateral, though. However, although Bilateral looks best in most cases, sometimes it produces artifacts, so at this point I'm not confident recommending it as a general purpose allround algorithm yet.

For luma upscaling I like NNEDI3 + SuperRes. For downscaling I like SSIM1D 100 with some Anti-Bloating.

Just my personal opinion, though. YMMV.

Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Which settings did you use for your newest SuperRes for this image?

I just compared your latest SuperRes with mine again last weekend, but I'm still not convinced that your latest algo is an improvement over what I already have. The nice thing about yours is that it doesn't need an extra anti-ringing filter. However, depending on the settings, yours still has either aliasing artifacts, or looks somewhat "bloated", or is too soft for my taste.

Generally I don't like having 5 different options which all influence each other. Most users wouldn't have a clue which settings they should use. I'd like to have one algo with just a "strength" option which works decent for all sources. And from what I'm seeing, currently I still think my current implementation is a better allround solution with less bloated look, less aliasing problems and higher detail reconstruction. But I'm very willing to be convinced otherwise!

Which settings would you recommend to use with your new algorithm? Those settings should work well for all sources. I'll gladly retest to see if with those settings I now like yours better than mine.

Thanks!! :)

I'm trying to use the debug mode to find out what's preventing me from using D3D11 exclusive mode but I don't quite understand what the log says. These two lines seem significant though

00006286.019 Window blocking WM_NCACTIVATE
00006289.356 Render prevented Direct3D from setting display mode 0x0, 0 Hz, progressive


Could this be the problem and how can I fix it? If no what should I look for in the log for such problem?
The log is pretty hard to interpret. It's made for my eyes, so I'm not sure if you can find what you need. Those 2 lines you mentioned are "good", they should be there are don't indicate a problem.

If you upload the (zipped) log somewhere I can have a look if I can see something. Please activate the Ctrl+J OSD and keep it active while creating the log, then try to enter exclusive mode. Having the Ctrl+J OSD turned on is important because in this specific case it adds more information to the debug log.

The adaptive sharpen shader has been updated
K, thanks.

Could you implement changing 3d formats, allowing a change from frame packed 3d to frame sequential 3d?
My control over what the GPU outputs is very limited. I can either output frame packed 3D, or conventional 2D. I have no other options. When outputting conventional 2D, I can do some fancy pixel resorting, which allows me to render 3D for those line or column alternate displays (passive IPS LCDs). But I don't see how I could do frame sequential 3D. Neither Windows nor the GPU manufacturers offer any kind of API for that.

Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)
This is really what the media player should do. I do know that not all media players provide a nice exclusive mode GUI, though, which is the reason why I implemented the seekbar in the first place. Maybe at some point I'll add more GUI controls for media players that don't have their own in exclusive mode. But it's not a high priority atm.

I've watched this HDR test video quite a lot at work on HDR & non HDR TV's, and that's exactly how it looks.
FWIW, tone+gamut mapping on current HDR TVs is not really high quality, so I'm not sure if that should be used as a reference. I would really like madVR to be better than what HDR TVs do.

I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:

[..]

Without hue preserve the madVR image luminance is too low and appears oversaturated - with hue preserve you lose all of the amber light and a good portion of the red tent.

The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.
Agreed. I've talked to Graeme about this. He says priority in gamut mapping should be like this:

1) hue preserversion.
2) luminance preservation.
3) saturation preservation.

Which is *exactly* the priority sorting I use in madVR. However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.

So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.

After resetting my setting and nuking all of my profiles, I figured out the culprit. It was SuperRes turned on for chroma upscaling. When both SuperRes and HDR procesing turned on, it produces weird color shift and it changes depending on the SR level.
Ah, thanks! Will have a look at this ASAP.

Can anyone else confirm these D3D11 bugs...

When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.
This can happen with weird refresh rates, especially in 10bit mode, especially with AMD GPU drivers. I don't think I've seen this reported with NVidia drivers yet. One possible fix is to lower the number of prepresented frames to e.g. 4-6. This reportedly has helped for most users in the past. I believe it's a GPU driver issue, which is related to the mixture of using D3D11, weird refresh rates, a high number of prepresented frames, and maybe 10bit output.

I'm having an issue: I get a OpenCL error on the x64 version of MPC-HC. Causes MPC-HC to crash. I don't get it on the x86 version. Is this a known issue?

I have a AMD R9 390 8GB GPU. So it can't be a memory issue.
Probably a GPU driver issue. Have you tried different GPU driver versions?

Do you use hdmi port for your tv\monitor? I can confirm this weird behavior occurs over hdmi but not over display port, everything is like it should there. I have 290x with latest crimson drivers(16.7.2) and win10(64bit). Personally I don't use FSE that much as I don't see any performance gain and it sometimes messes with my multi monitor setup
That's quite interesting! I suppose the left most screenshot is HDMI while the other 2 are display port? So a good workaround would be to use a display port -> HDMI adapter to avoid the presentation queue from getting empty in FSE mode?

MariaX9
14th July 2016, 11:39
Is Luma Upscaling the Image Doubling setting?

chros
14th July 2016, 11:53
No, BT.2020 just means wide gamut encoding. The colors in that clip do not exceed DCI/P3 gamut and the problem is with high luminance throwing these colors out-of-gamut, not high saturation.
Thanks zoyd for the Calman screenshot, it looks the best indeed. So it's clear now (as e-t172 suggested as well) that it's an out of gamut problem.
Agreed. I've talked to Graeme about this. He says priority in gamut mapping should be like this:

1) hue preserversion.
2) luminance preservation.
3) saturation preservation.

Which is *exactly* the priority sorting I use in madVR. However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.

So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.
Amazing, thanks for all your work, madshi!

ShiftyFella
14th July 2016, 12:52
That's quite interesting! I suppose the left most screenshot is HDMI while the other 2 are display port?
No, only one on the right(last one) is display port. left is hdmi with fse, middle one is hdmi in windowed and on the right is display port with fse.

madshi
14th July 2016, 13:09
Is Luma Upscaling the Image Doubling setting?
Yes.

No, only one on the right(last one) is display port. left is hdmi with fse, middle one is hdmi in windowed and on the right is display port with fse.
Ok. To be fair, both the resolution and the refresh rate differs when comparing hdmi and display port in your screenshots. So I'm not sure if it's proof yet that display port doesn't have the issue.

zoyd
14th July 2016, 13:32
.

However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.

So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.


I have trouble visualizing why desaturation would be used to preserve hue in the first place. Assuming the hue angle is correct for a primary color, desaturation along that line increases luminance. And this is a good trade to make in moderation because the overly dark color "appears" too saturated although it really isn't, it's just too dark. That trade is usually evaluated by minimizing one of the modern dE formulas (CIE1994 or CIE2000).

madshi
14th July 2016, 13:42
So basically I'd be using something like dE to calculate the best compromise between saturation loss and luminance loss (while keeping the hue angle constant)?

colinhunt
14th July 2016, 13:42
Apologies for asking something I couldn't find but which has probably already been answered:

- Windows 7 64-bit
- Radeon RX 480 (HDCP 2.2 and HDMI 2.0 with support for HDR), connected via HDMI to an HDR 4K television.

I'm trying to play HDR 4K demo clips on MPC-HC which has been configured to use MadVR but the screen remains black. Audio plays, though.

Should MPC-HC + madVR pass 10-bit video with HDR metadata to the TV or not, i.e. should the TV recognize and display HDR video?

nevcairiel
14th July 2016, 13:47
Should MPC-HC + madVR pass 10-bit video with HDR metadata to the TV or not, i.e. should the TV recognize and display HDR video?

No, it should not. madVR can only convert HDR videos to SDR and display that.

colinhunt
14th July 2016, 13:55
No, it should not. madVR can only convert HDR videos to SDR and display that.
Thanks for the quick reply!