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

chros
17th April 2016, 11:43
When I watch a 24.000 fps movie with "use Direct3D 11 for presentation" enabled render queue and present queue are not full. Present time is unusually high too

With "use Direct3D 11 for presentation" disabled stats is ok.
Does it only happen to 24fps? Have you tried e.g. 23.976 and 25fps as well?
If 23.976 works fine but not 25 that probably means that your system isn't fast enough for those bigger fps and 10bit.
Can I set a profile auto select rules for 24 fps movies?
Yes, you can create a profile group with the "rendering" group entry and set something similar for rules:
if (srcFps < 24) "23fps"
else "Default"

huhn
17th April 2016, 11:48
I have a question regarding the SMPTE 170M primaries management in Madvr.

I have many japanese DVD and from my understanding, japan video industry still used SMPTE 170M primaries for DVD authoring instead of the more recent SMPTE C. If I'm not wrong, Madvr is able to manage SMPTE 170M Primaries if the filename is flagged so.

My issue is that, as I used my DVD and not rip (I have too many), I can't used the flag and so Madvr used SMPTE C primaries automatically. And using the primaries toggle option, SMPTE 170M is not listed as it should be very rare. Is a way to use SMPTE 170M primaries with my dvd without to rip them all (yes, I'm a very old fashioned man, I don't even rip my blu-ray)?

Thank in advance for your help!


when i open a DVD using "open disc" in mpc-hc madVR get's the primaries from the stream.

Matching_Mole
17th April 2016, 12:48
when i open a DVD using "open disc" in mpc-hc madVR get's the primaries from the stream.

Madvr don't get all the time this information from the stream, this is why you have "(best guess)" indicated in the statistic screen. Otherwise this is "(says upstream)" that is indicated. Each time I watch my DVD, I look the statistic screen to monitor the parameters used by Madvr.

Madvr guesses based on the resolution of the video and the framerate. In this case, this is NTSC video so it uses the best primaries for it so SMPTE C. But, in this specific cases, it seems to be wrong. This is why I want to change the primaries.

cvrkuth
17th April 2016, 13:07
Does it only happen to 24fps? Have you tried e.g. 23.976 and 25fps as well?
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth

Thanks for your help!

Clammerz
17th April 2016, 16:05
Is a way to use SMPTE 170M primaries with my dvd without to rip them all?

If you want to get turbo ghetto, you could mount your optical drive to a folder that has "primaries=XXXYYY" tag in it.

See here for more information about mount points:
https://technet.microsoft.com/en-us/library/cc753321.aspx

For some info about filename tags see here:
http://forum.doom9.org/showthread.php?p=1709584
(Search [CTRL+F] for "File name tags")

Create an empty folder path like:
S:\Movies\DVDDrive\Japan[primaries=170M]\

Then create the mount point as in the above microsoft article.
You could create multiple folders with different "dvd drive tags" I imagine.

Note: haven't tested any of this, so good luck.

chros
17th April 2016, 18:09
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth
That's pretty interesting! I don't have problem with 23/24/25fps but all the others! I thought it's because of increased bandwidth. I'll try to make some more tests with different materials.
(I have to mention that the GT650m is underclocked :) )

Matching_Mole
17th April 2016, 19:09
If you want to get turbo ghetto, you could mount your optical drive to a folder that has "primaries=XXXYYY" tag in it.


Thanks for the tips but unfortunately it doesn't work for DVD (and I think Blu-ray too), I just tried. I mean, it works if I choose the VOB files directly. But if I used the open DVD feature of MPC, this is the IFO that is selected and, due to the DVD navigator filter I assume, the solution failed.

wolfman2791
17th April 2016, 23:07
reproduced.

lanczos is used or at least shown in the OSD when the image is only scaled in X or Y direction.

jinc is correctly used with a 1440x1080p 16/9 AR source displayed at 1920x1080p.
there is an additional "image y = jinc" line.

you have set your player to stretch. set it to "touch window from the inside" (name can depend on the player) if you don't want that.
Thanks my man.

