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

madshi
13th December 2012, 13:07
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
Thanks, will double check here. Could you upload a short debug log, nevertheless, just in case I can't reproduce it here?

Madshi, levels are now incorrect using 85.3 with dxva scaling and mpc-hc internal decoder and splitter. Blacks are now grey. Other scaling methods provide proper levels. I'm using the old path exclusive without overlay on an Amd card.
Which exact OS, GPU and driver version? Can you please also upload a short debug log?

I have accidently realized that there's a huge performance issue since v0.85.2 (v0.85.1 is OK) when I using post resize pixel shader (sharpen complex 2) in mpc-hc on my laptop (720p content upscaled to 1680*xxx).

test (using nvidia inspector):
- v0.85.1: MCU usage: 19%, GPU usage: 53%
- v0.85.3: MCU usage: 30%, GPU usage: 78% (!!!!)

If I disable post resize shaders in mpc-hc, everything is the same between the 2 builds (or 0.85.3 is even slightly better).
v0.85.1 stored custom pixel shader results in 16bit integer video levels. That's the internal data format madVR uses for temp buffers in its render pipeline, so I didn't have to do any funny conversions. However, VMR9 and EVR always ran pixel shaders in PC levels. So v0.85.3 now converts the internal madVR data to PC levels before running the custom pixel shaders. And since I don't want to lose BTB and WTW, I can't use 16bit integer textures, either, so the pixel shader passes are stored to 32bit float textures. The levels conversions and the 32bit float textures are probably causing the higher load on your GPU. I guess I could add another "trade quality for performance" option to only use 16bit float textures instead of 32bit float. That might restore *some* of the lost performance, on the cost of ever so slightly less precision. But it will most probably not get back to v0.85.1 performance levels.

Then signal Full Quantization Range in AVI InfoFrame - HDMI Sink shall understand this and shall use 0 - 255 quantization range. Only RGB colorspace shall be used for Full Quantization Range. Or perhaps force HDMI to DVI mode then only 0 - 255 RGB is allowed.
Yes, that would be the ideal solution.

If we use digital sources (i mean MPEG-2, H.264) then choice is quite simple 704 and 720 pixels, 702 - 716 problem affect only analog capture sources and knowledge about capture device is required to understand real number of pixels in captured source. This purely source/display dependable relation - to be precise we need to know what timing is used by grabber and what timing is used by display. Without this everything will be educated guess.
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:

PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480

I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?

omarank
13th December 2012, 13:46
:thanks: for adding the double/ triple expanded source levels toggle. I have two questions regarding the way madVR handles video levels:

1. If I increase say Black Level of source from 0 to +1, madVR changes the video levels by 0.5 (I guess) for regular content. Now if I change the Black level to +1 in case of a 10 bit content, will madVR change the video levels by 0.5 only or by 2 (=0.5*1023/255)?

2. If I switch to double expanded source levels while playing a 10 bit content, what levels are considered then?

madshi
13th December 2012, 13:52
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.

TheShadowRunner
13th December 2012, 13:54
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.

omarank
13th December 2012, 14:02
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.

OK, thanks for the clarification.

madshi
13th December 2012, 14:03
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.

TheShadowRunner
13th December 2012, 14:09
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.
Oh.. could we have a feature to grab exactly the source color range then?
When I use the ffdshow grab feature, or change madVR to VMR9 and use also ZP to make a screenshot, the resulting image is exactly what's on screen (PNG).
It's strange, I could have sworn madVR used to take exactly what's on screen in previous builds. ^^;

iSunrise
13th December 2012, 14:14
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:

PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480

I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?
IMHO, the whole ITU and non-ITU topic is already confusing the hell ouf of the majority of people which are using madVR. It will be used very rarely, if at all.

It certainly wouldn't hurt to offer it as an option, since I own about 800 DVDs (the majority is in NTSC format) I would like to give this a try myself. But I am not sure if I can even see a huge difference and if I want to go into the settings every time to change it.

hannes69
13th December 2012, 14:55
Originally Posted by hannes69
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).

Here the debug log: http://netload.in/dateixaiGwJat9z/madVR-log.rar.htm
Log created by using case (2). Hoping that helps ;)

leeperry
13th December 2012, 16:16
Why is he saying that? Ok, MPC-HC performs shaders in 8bit by default, I think, and cuts BTB and WTW. But that does not apply to madVR. The formula used by that script looks alright to me on a quick look. It converts TV to PC, though, so it's the opposite of what you want.
Yep, I would guess that the major issue with VMR9/EVR is indeed that BTB/WTW aren't preserved as you said :o

But I've got quite a lot of work ahead of me creating a dozen automatic gamut mapping profiles in PotP, so I don't plan on bothering with this script when a mere hotkey in mVR can do exactly what I want :p

Having users manually adjust frame scaling/cropping would be too troublesome
Well, I've got many different kinds of sources: VHS encodes, old and new PAL and NTSC DVD's, sloppy uncropped encodes....it's very easy when using a 4:3 display to stretch the picture horizontally in order to completely fill the screen, but it's a whole different story with 16/9 coz you never know where the 4:3 width actually stands and I'm afraid there will never be a "one size fits all" magic bullet to this issue :scared:

madshi didn't seem to like my idea of a 4:3 placeholder so I'll try to look into my options writing my own script, yay....no more whining, actions :D

I just want something like yellow rectangles in the 16/9 outer portions so I could clearly see the 4:3 limits =)

MPC provides hotkeys for pan & scan and I made my own pan & scan helper in PotP, so horizontal stretching really only takes me a few clicks: http://thumbnails102.imagebam.com/22556/391433225552817.jpg (http://www.imagebam.com/image/391433225552817)

pre and post are interchanged or they all run in pre?
they're all pre atm, a bugfix is in the works ;)

madshi
13th December 2012, 17:16
Oh.. could we have a feature to grab exactly the source color range then?
When I use the ffdshow grab feature, or change madVR to VMR9 and use also ZP to make a screenshot, the resulting image is exactly what's on screen (PNG).
It's strange, I could have sworn madVR used to take exactly what's on screen in previous builds. ^^;
madVR doesn't have screenshot functionality for that long, but for as long as it exists, it has always been PC levels. Before madVR had screenshot functionality, maybe you've pressed PrintScreen, and that produces the levels madVR is configured for. You can still do that, if you want.

I don't really see a good reason to produce BMP/PNG/JPG files with video levels. I don't have a spec at hand right now, but AFAIK BMP/PNG/JPG *always* have black at 0 by definition. I consider BMP/PNG/JPG files with video levels "out of spec".

Screenshots are often taken to upload them to the internet for comparison. And for that nothing else than PC levels makes sense. How could you compare screenshots with other people if some screenshots were TV levels and some PC levels? That simply makes no sense. Also, if you create video levels screenshots and send them to someone else who looks at them with his computer monitor, he'd see washed out black levels.

You're also the first person who's ever asked for screenshots in TV levels. I couldn't care less what ffdshow, VMR9 or ZP do. madVR does not aim to mimic what other software does. I'm doing things the way I consider "correct". The only way to convince me to offer an option to do video levels screenshot is to come up with a really convincing reason why that would be useful. It might also "help" if many more people requested that. But as long as you're the only one asking for this, and as long as I don't see much sense in your request, I'm going to stick with PC levels.

Originally Posted by hannes69
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).

Here the debug log: http://netload.in/dateixaiGwJat9z/madVR-log.rar.htm
Log created by using case (2). Hoping that helps ;)
Hmmmm... The log looks clean to me. Are you sure that you have all funny video processing options turned off in your GPU control panel (except deinterlacing related options)?

SyrupBuccaneer
13th December 2012, 17:22
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.

Same behaviour when paused. I tried disabling the madVR buffers [or at least change buffer to '1'] but that didn't change anything.

And it's the same behaviour whether I choose 'capture source' or 'capture real screen'

I don't know if it will tell you anything but I uploaded a log: http://www.mediafire.com/?6nsmums66f6jch7

-Open video
-Seek ahead
-Take capture
-Exit

chros
13th December 2012, 17:23
v0.85.1 stored custom pixel shader results in 16bit integer video levels. That's the internal data format madVR uses for temp buffers in its render pipeline, so I didn't have to do any funny conversions. However, VMR9 and EVR always ran pixel shaders in PC levels. So v0.85.3 now converts the internal madVR data to PC levels before running the custom pixel shaders. And since I don't want to lose BTB and WTW, I can't use 16bit integer textures, either, so the pixel shader passes are stored to 32bit float textures. The levels conversions and the 32bit float textures are probably causing the higher load on your GPU. I guess I could add another "trade quality for performance" option to only use 16bit float textures instead of 32bit float. That might restore *some* of the lost performance, on the cost of ever so slightly less precision. But it will most probably not get back to v0.85.1 performance levels.

Thanks for the explanation.
Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
If it's too much trouble then I'm waiting for the next build and see how it performs with the reduced quality setting...
Thanks!

toniash
13th December 2012, 17:38
Thanks for the explanation.
Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
If it's too much trouble then I'm waiting for the next build and see how it performs with the reduced quality setting...
Thanks!

Could you also test the overhead of only PS? (without upscaling or downscaling) Thanks!

hannes69
13th December 2012, 18:17
:rolleyes:Hmmmm... The log looks clean to me. Are you sure that you have all funny video processing options turned off in your GPU control panel (except deinterlacing related options)?
Yes, I am sure ;) Iīm using one of the latest MPC HC builds, madVR 0.85.3, LAV filters 0.54.1, AMD Catalyst 12.6 (the latest available for my Radeon HD4550, AMD stopped driver development for older GPUs like 4000 series) with Windows 7 64bit. In CCC everything concerning video is disabled. I also tried enabling them, nothing changed. So they stay disabled.
I use the AVS "color steps pattern" to determine the color shift. Blue stays the same, red gets a little less, green gets much more with using native DXVA decoding vs. software (or DXVA copy back). With native DXVA the top 4 green blocks get full saturated (so not distinguishable anymore), red gets slightly more saturated. I havenīt tried any other DXVA decoder, only the one from LAV.
Edit: Tried CoreAVC DXVA, same as LAV.
Tried NV12 and YV12 color space, both the same problem.
No further ideas...
Ahh almost forgot to mention: EVR doesnīt show the problem. Same configurations, just selected EVR custom instead of madVR.
What a pity, I have to blame madVR, really donīt like that, but one has to be honest...:rolleyes:

ryrynz
13th December 2012, 20:38
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.


That's like when I have exclusive mode enabled and I try taking a screenshot, I just disable exclusive mode with a keyboard shortcut and use Print Screen personally.

SyrupBuccaneer
13th December 2012, 21:23
That's like when I have exclusive mode enabled and I try taking a screenshot, I just disable exclusive mode with a keyboard shortcut and use Print Screen personally.

That's what I thought at first but it occurs in windowed mode as well. It's easier on Potplayer I guess because I can quickly switch between renderers using the context menu while it's playing, take a capture with EVR and then switch back to madVR.

TheShadowRunner
13th December 2012, 21:26
madVR doesn't have screenshot functionality for that long, but for as long as it exists, it has always been PC levels. Before madVR had screenshot functionality, maybe you've pressed PrintScreen, and that produces the levels madVR is configured for. You can still do that, if you want.

I don't really see a good reason to produce BMP/PNG/JPG files with video levels. I don't have a spec at hand right now, but AFAIK BMP/PNG/JPG *always* have black at 0 by definition. I consider BMP/PNG/JPG files with video levels "out of spec".

Screenshots are often taken to upload them to the internet for comparison. And for that nothing else than PC levels makes sense. How could you compare screenshots with other people if some screenshots were TV levels and some PC levels? That simply makes no sense. Also, if you create video levels screenshots and send them to someone else who looks at them with his computer monitor, he'd see washed out black levels.

You're also the first person who's ever asked for screenshots in TV levels. I couldn't care less what ffdshow, VMR9 or ZP do. madVR does not aim to mimic what other software does. I'm doing things the way I consider "correct". The only way to convince me to offer an option to do video levels screenshot is to come up with a really convincing reason why that would be useful. It might also "help" if many more people requested that. But as long as you're the only one asking for this, and as long as I don't see much sense in your request, I'm going to stick with PC levels.

Thanks for your extended answer.
I'm sorry this doesn't make sense to me at all.
If I'm taking a SCREEN SHOT, I expect the program to do just that, take a screen shot.
Not expand to PC levels, not do any tricks whatsoever, just capture exactly what's on screen.
Of course madVR doesn't aim to mimic other programs, but it's just what one expects!
Besides 99% of the contents is in limited range to begin with, so certainly people comparing screenshots would want to compare what the source is, without any color level modification?
I don't get it o_O
So please consider making the screenshot feature exactly that, a screenshot feature (!)
Or if you want the default behavior to do something else, please at least allow users who need and expect "exactly what's on screen" [a screen shot] to be able to do so, via an option somewhere?
Having to use PrntScr when a screenshot feature is implemented is.. nuts! XD
And maybe I'm the only asking that because other users haven't noticed yet? ^_^;;
See you,

TSR

SamKook
13th December 2012, 22:01
It's actually called a save image functionality if you're using MPCHC so you're not necessarily expecting it to take exactly what's on screen from the name but to save an image of the frame.

With that said, it would be nice to have both options. Not simply have the tv levels for the second(if they're applied), but also the resizing and all the applied filters so we could compare the effects of the different processing options more easily.
It could be useful for showing people how the quality of the picture can change with certain settings since most of them are clueless. That way they can be informed and choose which they prefer with less effort.

madshi
14th December 2012, 01:36
Same behaviour when paused. I tried disabling the madVR buffers [or at least change buffer to '1'] but that didn't change anything.

And it's the same behaviour whether I choose 'capture source' or 'capture real screen'

I don't know if it will tell you anything but I uploaded a log: http://www.mediafire.com/view/?t6bm44b4nj4a8xh
I'll have a look at the log tomorrow.

Can't you add back the way how it was working in 0.85.1 with a checkbox somewhere?
Not sure if I like the idea, I'll think about it.

Yes, I am sure ;) Iīm using one of the latest MPC HC builds, madVR 0.85.3, LAV filters 0.54.1, AMD Catalyst 12.6 (the latest available for my Radeon HD4550, AMD stopped driver development for older GPUs like 4000 series) with Windows 7 64bit. In CCC everything concerning video is disabled.
Ok. Still didn't get around to test this myself with an AMD card in win7 x64. Hopefully I'll be able to test that tomorrow. I just fear that this problem might only occur in your specific setup, for some funny reason, but we'll see...

I'm sorry this doesn't make sense to me at all.
If I'm taking a SCREEN SHOT, I expect the program to do just that, take a screen shot.
Not expand to PC levels, not do any tricks whatsoever, just capture exactly what's on screen.
If that's what you want then PrintScreen is exactly your ticket. What madVR offers is support for this official Microsoft interface:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd389570%28v=vs.85%29.aspx