huhn
17th April 2016, 23:38
Thanks for the tips but unfortunately it doesn't work for DVD (and I think Blu-ray too), I just tried. I mean, it works if I choose the VOB files directly. But if I used the open DVD feature of MPC, this is the IFO that is selected and, due to the DVD navigator filter I assume, the solution failed.

which windows version are you using?

if you are not using windows 10 i could try a sample that doesn't work for you to see if it could at least work with a newer version of DVD navigator.

baii
18th April 2016, 13:18
Madvr don't get all the time this information from the stream, this is why you have "(best guess)" indicated in the statistic screen. Otherwise this is "(says upstream)" that is indicated. Each time I watch my DVD, I look the statistic screen to monitor the parameters used by Madvr.

Madvr guesses based on the resolution of the video and the framerate. In this case, this is NTSC video so it uses the best primaries for it so SMPTE C. But, in this specific cases, it seems to be wrong. This is why I want to change the primaries.
Google seems to say smpte c and smpte 170m have the same color space, what exactly is the difference?

OK, Google actually able to pull up madshi response on this
http://forum.doom9.org/showthread.php?p=1722345#post1722345

They are the "same".


Sent from my 306SH using Tapatalk

James Freeman
18th April 2016, 17:29
@madshi about HDR to SDR algorithm.

I noticed that the HDR to SDR algorithm in madVR saturates the color way beyond normal, I'll explain.
A standard 709 image converted to BT.2020 ST.2084 (ICC profile made by ArgyllCMS) exported as AVI and encoded with HEVC (primaries and matrix 2020, ST.2084 EOTF, P3 master display, 10,000 peak).

When playing back this video in madVR the image should look identical to the original 709 image right?
The resulting image in madVR is dark and more saturated compared to simply reversing the 2020 st.2084 icc profile (back to linear).
That lets me believe that something is wrong.

In this ZIP file you'll find all the steps from the 709 image to the HEVC HDR video file and explanation in Read.txt file.
http://www.mediafire.com/download/jpkvqnbqcj1682z/HEVC_HDR_test_to_madshi.7z

Martian SDR.jpg
Martian 2020 2084 (converted and profiled).jpg
Before HEVC.avi
HEVC 10,000.mp4
Rec2020 ST.2084.icc
Read.txt


Please have a look at this because no matter what I can't make the image look like the original after madVR HDR to SDR algorithm.
By the look of it there is another not needed gamma curve after the video is converted back to linear.
Madshi if you will please include a 2084 curve in the "this display is calibrated to the following EOTF" dropdown box for easy testing.

nevcairiel
18th April 2016, 17:47
When playing back this video in madVR the image should look identical to the original 709 image right?
The resulting image in madVR is dark and more saturated compared to simply reversing the 2020 st.2084 icc profile.


I think you are greatly oversimplifying this process.

Compressing HDR to SDR is not a lossless process, since the gamut and brightness range needs to be greatly compressed. The only problem here is that you can't just compress the range linear since that would make everything extremely dark. HDR doesn't use the full range for the full image, the majority of the image is still in "normal" brightness areas, only using the higher brightness for highlights etc.

So depending on which display nits you selected, you get a different image. Try adjusting the nits setting in madVR, and you should probably manage to get closer to the "original".

My guess is that your conversion over-satured the colors. It may not be this obvious on a HDR screen though, but its not how any real HDR footage would look.
Anyway, I still maintain that such a test is flawed. Your original images are not HDR, so using them for any kind of HDR tests seems not very productive.

Edit:
On a second look, it seems like your files are not actually BT.2020, but just normal BT.709 flagged as BT.2020. Disable primaries/gamut conversion in madVR by setting it to "disaplay is calibrated to BT.2020", and it suddenly looks perfect on a BT.709 screen.
Did you just convert the gamma curve before encoding, but not the gamut?

James Freeman
18th April 2016, 17:58
I well aware of the process by now and would not bother madshi in vain.
The HEVC video is encoded with 10,000nit (peak white 1024 10bit) so madVR I assume should not do any range conversion when 10,000 is selected, just reverse the ST.2084 EOTF back to linear.
Actually after a simple photoshop check, madVR runs another un-needed Gamma curve after linearization from 2084 to linear.

EDIT answer your edit:
The SDR image file is converted to 2020 ST.2084, so it IS in rec.2020 and ST.2084 eotf, so Gamma and Gamut.
No, the "disaplay is calibrated to BT.2020" does not correct the colors, it's the (un-needed IMO) gamma curve that makes the image more saturated and dark.
You have all the files to play with and compare.

Maybe that is part of madshi's algorithm, it applies a slight gamma curve and saturates the colors slightly more.
That is why I request (yes I know) for an ST.2084 EOTF curve for the display so that madVR does not do another process besides the linearization with st,2084 videos.
When vieweing the 2020 st.2084 profiled image in MPC-HC+madVR it uses the embedded profile and it looks just like the unprocessed image as it should.
Madhsi, what is going on in there with you HDR to SDR algorithm, can you enlighten us please?

Anyway, I still maintain that such a test is flawed. Your original images are not HDR, so using them for any kind of HDR tests seems not very productive.
Even when I use a real HDR screenshot (HERE) (http://www.blu-ray.com/movies/screenshot.php?movieid=147430&position=6) from blu-ray.com where I don't need to convert to 2020 st.2084 with an ICC because it is already in 2020 st2084, madVR makes it look more saturated with a slight power curve applied to it.

Maybe madshi tried to emulate the HDR look on SDR screen by raising the gamma slightly that I understand, but why the more saturated colors?
709 colors should look like 709 if they are in P3 or 2020 container.

XMonarchY
18th April 2016, 18:20
Are saying that Plasma TV's can produce HDR effect fully???

Bump!

Patrik G
18th April 2016, 18:47
Bump!

only the Pioneer 9G Kuros have a wider gamut that covers 89% of DCI P3 (calculated with dispcal 3d lut program after profiling)
the Panasonics are just slight over srgb gamut.
HDR is not all about brightness
it also needs those extra colors to get the image right.

This 500M has also less agressive ABL dimming than the rest of the plasmas.
it can maintain a higher brightness level even on high apl scenes.
thats also a key point to get the image and gamma right.

HDR Photo with 22 stops of dynamic range from the Exodus HDR clip with madvr on my 500M
i have compared it to the regular blu ray verison and the HDR version has higher depth and greater colors.
you can see more details near black and near white.

lets hope there will be more HDR material because this tv/monitor is made for it.
its hard to believe that an 8 year old monitor can handle todays standards i know lol

thanks to madvrs HDR support that made it possible to squeeze out the last % of picture quality on this haunted tv ;)

http://privat.bahnhof.se/wb192876/KRP%20500M%20Exodus%20HDR_lowres.jpg

Full size
http://privat.bahnhof.se/wb192876/KRP%20500M%20Exodus%20HDR.jpg

nevcairiel
18th April 2016, 19:06
The SDR image file is converted to 2020 ST.2084, so it IS in rec.2020 and ST.2084 eotf, so Gamma and Gamut.
No, the "disaplay is calibrated to BT.2020" does not correct the colors, it's the (un-needed IMO) gamma curve that makes the image more saturated and dark.

Then why does it look fine when I force madVR to assume the file is BT.709 input (via shortcuts, ctrl-alt-shift-P i believe), and set HDR nits to ~3000 or so (to get the brightness down)?
Neither one of those settings individually fixes it, but only the combination. Which makes me strongly believe that at least one of those aspects is not correct in your file.

Looks to me like something is fishy with your conversion. Your conversion has way too many manual steps to really trust it. How did you export it to AVI? Maybe your export converted it again.

James Freeman
18th April 2016, 19:14
Then why does it look fine when I force madVR to assume the file is BT.709 input (via shortcuts, ctrl-alt-shift-P i believe), and set HDR nits to ~3000 or so (to get the brightness down)?
Neither one of those settings individually fixes it, but only the combination. Which makes me strongly believe that at least one of those aspects is not correct in your file.

Looks to me like something is fishy with your conversion. Your conversion has way too many manual steps to really trust it. How did you export it to AVI? Maybe your export converted it again.