This is how the media players create "screenshots" with madVR. The name "screenshot" is misleading, because really what the media players do is ask madVR for an RGB representation of the currently shown video frame *before* scaling. So this is far from what you would typically understand under the name "screenshot". Really, if you want a screenshots in the true sense of the word, PrintScreen is exactly what the doctor has ordered. What madVR offers is an RGB representation of the frame, properly encoded to the standards.

Basically madVR tries to produce the same screenshot for the same Blu-Ray on every PC, regardless of your madVR display device settings. This is intentional, and I believe it's a good and important feature, so screenshots made by different people are truely comparable.

Besides 99% of the contents is in limited range to begin with, so certainly people comparing screenshots would want to compare what the source is, without any color level modification?
The source is almost always YCbCr 4:2:0, and no media player I know of accepts that kind of "screenshot" from madVR. So madVR has no other choice than to convert the image from YCbCr 4:2:0 to RGB. And that conversion alone already involves quite a lot of processing which can't be avoided. Whether madVR converts YCbCr to RGB PC or TV levels doesn't change the number of processing steps, it just uses different matrixes, that's all.

And please have a look at the official PNG specification here:

http://www.w3.org/TR/PNG/#11IHDR

> The red, green, and blue samples determine the intensities
> of the red, green, and blue components of the pixel's colour;
> if they are all zero, the pixel is black, and if they all have
> their maximum values (2sampledepth-1), the pixel is white.

This clearly specifies that for 8bit PNG, black is at 0 and white is at 255. Which is exactly how madVR creates its "screenshots". The PNG spec does not have an option for video levels. PNG is always PC levels. So what madVR does is the only right thing to do, IMHO.

With that said, it would be nice to have both options. Not simply have the tv levels for the second(if they're applied), but also the resizing and all the applied filters so we could compare the effects of the different processing options more easily.
It could be useful for showing people how the quality of the picture can change with certain settings since most of them are clueless. That way they can be informed and choose which they prefer with less effort.
Options for providing screenshots before or after scaling/processing are planned for a (far away) future version. Currently I don't plan to offer video levels "screenshots" because I consider that to be "wrong".

TheShadowRunner
14th December 2012, 04:49
madshi, again thanks for this very detailed answer. I do understand the point you're making but am still baffled.
When I capture with VMR9, EVR or even Haali (all to PNG), the capture is in "limited range" and exactly what's on screen.
The microsoft document directly contradicts this? Or is it because those renderers work internally in limited range versus madVR working internally in full range?
When I capture with madVR, it's just completely black burnt and unusable.
I don't understand why madVR is the only renderer behaving this way.. do all the other renderers have it wrong?

6233638
14th December 2012, 05:05
madshi, again thanks for this very detailed answer. I do understand the point you're making but am still baffled.
When I capture with VMR9, EVR or even Haali (all to PNG), the capture is in "limited range" and exactly what's on screen.
The microsoft document directly contradicts this? Or is it because those renderers work internally in limited range versus madVR working internally in full range?
When I capture with madVR, it's just completely black burnt and unusable.
I don't understand why madVR is the only renderer behaving this way.. do all the other renderers have it wrong?I'm not sure I understand your setup.

In order to have screenshots appear "black burnt and unusable" that means your display is expecting video levels (16-235) and clipping everything below that.

For them to look that way, it means that your desktop is outputting 0-255 to your display, so it's not just screenshots, but rather everything except madVR that is having its levels clipped.


The problem here is not madVR, the problem is that you need to either fix your display's levels settings, or the video card's output levels.

I don't see any reason to take screenshots with video levels.

dansrfe
14th December 2012, 07:27
madshi,

I have an NTSC DVD that is telecined. madVR turns on deinterlacement and I change the source type to film but it seems like madVR is removing extra frames and the resultant motion isn't smooth.

Here's a 19 second sample cut from the film:

http://www.sendspace.com/file/i7eejt

Thanks!

TheShadowRunner
14th December 2012, 08:57
I'm not sure I understand your setup.
In order to have screenshots appear "black burnt and unusable" that means your display is expecting video levels (16-235) and
clipping everything below that.
That's right, my display is a Sony HDTV.

For them to look that way, it means that your desktop is outputting 0-255 to your display, so it's not just screenshots, but rather everything
except madVR that is having its levels clipped.
Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).
It has never bothered me since I only watch movies on this htpc, so with the complete video chain set to 16-235, I still watch movies the way they were meant to be seen.
Besides, the least conversion happen in the video chain, the optimal PQ is, right?
According to Section 6.6 of the HDMI 1.3 Specification document:
<snip>While using RGB, Limited Range shall be used for all video formats defined in CEA-861-D,
with the exception of VGA (640x480) format, which requires Full Range.
Also it was my understanding that Full RGB is a legacy feature coming from DVI specification, therefore not applicable for a recent HDTV which expects RGB limited via HDMI in the first place.