VirtualDub exports a set of images to lossless avi in 4:2:0, it looks absolutely identical to the 2020 st.2084 image.
I assure you it is not in the 2020 conversion or the avi.
It may be the HEVC encoding, here are the lines:
avs4x26x.exe -L "x265.exe" --seek-mode safe --input-depth 8 --preset slow --subme 7 --crf 0 --profile main10 --level-idc 5.1 --no-high-tier --b-adapt 0 --bframes 0 --keyint 1 --min-keyint 1 --no-open-gop --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" "E:\x265\Script.avs"

muxer -i output.hevc?[fps=1/4] -o output.mp4
del output.hevc


It's not the HEVC encoding, look EDIT.

It's the HDR to SDR algorithm in madVR that raises the gamma, and saturation ever so slightly.
It is not equal to just looking at the 2020 st.2084 image in mpc-HC+madVR, which just applies the profile inside the image.

I can understand the raised gamma to recreate an HDR look on SDR screen, but why more saturated? 709 should look like 709.

EDIT:
You can see that applying a gamma curve to the SDR image is look like the HEVC 10,000 video.
So it's a simple RGB curves manipulation to simulate HDR on SDR after linearization, which obviously affect saturation.
Yet the right image is ever so slightly more saturated.
http://www.mediafire.com/convkey/981a/2l023nzubbtlksqzg.jpg

chros
18th April 2016, 20:17
23.976 (and all others fps) works fine. Only 24fps is a problem with 10bit display bitdepth
That's pretty interesting! I don't have problem with 23/24/25fps but all the others! I thought it's because of increased bandwidth. I'll try to make some more tests with different materials.
(I have to mention that the GT650m is underclocked :) )
It's definitely a performance problem in my case (no wonder why :)). Can it be that the refresh rate of your display is under 24fps? Is this true for the other modes as well?

James Freeman
18th April 2016, 21:50
I have run several tests with a simple color steps pattern converted to HDR 1000 and 10,000 in full 2020 gamut, and 709 inside 2020.

Apparently madVR algorithm is much more complex with range conversions much smarter than I am.
It looks like it is not a simple curve as I assumed, it is dynamic gamut and average picture level dependent.
Madshi, can you just explain how it works, I will be grateful.

I think you are greatly oversimplifying this process.
You were right from the start, shame on me. :o

Sp00kyFox
19th April 2016, 01:33
I was wondering, is the ssim downscaling algorithm also available as an avisynth filter? madVR is the only place I came across it.

cvrkuth
19th April 2016, 11:40
It's definitely a performance problem in my case (no wonder why :)). Can it be that the refresh rate of your display is under 24fps? Is this true for the other modes as well?

Refresh rate is ok, probably a performance problem. I have AMD 5670 (passive cooled).

Thanks for your help with profiles, that was solve my problem with 24fps
Regards

Ver Greeneyes
19th April 2016, 12:13
I was wondering, is the ssim downscaling algorithm also available as an avisynth filter? madVR is the only place I came across it.I don't think so, though it might be possible using AviSynthShader (http://forum.doom9.org/showthread.php?t=172698) and the SSIM downscaler (https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/SSimDownscaler) code for Media Player .NET (though the code madVR uses might be slightly different, and it won't contain the anti-ringing filter).

As a personal note, I'd love to just be able to insert madVR into an Avisynth script :P madVR's DLL interface is too limited for that though, as far as I can tell.

DragonQ
19th April 2016, 19:26
Anyone know if AMD's Crimson 16.15 drivers fix deinterlacing? Still on Catalyst 15.30 since they broke it.

BluesFanUK
19th April 2016, 20:31
Is it essential to have LAV filters when installing MadVR?

sneaker_ger
19th April 2016, 20:33
Not in general but madVR's 3D mode with MVC decoding only works with LAV Video, I think.

RenderGuy2
19th April 2016, 20:58
Would it be possible for MadVR to support:

MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
MEDIASUBTYPE_XYZC {435A5958-0000-0010-8000-00AA00389B71}
FORMAT_VIDEOINFO2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}

This is a 12-bit XYZ format. There are a couple of relatively inexpensive DirectShow filters that can decode jpeg2000 pretty quickly and can output 12bit xyz (without forcing a conversion to rec709). The conversion to display color can easily be done by the user with either a 3DLUT or pixel shaders (linearize, 3x3 matrix, gamma), or a combination of both.

I have no idea if it is simple or difficult to add support for another pixel type. Thank you.

huhn
20th April 2016, 05:00
Anyone know if AMD's Crimson 16.15 drivers fix deinterlacing? Still on Catalyst 15.30 since they broke it.

i will test this later.

in one of the driver was a line like " fixed deinterlacing" or something like this.

RenderGuy2
20th April 2016, 17:23
Would it be possible for MadVR to support:
MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
MEDIASUBTYPE_XYZC {435A5958-0000-0010-8000-00AA00389B71}
FORMAT_VIDEOINFO2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}


Regarding this format, the filter outputs 48 bits which are assigned as:

Bits 0-7 = "Red" LSB's
Bits 8-11 = Nothing
Bits 12-15= "Red" MSB's
Bits 16-23= "Green" LSB's
Bits 24-27= Nothing
Bits 28-31= "Green" MSB's
Bits 32-39= "Blue" LSB's
Bits 40-43= Nothing
Bits 44-47= "Blue" MSB's

Hopefully this is useful.

Thanks!

huhn
20th April 2016, 17:23
i don't saw an issue on an short test.

nevcairiel
20th April 2016, 17:39
Regarding this format, the filter outputs 48 bits which are assigned as:

Bits 0-7 = "Red" LSB's
Bits 8-11 = Nothing
Bits 12-15= "Red" MSB's
Bits 16-23= "Green" LSB's
Bits 24-27= Nothing
Bits 28-31= "Green" MSB's
Bits 32-39= "Blue" LSB's
Bits 40-43= Nothing
Bits 44-47= "Blue" MSB's


So, ordinary Little-Endian format? =p

RenderGuy2
20th April 2016, 18:56
So, ordinary Little-Endian format? =p

Yeah, the only thing that confuses me is that I sometimes see Little-Endian as (first 16 of 48 bits):

Bits 0-3 = "Red" LSB's
Bits 4-7 = Nothing
Bits 8-15 = "Red" MSB's

So the empty bits are in a different location, though this might not matter as the least significant bits/most significant bits are still in the same bytes overall?

nevcairiel
20th April 2016, 19:39
So the empty bits are in a different location, though this might not matter as the least significant bits/most significant bits are still in the same bytes overall?

Some formats have the zero bits in the MSBs, some in the LSBs, its always just a matter of how the format is defined.

RyuzakiL
21st April 2016, 01:33
So the latest AMD Crimson (April 2016) still runs like crap on MadVR? I'm still using the last AMD Catalyst, is there an improvement 4 months after or I better wait again, or switch to NVIDIA now since it seems MadVR runs properly with NVIDIA cards.

Warlock
21st April 2016, 02:17
Guys, I'm having problems with excessive presentation glitches and dropped frames. In Windows 8.1 and Windows 10 does not appear this problem of presentation glitches or dropped frames, but in windows 7 ultimate x64 sp1 is happening. A picture of the problem:

http://i.imgur.com/Bcsuj8Y.png

My pc configuration is this:

4770k
Z87-GD65 gaming
8gb 1600
hd 1tb SATA3

I am using the onboard video 4770k, the Intel HD 4600.

What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.

huhn
21st April 2016, 07:41
the screen is most likely taken while playback is paused.
and i don't see any issue on the screen there are 12 dropped frames and 8 glitches and that's totally ok after going into fullscreen.

do these numbers change?
how many displays are connected to the PC?

SweetLow
21st April 2016, 09:14
What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.
As you use Intel and DX9 render - try using overlay.

Warlock
21st April 2016, 12:44
the screen is most likely taken while playback is paused.
and i don't see any issue on the screen there are 12 dropped frames and 8 glitches and that's totally ok after going into fullscreen.

do these numbers change?
how many displays are connected to the PC?