I don't see any reason to take screenshots with video levels.
But, again, are all the other video renderers doing it wrong? When frame capturing from EVR, VMR9 or Haali, the images are all in video levels (as they appear on screen).

dansrfe
14th December 2012, 09:19
Outputting video levels on any display is kind of a thing of the past. Kind of in the same boat as having new movies come out on DVDs and interlaced footage.

My main question now is: Why is video levels still in the spec for Blu-ray material? What is the purpose of having limited range anyways?

diizzy
14th December 2012, 09:35
Is deinterlacing known to be broken on Intel HD Graphics (IB)?
Doesn't work at all even if I force deinterlacing.
//Danne

madshi
14th December 2012, 10:20
I have an NTSC DVD that is telecined. madVR turns on deinterlacement and I change the source type to film but it seems like madVR is removing extra frames and the resultant motion isn't smooth.

Here's a 19 second sample cut from the film:

http://www.sendspace.com/file/i7eejt
Will have a look at this later...

Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).
It has never bothered me since I only watch movies on this htpc, so with the complete video chain set to 16-235, I still watch movies the way they were meant to be seen.
Besides, the least conversion happen in the video chain, the optimal PQ is, right?
Something is not right here. If your GPU outputs 16-235, then that practically means that your TV takes the Windows output (desktop, photos, games etc) and stretches it so that black (0) gets moved to 16. So if your GPU really outputs 16-235, your desktop should *not* be clipped. I think what is really happening is that your GPU outputs 0-255, which is actually a good thing. Then if your TV is set to 16-235, and madVR is set to 16-235, too, everything you're describing makes sense.

But, again, are all the other video renderers doing it wrong? When frame capturing from EVR, VMR9 or Haali, the images are all in video levels (as they appear on screen).
The bad thing about the other renderers is that you just can't rely on consistent behaviour. Let me explain how the other renderers work internally: They get NV12 YCbCr 4:2:0 and then use either DXVA or Direct3D to convert that to RGB. This YCbCr 4:2:0 -> RGB conversion is either done to RGB TV or PC levels, depending on the mood of the GPU driver. E.g. with NVidia there's a switch somewhere in the GPU control panel which defines whether this YCbCr -> RGB conversion produces TV or PC levels.

The MS video renderers don't really care much about PC vs. TV levels. They just rely on DXVA or Direct3D to convert to the "proper" levels. And then if you ask the MS renderers for a "screenshot" (again, the name is somewhat misleading), you'll get the direct output of the DXVA/Direct3D conversion. Which can be either TV or PC levels, depending on various different GPU settings. The end effect is that with the MS video renderers you can't really depend on which levels you'll get your "screenshot" in. On computer A it can be TV levels, on computer B it can be PC levels. All depending on whether the GPU outputs 0-255 or 16-235, and how the GPU control panel options are setup. IMHO this is all "wrong".

Let me tell you an experience I had several years ago, before I even thought about creating madVR:

There are sometimes different Blu-Ray encodings of the same movie in different countries. I like to compare them so I can get the best encoding of my favorite movies. When Pan's Labyrinth was released on Blu-Ray, there were about 5 different encodings available in different countries, some in VC-1, some in h264. So I looked at comparison screenshots on the internet and made a screenshot of the German Blu-Ray that I owned myself. And guess what happened? Due to my setup, my screenshot was not comparable to the other screenshots on the internet. So I actually thought for a while that the encoding on the German Blu-Ray had a different contrast or whatever. Only a while later I realized that my screenshot was at fault, due to incorrect levels.

I think the key point is that madVR creates screenshots that have black and white exactly where every other JPG and PNG file has black and white. So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.

Outputting video levels on any display is kind of a thing of the past. Kind of in the same boat as having new movies come out on DVDs and interlaced footage.

My main question now is: Why is video levels still in the spec for Blu-ray material? What is the purpose of having limited range anyways?
No. YCbCr video is in 99.99% limited range. And TVs usually do expect limited range RGB, too. Many newer TVs have a levels switch, though, to optionally also support full range RGB. Full range has historically been what PCs output. Limited range has historically been what consumer electronics (DVD players, Blu-Ray players, TV receivers) output.

Is deinterlacing known to be broken on Intel HD Graphics (IB)?
Doesn't work at all even if I force deinterlacing.
//Danne
It seems to be working with Sandy Bridge and Ivy Bridge. It has already been reported to not working on older Intel GPUs. I don't know why, and I can't really easily fix it, because I don't have access to such old hardware here, unfortunately.

6233638
14th December 2012, 11:11
That's right, my display is a Sony HDTV.How old is it? Anything recent enough to tell the driver to output 0-255 (default is 16-235 with HDMI unless the GPU is told otherwise) should be able to support it. It has to be outputting 0-255, if levels are being clipped.