Actually, this image was when the video is paused, but even running, the flow of presentation glitches increases considerably. Increased presentation glitches, dropped frames, delayed frames rely heavily on the video type that I am running. Some have far fewer glitches than others, as well as delayed and dropped frames. It no has a specific time limit to happen, sometimes happens 5 for 5sec, 15 for 15sec, 30 for 30sec, and so on. These numbers change much, the glitches come easy 60 ~ 70 and droped frames increase much more, coming to pass 90 in most cases. I have only one display connected to my computer.


As you use Intel and DX9 render - try using overlay.

I did what you recommended, information on the presentation glitches disappeared, in contrast, the number of delayed frames greatly increased, it increases every second continuously.


I do not know why this is happening. In Windows 8.1 worked perfect, had no problems with presentation glitches, much less dropped frames and problems with delayed frames was very rare. The settings that use the madVR are those that come standard, only changed the trade of quality for performance, where deselect all selected options. In the devices, I selected my monitor, in case a benq XL2420T. In properties, let the default options, with the exception of bitdepth display option, where selected 7 bit. How do you think I set the madVR? It has some special sets for those using Intel video card?

huhn
21st April 2016, 12:56
your settings are default so you are using full screen exclusive mode?

Warlock
21st April 2016, 13:13
your settings are default so you are using full screen exclusive mode?

No, I use the windowed mode. I forgot to warn that deactivated the full screen exclusive mode option.

huhn
21st April 2016, 13:17
can you give FSE mode a try?

what type of decoding is used?

how do the queues look like are some acting "strange"?

Warlock
21st April 2016, 13:45
can you give FSE mode a try?

what type of decoding is used?

how do the queues look like are some acting "strange"?

Open Video in fullscreen exclusive mode, still having presentation glitches and dropped frames, but are much less than in windowed mode. In fact, it seems to be much more stable in exclusive mode in full screen. The decoding you refer to are the options lav filters? If so, use the dxva-cb mode. The queues are normal. They are functioning normally. I'll add an image running in fullscreen exclusive mode.

http://i.imgur.com/jdUiQYd.jpg
http://i.imgur.com/VPP4nDW.jpg

SweetLow
21st April 2016, 15:03
Try lower GPU queue to 6 and present frame in advance to 4

James Freeman
21st April 2016, 15:21
Fellows would you care to test these, both are video this time: :)
Both peak at 1000nit with the average picture levels like all current HDR 4K blu-ray releases.