If your TV is recent enough to have the XMB menus (https://www.google.com/search?q=sony+xmb&tbm=isch), the setting should be under:

Settings > Display > Video Input Settings > RGB Dynamic Range

"Auto" or "Full" should both work with 0-255.

Yes, everything (desktop, etc..) except the video is clipped (I force madVR to use 16-235). The reason is: nvidia.
On XP, as soon as a Nvidia card is connected to HDTV via HDMI, the driver sends RGB Limited range 16-235 and there's absolutely no way around it (the Custom resolution trick or SetDefaultFullRGBRangeOnHDMI trick both don't work on XP [I'd love for someone to tell me how they did if they managed to make it work, on XP]).Are you sure the card is outputting 16-235?

If the card was outputting 16-235, nothing should be clipped, as the card is compressing the levels, and a madVR screenshot would look correct.

If the card was outputting 16-235, and madVR is also outputting video levels, you will have the levels compressed twice so that video was being displayed at 30-218.

I think the key point is that madVR creates screenshots that have black and white exactly where every other JPG and PNG file has black and white. So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.I agree.

fallengt
14th December 2012, 14:23
How do I create a compatible 3Dlut file for Madvr?. I used DiscalGUI(argyllCMS) (http://dispcalgui.hoech.net/) to create icm profile and then create 3dlut profile(.3dl) from it but can't add it to madvr; "not valid 3dlut file" error.

vaporizer
14th December 2012, 18:23
crash report: radeon 7750 catalyst 12.10, mpc-hc 1.6.5.6261, lav filters 054.1 dxva-native, madvr 085.3, 2 monitors, 1x dvi / 1x hdmi

- 720p or smaller dxva: play video windowed, enter fse, return to window, move to other screen, crash (repeatable)
- 1080p dxva: play video on screen1 (windowed), move to screen2 (windowed), crash (repeatable)

always exception message 'access violation at address $4a4141a2 in module 'madvr.ax' read of address $0'

no problems if lav in copy-back mode, so maybe lav's fault. but no crash with evr cp.

if you need more infos... ask

Asmodian
14th December 2012, 21:43
How do I create a compatible 3Dlut file for Madvr?. I used DiscalGUI(argyllCMS) (http://dispcalgui.hoech.net/) to create icm profile and then create 3dlut profile(.3dl) from it but can't add it to madvr; "not valid 3dlut file" error.

You need to use yCMS (http://forum.doom9.org/showthread.php?t=154719) to create the 3Dlut file, or you can just measure the primaries and gamma curve of your calibrated display and write that into MadVR which creates the 3Dlut for you.

This is for converting the video's gamut to the display's gamut and displaying with the desired gamma, not doing what I would call a full calibration as is done with a "normal" CMS.

DragonQ
14th December 2012, 21:59
Found an example of incorrect ITU scaling on an HD upscale of SD material broadcast on E4 HD:

DVD = ITU (702x576= 16:9) (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20SD.png)
HD Upscaled = full-frame scaling (720x576 = 16:9) (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20HD.png)
HD Upscaled adjusted for ITU (http://www.aotplaza.com/Files/HTPC/Screengrabs/ITU%20601/The%20IT%20Crowd%20-%20HD%20Adjusted.png)

The HD upscale has more of the frame visible but I'm not sure which one of these is correct in terms of scaling. The black bars on either side of the HD upscale suggest that the DVD might be correct - if true, it's a shame that a public service broadcaster can't even get this right.

fallengt
14th December 2012, 23:48
This is for converting the video's gamut to the display's gamut and displaying with the desired gamma, not doing what I would call a full calibration as is done with a "normal" CMS.

nvm. I should read intruction first

glc650
15th December 2012, 01:17
Hello,

Been following the RGB level discussions of the last few days in this thread and I'm not sure how I should have this configured for my setup.

My TV does not seem to have any settings for this but from what I can gather online it supports 0-255.

So assuming this is correct, how should I setup CCC (Radeon 6570), madVR, and LAV video?

I use my HTPC for viewing photos and media playback (BR rips, AVCHD camcorder and GoPro footage).

Thanks,

->g.

dansrfe
15th December 2012, 01:41
So assuming this is correct, how should I setup CCC (Radeon 6570), madVR, and LAV video?

LAV Video: Untouched
madVR: 0-255
CCC: 0-255
TV: 0-255

TheShadowRunner
15th December 2012, 01:58
Something is not right here. If your GPU outputs 16-235, then that practically means that your TV takes the Windows output (desktop, photos, games etc) and stretches it so that black (0) gets moved to 16. So if your GPU really outputs 16-235, your desktop should *not* be clipped. I think what is really happening is that your GPU outputs 0-255, which is actually a good thing. Then if your TV is set to 16-235, and madVR is set to 16-235, too, everything you're describing makes sense.
I'm not certain what's going on tbh. I really do believe the nvidia driver is delivering RGB limited 16-235 to the TV, but that something strange is going on with the clipping (or not) of the desktop.
(I think so especially because in the nvidia panel, for "Digital Color format", changing between RGB <> YCbCR444 makes 0 difference when it comes to color levels)
(Desktop)
If I open paint shop pro and test colors 000000 to 161616, it's perfectly black. I do start to see (extremely faint) grayish around 171717.
(video)
If I play videos at 0-255, I suffer majorly of burnt blacks.
If I force madVR to 16-235, everything is fine, including the calibration files (1-Black Clipping.mkv, 2-APL Clipping.mkv & 3-White Clipping.mkv).

The bad thing about the other renderers is that you just can't rely on consistent behaviour. Let me explain how the other renderers work internally: They get NV12 YCbCr 4:2:0 and then use either DXVA or Direct3D to convert that to RGB. This YCbCr 4:2:0 -> RGB conversion is either done to RGB TV or PC levels, depending on the mood of the GPU driver. E.g. with NVidia there's a switch somewhere in the GPU control panel which defines whether this YCbCr -> RGB conversion produces TV or PC levels.Ah, I understand. I never touched this setting ("With the video player settings" is selected in nVidia panel) and it gives me 16-235 by default, with by exemple, WMP.

The MS video renderers don't really care much about PC vs. TV levels. They just rely on DXVA or Direct3D to convert to the "proper" levels. And then if you ask the MS renderers for a "screenshot" (again, the name is somewhat misleading), you'll get the direct output of the DXVA/Direct3D conversion. Which can be either TV or PC levels, depending on various different GPU settings. The end effect is that with the MS video renderers you can't really depend on which levels you'll get your "screenshot" in. On computer A it can be TV levels, on computer B it can be PC levels. All depending on whether the GPU outputs 0-255 or 16-235, and how the GPU control panel options are setup. IMHO this is all "wrong".
Thanks for clearing that up, I now get it. ^^;

And guess what happened? Due to my setup, my screenshot was not comparable to the other screenshots on the internet. So I actually thought for a while that the encoding on the German Blu-Ray had a different contrast or whatever. Only a while later I realized that my screenshot was at fault, due to incorrect levels.
You convinced me alright that different color levels for screen grabs depending on players/renderers/setups will trigger errors such as these and is less than ideal indeed.. ^^;

So if you e.g. look at your vacation photos, and then look at a madVR screenshot, they both have black at the same level. If your vacation photos look alright on your display, then so will madVR screenshots. If neither of them looks alright on your display (due to how the GPU is setup etc) then it's not the fault of madVR, instead your display setup simply doesn't allow to watch any photos (and thus any madVR screenshots, either) with correct black levels.
..and that's what I experience alright.
But regardless of the issue i'm experiencing, I still disagree on the fact that the best solution to "unify" screenshot color levels is to use PC levels.
After all the sources aren't the same. It makes sense for vacation photos or anything coming out of the PC world to be in PC levels.
But again, in the video world as we both know, 99% is in 16-235 color range by definition so taking "screenshot" using this color range makes more sense to me, if only to allow comparision with "screenshot" from other renderers which seem to be outputting 16-235 by default. XD

How old is it? Anything recent enough to tell the driver to output 0-255 (default is 16-235 with HDMI unless the GPU is told otherwise) should be able to support it. It has to be outputting 0-255, if levels are being clipped.
It's a Sony 40Z5500 from around 2 years ago, it was the top of the line model back then and does have the XMB menu.

Settings > Display > Video Input Settings > RGB Dynamic Range
I have no such setting :/
I only have "Settings" > "Picture" and "Settings" > "Video" (in which i can only alter/force the color format NTSC/PAL, etc..)
I do see a huge difference when I force the PS3 to output RGB full versus RGB limited, if it's any indicator..

Are you sure the card is outputting 16-235?
If the card was outputting 16-235, nothing should be clipped, as the card is compressing the levels, and a madVR screenshot would look correct.
If the card was outputting 16-235, and madVR is also outputting video levels, you will have the levels compressed twice so that video was being displayed at 30-218.Hmm I'm not sure about that, it seems like the nvidia driver has distinct color range behaviors for the desktop and video independently.(?)
I still do think the driver outputs 16-235 and my TV expects 16-235. Everything on the desktop that is really between 0-16 is brought back to black, so of course I suffer black crush for the desktop/pictures etc..
Is this reasoning flawed?

6233638
15th December 2012, 03:42
I still do think the driver outputs 16-235 and my TV expects 16-235. Everything on the desktop that is really between 0-16 is brought back to black, so of course I suffer black crush for the desktop/pictures etc..
Is this reasoning flawed?If the card was outputting 16-235, then nothing would be getting clipped on your display, because the card compresses anything rendered in 0-255, down to 16-235 specifically to avoid clipping.

If the card is outputting 0-255, and the display is set up only to accept 16-235, then anything outside the 16-235 range will be clipped.

It should like you have inadvertently managed to force 0-255 output when your display doesn't support that, and you should be sending it 16-235.

Even if you don't have a levels option, some displays will clip anything outside 16-235 by default, but it's not a hard clip, and you are able to use the brightness & contrast controls to have them display 0-255. (other displays that have a hard clip to 16-235, will never show anything outside the 16-235 range) Have you tried that?

There may also be a "super white" or some other option to switch your display's levels though.
EDIT: I've just read through your TV's manual and there doesn't appear to be an option for this. Strange, I thought all the XMB-equipped models had it.

The first thing I would try is switching to the "graphics" scene mode.
If that doesn't work, try adjusting brightness/contrast to see if you can make levels outside 16-235 visible.
If that doesn't work, you need to get your GPU outputting 16-235, and not 0-255.

glc650
15th December 2012, 04:45
LAV Video: Untouched
madVR: 0-255
CCC: 0-255
TV: 0-255And if I find out my TV doesn't support 0-255?

Is there some sort of test pattern/pic I can use to verify?

BetA13
15th December 2012, 05:02
this is an (black white) 0 - 255 PIC..on my CRT i see all color differnces..on my HD TC however i do not..on my hdtv i use 10 - 255 and its perfect now thanks to madshis custom color range option..

http://i155.photobucket.com/albums/s297/mikeyurkus/0-255BWDVD.png

16 - 255 gave me overgreyed blacks and artefacts in grey, black portions of teh screen..

Mangix
15th December 2012, 05:37
I found an annoying issue with madVR. On several .vob/.mkv files which are 30i, using LAV Video to decode it(software) results in deinterlacing being activated. The same is not true of madVR's built-in decoder. it says deintertlacing off (framerate).

manma
15th December 2012, 06:28
I FINALLY figured out why I'm getting dropped frames in madvr. Its leafs. Scenes with lots of green leafs, trees, and that sorta thing make my GPU usage rocket up to 100% and madvr starts dropping frames like crazy. Is there anything that could be done to make madvr handle leafs better? If it matters, I'm using Jinc4, and my GPU Is a GTX460.

ryrynz
15th December 2012, 07:31
Its leafs

It's leaves :)

I believe Jinc 3 AR is slightly less demanding than Jinc 4 AR so you could try that. If you still have frame drops and you want to keep using Jinc then I'd recommend overclocking your GPU or selecting a less demanding Chroma algorithm otherwise choose Lanczos 3 AR instead.

corporalgator
15th December 2012, 08:26
Sounds good to me. You do lose the values < 16 and > 235 this way, but these values are not supposed to be seen on screen, anyway, so it's not a big loss. You could also set your plasma to standard HDMI range and madVR to 16-235. That should be roughly identical in image quality for madVR playback, while preserving < 16 and > 235 data. But if you do that, your desktop and photos etc will have wrong black/white levels.



Thanks, I changed based on your suggestion and now am able to get btb and wtw. I calibrated black so 16 isn't visible and left most of the wtw, since those signals apparently exist on a lot of blu-rays like in chrome reflections.

Another question if you don't mind. My Plasma can do 60 hz and 48. It's a panasonic st30. When I send it 24p, I can switch to 48hz, but it has horrible flicker, so that's a no go.

So, I'm left with 60hz. My question is, I can have madvr switch the refresh rate to 24p, which means the tv does 3:2 pull down. The tv says the option is off, but since there's video playing on the screen, it must be doing 3:2. My other option is to not do refresh rate switching, leaving the video card at 60hz. Does that mean madvr is doing the 3:2 pulldown or is it my vid card? Which is preferable, letting the tv handle it, or sending it already switched?

manma
15th December 2012, 08:44
It's leaves :)

I believe Jinc 3 AR is slightly less demanding than Jinc 4 AR so you could try that. If you still have frame drops and you want to keep using Jinc then I'd recommend overclocking your GPU or selecting a less demanding Chroma algorithm otherwise choose Lanczos 3 AR instead.

Its funny, I actually wrote leaves, and then replaced each one with leafs before I hit submit for some reason. Weird how spell check likes both spellings.

alizard
15th December 2012, 10:04
Madshi, I'm using a AMD 4870 with 12.6 drivers on Windows 8 x64.
Here is the log file: http://www.filedropper.com/madvr-log

truexfan81
15th December 2012, 11:32
I'm just curious if anyone else has experienced this bug while using cuvid and madvr on win7

http://support.microsoft.com/kb/983615

thanks

ThurstonX
15th December 2012, 15:53
Its funny, I actually wrote leaves, and then replaced each one with leafs before I hit submit for some reason. Weird how spell check likes both spellings.
Well, to "leaf" is a verb, as in, While I sat in the dentist's office, I leafed through a magazine." So "leafs" is a valid spelling. It's all about context ;)

Yeah, horribly OT, but it seems a slow Sat. But definitely try something less demanding than Jinc4 :D

khanmein
15th December 2012, 16:50
guys my bro lappy unable to use GT630M on mpc-hc? how to solve it? using 306.97

goldie
15th December 2012, 16:52
madshi, many thanks for your great work, Jinc/AR/DXVA2native/ColorControls! (maybe I'm lag :p) Good job, keep going.

wanezhiling
15th December 2012, 16:53
guys my bro lappy unable to use GT630M on mpc-hc? how to solve it? using 306.97

http://forum.doom9.org/showpost.php?p=1603351&postcount=15891