Martian SDR to HDR Trailer.mp4 (http://www.mediafire.com/download/oeawrppgi3hzfv3/Martian+SDR+to+HDR+Trailer.mp4) (35MB)
4K Sun HDR Test.mp4 (http://www.mediafire.com/download/qp12w5fm5ng3tcm/4K+sun+HDR+test.mp4) (130 MB)

The second one is an actual 12bit HDR RAW footage before encoding, from a digital camera with all the F-Stops HDR needs.
surami shared this footage so I can experiment on it, on this thread: http://forum.doom9.org/showthread.php?t=172724&page=4

EDIT:
Martian trailer updated from 40s to full 2m:40s time.

QBhd
21st April 2016, 17:09
No, I use the windowed mode. I forgot to warn that deactivated the full screen exclusive mode option.

As you are using Windows 7... Have you tried disabling desktop composition. It never worked properly for me on Windows 7. FYI... Windows 8.1 and Windows 10 have no such issues

QB

Warner306
21st April 2016, 18:24
Open Video in fullscreen exclusive mode, still having presentation glitches and dropped frames, but are much less than in windowed mode. In fact, it seems to be much more stable in exclusive mode in full screen. The decoding you refer to are the options lav filters? If so, use the dxva-cb mode. The queues are normal. They are functioning normally. I'll add an image running in fullscreen exclusive mode.

http://i.imgur.com/jdUiQYd.jpg
http://i.imgur.com/VPP4nDW.jpg

Have you tried the D3D11 presentation path? Also, it might we wise to reset everything to its default from the madVR installation folder and start from scratch.

omarank
21st April 2016, 20:07
I was doing some testing on GPU LUTs and found that the “disable GPU gamma ramps” setting in madVR doesn’t perfectly make the ramps linear. I used this (https://www.xrite.com/i1display-2/support/d546) tester from X-Rite website and tested on three different systems with AMD, Nvidia and Intel GPUs respectively. All three systems didn’t have any ICC profile loaded or any other application loading the GPU LUTs. So they already had linear ramps. The tester software correctly reported that the LUTs were unmodified. When madVR was used with “disable GPU gamma ramps’ selected, it reported that the LUTs were modified. The tester software also shows some RGB values to describe the modification done to the LUTs. The RGB values shown in case of madVR were just slightly different from the values which it shows when the LUTs are linear. Apparently, this is a bug in madVR. This bug may not have any visual consequences because madVR makes the LUTs almost linear, but still it's a thing of concern as this will engage the GPU processing of LUTs adding an extra dithering noise to the video.

Stereodude
22nd April 2016, 01:24
I'm running a Nvidia GTX 650 under Windows 10 x64 with the 364.51 drivers driving a 2560x1440 display. With madVR 90.17 my chroma is always DXVA no matter what I set it to in madVR's settings. I tried MPEG-2, H.264, interlaced & progressive content. I've used madVR for years with AMD HW in my HTPC so I'm not a total n00b. It doesn't appear to be a OSD bug since the rendering time doesn't change when I change the chroma scaling mode. Am I missing something or is this a known bug?

Edit: I had LAV set to DXVA native... Changing it to something else mostly fixes that. However, if deinterlacing is enabled you automatically get DXVA chroma regardless of the decoder mode. Is that a Nvidia or Windows 10 thing? My AMD setup in my HTPC doesn't do that...

huhn
22nd April 2016, 01:37
I'm running a Nvidia GTX 650 under Windows 10 x64 with the 364.51 drivers driving a 2560x1440 display. With madVR 90.17 my chroma is always DXVA no matter what I set it to in madVR's settings. I tried MPEG-2, H.264, interlaced & progressive content. I've used madVR for years with AMD HW in my HTPC so I'm not a total n00b. It doesn't appear to be a OSD bug since the rendering time doesn't change when I change the chroma scaling mode. Am I missing something or is this a known bug?

Edit: I had LAV set to DXVA native... Changing it to something else mostly fixes that. However, if deinterlacing is enabled you automatically get DXVA chroma regardless of the decoder mode. Is that a Nvidia or Windows 10 thing? My AMD setup in my HTPC doesn't do that...

look at the trade quality for performance options.
your AMD setup would do the some. (2 and 3)

and don't forget nvidia DXVA native lowers PQ by a lot even without DXVA chroma scaling.

Sunspark
22nd April 2016, 04:32
Guys, I'm having problems with excessive presentation glitches and dropped frames. In Windows 8.1 and Windows 10 does not appear this problem of presentation glitches or dropped frames, but in windows 7 ultimate x64 sp1 is happening. A picture of the problem:

My pc configuration is this:

4770k
Z87-GD65 gaming
8gb 1600
hd 1tb SATA3

I am using the onboard video 4770k, the Intel HD 4600.

What changes should I do to stop this problem of excessive presentation glitches and dropped frames? In Windows 8.1 works perfectly, but in Windows 7 is taking place this problem. I appreciate if you guys can help me guys.

Hi, you will get dropped frames when you're switching in and out of modes. What you should do instead is monitor playback after resetting the counter. Ctrl-R resets counter values to 0. If you're not experiencing the issue after reset, then it is fine.

I have a Broadwell using the HD 6000 on Windows 7 running under the classic theme.

I use Intel Quicksync in LAV 0.68 though I used to use copyback.

Maybe check the video driver version you have.. I'm using 4279.

Stereodude
22nd April 2016, 13:18
look at the trade quality for performance options.
your AMD setup would do the some. (2 and 3)

and don't forget nvidia DXVA native lowers PQ by a lot even without DXVA chroma scaling.
Thanks for pointing me in the right direction. I don't remember those on my HTPC, but it's a few revisions behind and it's been a while since I set it up.