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

DigitalLF
21st October 2015, 15:28
first of a bugreport!
in MadVR. devices - sony vm500es - properties - green text right of "test projector" says (JVC) until i press "FIND"/"TEST" again, even if the ip is correct.





Sorry, typo. I meant: "Do you have black bar *detection* activated"?
yes!


Do you have any other software which could potentially be issuing ip control commands to your JVC while madVR is running? That could cause trouble.
Just so you know. I have a Control4 system that talks TCP/IP with my projector!


I didn't mean which *device* was bold. I mean the "screen config" profiles. You do have different "screen config" profiles setup, so you could activate different lens memories, right? When you open the settings dialog while madVR is doing video playback, one of the sceen config *profiles* should be bold. Is it always the correct one?
oh sorry! No! i did not know there was a "screen config group" but i don't know how to script. i saw that i can make hotkeys for it and i tried that and that did not work more then that the OSD said "screen mode 2.40:1" or something like that.

EDIT: i now tried to make a script. Is this correct? on a "1.85:1" movie it still uses "2.40:1" my profiles are called "1.77:1", "1.85:1", "2.40:1"
if (AR = 1.85:1) "1.85:1" else
if (AR = 2.35:1) "2.40:1" else
if (AR = 2.40:1) "2.40:1" else "1.77:1"


1) What happens if you activate mem2, and then while it's still in the process of switching to mem2, if you activate mem2 *again*? Does it abort the operation then? Or does the 2nd mem2 button press have no effect?
it stops and says failed, if i press mem2 while mem2 is being "loaded" if i then press "mem3" it goes back to "mem3"


2) What happens if you activate mem2, wait until it's fully done, then activate mem2 again? Does the projector do anything at all? Or is it clever enough to know that nothing needs to be done?
then the projectors OSD just shows and says "adj. completed".


With this new build please also repeat the following 2 tests:
downloaded and tested.


1) Does abort work correctly now?
no it does not. still nothing. are you sending a incorrect command?

2) If you press mem2, and then mem1, before mem2 is fully done, does it properly abort mem2 and automatically activate mem1 now, with just the one button press?
No it stops like a "ABORT" would. and writes a log line "failed"

aufkrawall
21st October 2015, 16:28
Maybe linear light should be used by default for SuperRes?
Also with strength 3, sharpness 2 an (I think mostly unwanted) increase of brightness can be observed without it.

LL on:
http://abload.de/thumb/llon99s32.png (http://abload.de/image.php?img=llon99s32.png)

LL off:
http://abload.de/thumb/lloffp9sh8.png (http://abload.de/image.php?img=lloffp9sh8.png)

JarrettH
21st October 2015, 18:08
Is there some reason why I can't get the madvr test patterns (ytp files) to load? It's been like this for 6 months or more. Just says cannot render file. I'm on 88.21 and MPC 1.7.9, both 64-bit. Does this maybe have a 64-bit conflict? Windows 7 SP1

cvrkuth
21st October 2015, 18:29
After install new version, my devices are gone?
That's weird. I can only guess that your settings configuration got corrupted/damaged somehow. Does going back to the old version fix the problem? Please run a checkdisk/scandisk to make sure your file system is healthy.

Uninstall AMD-Catalyst-15.9.1Beta-64Bit and install AMD-Catalyst-15.7.1-Win10-64bit and now is ok

Regards!

Olivier C.
21st October 2015, 20:46
Seems interesting. Are you sure the GPU is not changing frequencies to save power?

On a quick test I get 35% usage for Catmull-Rom without linear light and 41% with LL for image downscaling on a 24fps 4K viedo and that's on a Geforce 750Ti(!).

Could you post your settings, especially scaling algorithms used, smooth motion (on/off), dithering used and screenshot of debug OSD?

Thanks for your reply.

You can find below the settings and results with Linear Light On & Off :


OSD MPC-HC & GPU-Z with Linear Light OFF :
http://img15.hostingpics.net/thumbs/mini_286452MPCHCLLOFF.jpg (http://www.hostingpics.net/viewer.php?id=286452MPCHCLLOFF.jpg)

OSD MPC-HC & GPU-Z with Linear Light ON :
http://img15.hostingpics.net/thumbs/mini_583291MPCHCLLON.jpg (http://www.hostingpics.net/viewer.php?id=583291MPCHCLLON.jpg)

madVR - General Settings :
http://img15.hostingpics.net/thumbs/mini_367171madvrGeneralsettings.jpg (http://www.hostingpics.net/viewer.php?id=367171madvrGeneralsettings.jpg)

madVR - Output :
http://img15.hostingpics.net/thumbs/mini_766354madVRoutput.jpg (http://www.hostingpics.net/viewer.php?id=766354madVRoutput.jpg)

madVR - Trade Quality for Performance :
http://img15.hostingpics.net/thumbs/mini_994018madVRTradeQuality.jpg (http://www.hostingpics.net/viewer.php?id=994018madVRTradeQuality.jpg)

madVR - Downscale :
http://img15.hostingpics.net/thumbs/mini_825447madvrDownscaleLLOFF.jpg (http://www.hostingpics.net/viewer.php?id=825447madvrDownscaleLLOFF.jpg)

madVR - Chroma Upscaling :
http://img15.hostingpics.net/thumbs/mini_601661madvrChromaUpscaling.jpg (http://www.hostingpics.net/viewer.php?id=601661madvrChromaUpscaling.jpg)

madVR - Double Luma :
http://img15.hostingpics.net/thumbs/mini_186950madvrDoubleLuma.jpg (http://www.hostingpics.net/viewer.php?id=186950madvrDoubleLuma.jpg)

madVR - Upscaling Refinement :
http://img15.hostingpics.net/thumbs/mini_120772madvrUpscalingrefinement.jpg (http://www.hostingpics.net/viewer.php?id=120772madvrUpscalingrefinement.jpg)

madVR - Dithering :
http://img15.hostingpics.net/thumbs/mini_153717madVRDithering.jpg (http://www.hostingpics.net/viewer.php?id=153717madVRDithering.jpg)

madVR - Smooth Motion :
http://img15.hostingpics.net/thumbs/mini_669892madVRSmoothMotion.jpg (http://www.hostingpics.net/viewer.php?id=669892madVRSmoothMotion.jpg)

madVR - Image Enhancements :
http://img15.hostingpics.net/thumbs/mini_482675madVRImageEnhancements.jpg (http://www.hostingpics.net/viewer.php?id=482675madVRImageEnhancements.jpg)

madVR - Deband :
http://img15.hostingpics.net/thumbs/mini_199699madVRDeband.jpg (http://www.hostingpics.net/viewer.php?id=199699madVRDeband.jpg)

Hope it helps

mcn
21st October 2015, 21:09
I'm using madVR with MPC-HC.
I noticed that if I take a screenshot with the window resized below the actual video size the image is taken at the window resolution, with aspect ratio correction (if any) applied.

This is an interesting behaviour and I would like to ask if it's possible (and how) to:

force screenshots to be always taken at the original video resolution

take screenshots at the window size resolution even when it's resized to be larger than the original video dimensions

jmonier
21st October 2015, 22:13
Just give the test tool a try, please, to double check the reliability of Ip Control with your JVC, using my code. Thanks.

Do you have any other software which could potentially be issuing ip control commands to your JVC while madVR is running? That could cause trouble.

Here's what's happening:

If the JVC is off or it's been turned on locally (JVC remote control or power button) everything works as expected using your program.

If the JVC has been turned on remotely by me (either by RS232 or TCPIP) then your program will still find it, but always reports power state as standby and NONE of the other commands work.

My software does not issue IP (or rs232) control commands once power up is completed until power down. Note that I close the socket after every control command (and that the JVC would close it if I don't).

Thus it seems that once the JVC has been turned on by a control command from one source, it will no longer accept control commands from any other source (TCPIP or RS232) until a power off command is issued from the same source that issued the power on.

nevcairiel
21st October 2015, 22:14
In the next few weeks only expect bugfixes and small improvements, no big new features. Need to concentrate on my daily job for a while now.

Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D

agustin9
21st October 2015, 23:39
I'm still having problems with the subtitle margin. The bottom margin when moving the subtitles to the bottom of the window isn't woking for me. Anyone with the same problem? Thanks!

truexfan81
22nd October 2015, 00:54
Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D

Maybe its because my athlon 2 dualcore 2.9, 4GB ram, and NVIDIA GTX 650 1GB is to old to use any of the new stuff, but i've had 0 issues with the latest versions of madvr.

i am mostly just using Jinc3AR with AdaptiveSharpen 0.7 pre upscale

djsolidsnake86
22nd October 2015, 01:11
with a 7850 what are the suggested settings?

Arm3nian
22nd October 2015, 05:12
with a 7850 what are the suggested settings?

Whatever looks good to you and stays under the max render time.

huhn
22nd October 2015, 06:41
Thanks for your reply.

You can find below the settings and results with Linear Light On & Off :


should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.

ionutm80
22nd October 2015, 07:07
Hi guys,

I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.

First let me list my rig and the initial settings:

- Intel NUC D34010WYKH, intel Core I3 4010U (r (1.7 GHz Dual-Core processor with 3 MB smart cache), Intel HD 4400 GPU, Crucial 2x4GB = 8GB DDR3 1600MHz, 60GB OCZ Agility SSD
- LAVFIlters: DXVA Copy-Back
- madVR:
* chroma-up: BCB75AR
* image-up: DXVA
* image doubling: None
* image-down: DXVA
* enable fullscreen exclusive mode
* dithering: ordered
* smooth motion: off
- SVP: default 1g profile, 59.94Hz
- TV; Sony KDL26EX320, 60Hz, 1366x768
- ReClock: WASAPI exclusive Asus Xonar U3, 24 bit padded into 32, resolution of 59.94 input manually first time the video plays
- movies: Blu-Rays: 1920x1080 / 800, 23,976fps, DVDs: 720x576, 25,000fps (PAL) , Samsung S4: 1920x1080, 29,911fps.

With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:

http://i.imgur.com/2h3fKyP.jpg

But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5

Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?

ashlar42
22nd October 2015, 10:45
mashi, I fully admit that I'm ignorant about this, and you might have already given an answer for this. Considering your experience with dedicated scalers (Lumagen, if I remember correctly from our Panasonic discussions for 1:1 pixel mappings), is Non Linear Stretch for 4:3 material something you might be considering for the future?

madshi
22nd October 2015, 10:55
May be you put link to this http://forum.doom9.org/showthread.php?p=1724688#post1724688 from first post of the thread?
Not a bad idea, but then I don't think many users bother to read the first post. At some point there's going to be a manual or something like that. For now we'll have to live with constantly repeating support requests, I fear...

Is there some reason why I can't get the madvr test patterns (ytp files) to load? It's been like this for 6 months or more. Just says cannot render file. I'm on 88.21 and MPC 1.7.9, both 64-bit. Does this maybe have a 64-bit conflict? Windows 7 SP1
The test patterns currently only support 32bit media players.

Uninstall AMD-Catalyst-15.9.1Beta-64Bit and install AMD-Catalyst-15.7.1-Win10-64bit and now is ok
Ah ok. That means that with the beta driver seemingly no monitors were reported at all to madVR by your OS/driver.

You can find below the settings and results with Linear Light On & Off
should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.
^

Yep, seems to be a GPU RAM size issue. When enabling linear light, I'm using 32bit floating point textures for some processing steps, which consume twice as much RAM as the default format. I'm a bit surprised GPU RAM size seems to more than double, though, that doesn't make a lot of sense, to be honest. Anyway, you can probably work around the issue by reducing the size of the GPU queue a bit.

madVR v0.89.12.0 seems to work as expected.
Performance improvements of NNEDI3 and SuperRes seem to pay off, I can watch 1080p60 -> WQHD with NNEDI3 32 chroma, Jinc AR image, SuperRes 3 passes and maximum deband + SM without dropped frames on my GTX 980 OC.
I'm relatively sure that this wasn't possible in the past.
Good to hear!

first of a bugreport!
in MadVR. devices - sony vm500es - properties - green text right of "test projector" says (JVC) until i press "FIND"/"TEST" again, even if the ip is correct.
Ooops, good catch! Here's a fixed madHcCtrl.exe for you:

http://madshi.net/madHcCtrlSony.rar

Does that fix the problem for you? It might also make lens memories work for your Sony.

EDIT: i now tried to make a script. Is this correct? on a "1.85:1" movie it still uses "2.40:1" my profiles are called "1.77:1", "1.85:1", "2.40:1"
if (AR = 1.85:1) "1.85:1" else
if (AR = 2.35:1) "2.40:1" else
if (AR = 2.40:1) "2.40:1" else "1.77:1"
AR is often not *exactly* one of those numbers. E.g. imagine a Cinemascope Blu-Rays with 1920x796 active pixels. That's an AR of 2.4120603015075376884422110552764. You can't write the script in such a way to handle every possible AR. So instead of using "if AR = something" use "if AR > something". So your script could read:

if (AR > 1.9) "2.40:1" else
if (AR > 1.8) "1.85:1" else "1.77:1"

That said, do you really need different profiles for 1.85:1 and 1.77:1? Your call, though. Personally, with my CIH setup I just have 2 profiles, one for Cinemascope movies, and one for every other AR. So I'm just using "if (AR > 1.9) "21:9" else "16:9"".

Maybe linear light should be used by default for SuperRes?
Also with strength 3, sharpness 2 an (I think mostly unwanted) increase of brightness can be observed without it.
The difference doesn't seem so dramatic to me. But yes, there is a difference. But look at the roof ceiling line of the left most building. The line is noticably fatter in the linear light image. Once again, as I said before, ideally linear light should be enabled if the source was downscaled in linear light, or if it wasn't downscaled at all. But if the source was downscaled in gamma light from a higher resolution master, then disabling linear light should produce results that are nearer to the original master.

I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.

I'm using madVR with MPC-HC.
I noticed that if I take a screenshot with the window resized below the actual video size the image is taken at the window resolution, with aspect ratio correction (if any) applied.

This is an interesting behaviour and I would like to ask if it's possible (and how) to:

force screenshots to be always taken at the original video resolution

take screenshots at the window size resolution even when it's resized to be larger than the original video dimensions

Screenshot functionality will be revisited at some point in the future, but probably not in the next few weeks.

Here's what's happening:

If the JVC is off or it's been turned on locally (JVC remote control or power button) everything works as expected using your program.

If the JVC has been turned on remotely by me (either by RS232 or TCPIP) then your program will still find it, but always reports power state as standby and NONE of the other commands work.

My software does not issue IP (or rs232) control commands once power up is completed until power down. Note that I close the socket after every control command (and that the JVC would close it if I don't).

Thus it seems that once the JVC has been turned on by a control command from one source, it will no longer accept control commands from any other source (TCPIP or RS232) until a power off command is issued from the same source that issued the power on.
That's quite interesting! Let's look at the possible scenario cases one by one and let me ask a few questions for clarification:

1) projector is turned on by rs232

How is this possible?? At least my JVC X35 has a setup menu option to either use rs232 or ip control - I have to choose! Does your projector not have such a menu option? If it does have such an option, have you set it to rs232 or ip control?

Does your own ip control software work if you turned the projector on via rs232, while my ip control test tool fails?

2) projector is turned on by your ip control software

In this situation my ip control test tool fails, too? Does your own ip control software manage to switch lens memories or stuff in this situation, while my test tool fails?

3) projector is turned on physically (remote or project power switch)

In this situation my ip control test tool works perfectly?

4) projector is turned on by my ip control test tool

What happens in this case? Does my test tool work? Does your ip control software work?

Honestly I consider that a good thing. With all these new features in every other madVR release of late, there hasn't been a version for a long time that I considered perfectly stable and problem free. :)
Maybe a period of quiet and collecting and fixing issues is a good thing. :D
Well, I wasn't planning to do intensive bug searching & fixing, instead of adding new features. The point was just to reduce madVR development time for a while. So I'm not sure if that will help overall stability much.

Anyway, I think the biggest stability problems were caused by adding support for rendering in paused&stopped graph state, followed by changes needed to make black bar detection work. All those changes were rather invasive, and thus came with a high risk of new stability issues. However, I think most of the other new features planned for the near future are less risky, so stability should trend up now, regardless of whether I add new features or not.

Do you have any specific problems with v0.89.12? My impression from feedback so far is that it's working pretty well and stable.

I'm still having problems with the subtitle margin. The bottom margin when moving the subtitles to the bottom of the window isn't woking for me. Anyone with the same problem? Thanks!
Which subtitle renderer? SRT, ASS or bitmap (PGS/SUP)? Screenshots and a sample would be nice.

I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.

With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:

[...]

But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5

Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?
I've no idea why both reducing and greatly increasing the queue sizes would help over the default settings. Sounds strange to me. Generally, I do like high queue sizes, as long as your CPU and GPU RAM can handle it. There shouldn't be much downside to high queue sizes, except maybe slower switching between windowed <-> fullscreen mode, and slower OSD reaction. But I suppose most people would find these problems of low importance compared to smooth and reliable video playback. So by all means, go crazy with the queue sizes etc. Just make sure you don't choose values which your CPU/GPU RAM can't handle, because doing that would slow things down dramatically.

mashi, I fully admit that I'm ignorant about this, and you might have already given an answer for this. Considering your experience with dedicated scalers (Lumagen, if I remember correctly from our Panasonic discussions for 1:1 pixel mappings), is Non Linear Stretch for 4:3 material something you might be considering for the future?
Personally, I consider NLS very ugly and damaging to the source. Especially horizontal camera pans look like you'd had taken drugs. So while I might add it at some point, it's very low priority.

nevcairiel
22nd October 2015, 10:59
Do you have any specific problems with v0.89.12? My impression from feedback so far is that it's working pretty well and stable.

So far it seems pretty good, indeed. Will have to keep an eye on it. :)

madshi
22nd October 2015, 11:16
So far it seems pretty good, indeed. Will have to keep an eye on it. :)
Glad to hear that!

FWIW, the later v0.89.x builds have several stability bug fixes in them, which e.g. v0.88.x/v0.87.x and older builds are lacking. E.g. I've been working with CiNcH on live TV playback stability when switching TV channels. He says the later v0.89.x builds are more stable with DVBViewer than any previous build ever was. So I'm hopeful about stability, especially considering that no further *invasive* changes are planned for the near future.

amire
22nd October 2015, 11:56
nnedi3 doesn't work on my system .freeze the image .need fix thx

huhn
22nd October 2015, 12:26
you didn't provide us any informations for what ever reason so here is may guess.

disable CUVID in lavfilter and try again.

CiNcH
22nd October 2015, 13:05
FWIW, the later v0.89.x builds have several stability bug fixes in them, which e.g. v0.88.x/v0.87.x and older builds are lacking. E.g. I've been working with CiNcH on live TV playback stability when switching TV channels. He says the later v0.89.x builds are more stable with DVBViewer than any previous build ever was.
The problems got pretty severe after 0.88.16 with the introduction of Stop/Pause rendering. DXVA errors, crashes, freezes... Last problems for me finally got fixed with 0.89.6. I am now taking every step and perform regression tests (I am not testing fancy stuff like NNEDI though ;) ). Currently on 0.89.12. Never experienced a problem anymore after our fixing session.

Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).

Olivier C.
22nd October 2015, 13:16
should be a Vram issue with madVR. it looks like it tries to take more than 6 GB ram and is now using a ram page file which is terrible slow.


Yep, seems to be a GPU RAM size issue. When enabling linear light, I'm using 32bit floating point textures for some processing steps, which consume twice as much RAM as the default format. I'm a bit surprised GPU RAM size seems to more than double, though, that doesn't make a lot of sense, to be honest. Anyway, you can probably work around the issue by reducing the size of the GPU queue a bit.


Big thanks to you !

agustin9
22nd October 2015, 13:37
Which subtitle renderer? SRT, ASS or bitmap (PGS/SUP)? Screenshots and a sample would be nice.
With the latest XySubfilter beta, using SRT. It happens with every video and SRT I play, of course when moving the subtitles to the bottom of the window...

amire
22nd October 2015, 13:39
you didn't provide us any informations for what ever reason so here is may guess.

disable CUVID in lavfilter and try again.

thank you , it works .

SweetLow
22nd October 2015, 13:51
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward.
Are the video sample exists? Since i use DX11 with HD4000 ;)

Francois76l
22nd October 2015, 14:42
Hi guys,

I really need your help in understanding the effect of some changes I have made in madVR that allowed me to have a smooth playback again after hours of fighting with a nasty stuttering. Sorry if this seems stupid but I just need to know whether I have finally found the magic solution or is just something circumstantial.

First let me list my rig and the initial settings:

- Intel NUC D34010WYKH, intel Core I3 4010U (r (1.7 GHz Dual-Core processor with 3 MB smart cache), Intel HD 4400 GPU, Crucial 2x4GB = 8GB DDR3 1600MHz, 60GB OCZ Agility SSD
- LAVFIlters: DXVA Copy-Back
- madVR:
* chroma-up: BCB75AR
* image-up: DXVA
* image doubling: None
* image-down: DXVA
* enable fullscreen exclusive mode
* dithering: ordered
* smooth motion: off
- SVP: default 1g profile, 59.94Hz
- TV; Sony KDL26EX320, 60Hz, 1366x768
- ReClock: WASAPI exclusive Asus Xonar U3, 24 bit padded into 32, resolution of 59.94 input manually first time the video plays
- movies: Blu-Rays: 1920x1080 / 800, 23,976fps, DVDs: 720x576, 25,000fps (PAL) , Samsung S4: 1920x1080, 29,911fps.

With the above settings and everything else left as default in madVR I had a terrible stuttering even if madVR stats showed 1 frame drop every 6-7 hours. Please see print screen below:

http://i.imgur.com/2h3fKyP.jpg

But then I have just spotted that my "present queue" was showing 5-7/8 instead of 7-8/8 so I decided to drop the frames presented in advance from 8 to 4 in fullscreen mode and from 8 to 3 in windowed mode. Also in the tab trade quality for performance I've checked the first 4 options up to "store custom pixel shader ..." ... and voila my "present queue" was now 2-3/3 (windowed) and 3-4/4 (fullscreen) and the stutter was almost non percievable. Then I remember an article on Anandtech where they tested the NUC (the Core I5 version) with madVR and used "CPU and GPU queue sizes of 128 and 24". I said why not try, did that and no more stutter visible, madVR shows 1 drop frame every 1.02 days and SVP performance graphs show CPU average at 67% with 1g profile. Indeed the guys at Anandtech also increased the frames presented in advance to 16 ... and this is where I'm a bit lost. They have practically maxed everything.
http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review/5

Can you please tell me in which way did my PC benefited from the above and whether maxing out CPU and GPU queues size is a right thing to do in my case? Are there any other settings that would give me a better bang for the buck?

Hello ionutm80,
something is strange with your reclock parametrization.
Try to select "Automatic" instead of "59.940" fps.
Your video is running @ 23.976Hz, not 59.940Hz.
http://img11.hostingpics.net/pics/5322452h3fKyP.jpg

ionutm80
22nd October 2015, 15:04
@Francois76l

Hi, indeed is what I have inputed manually in ReClock because I'm using SVP which takes my 23,976 movie and interpolate frames up to 59.94 (23,976*5 /2) and hence ReClock should just marginally adjust vs my display resolution.

huhn
22nd October 2015, 15:05
nothing is strange he is using SVP so the source frame rate is not the same as the input frame rate.

Francois76l
22nd October 2015, 15:53
oups yes, you're right!...
:)

jmonier
22nd October 2015, 16:29
That's quite interesting! Let's look at the possible scenario cases one by one and let me ask a few questions for clarification:

1) projector is turned on by rs232

How is this possible?? At least my JVC X35 has a setup menu option to either use rs232 or ip control - I have to choose! Does your projector not have such a menu option? If it does have such an option, have you set it to rs232 or ip control?

No menu option at all. Both RS232 and TCPIP are available at all times

Does your own ip control software work if you turned the projector on via rs232, while my ip control test tool fails?

It would take quite a bit of coding for me to set up to test this so I'd like to defer it for the moment.

2) projector is turned on by your ip control software

In this situation my ip control test tool fails, too?

Yes (as I said).

Does your own ip control software manage to switch lens memories or stuff in this situation, while my test tool fails?

Yes (as I said).

3) projector is turned on physically (remote or project power switch)

In this situation my ip control test tool works perfectly?

Yes (as I said).

4) projector is turned on by my ip control test tool

What happens in this case? Does my test tool work? Does your ip control software work?

This is where the result was not as I expected it. Both of them DO work interchangeably for this case.

Could it be that your software turns on the JVC in a different way than I do? Do you do the full handshaking (PJ_OK/PJREQ/PJACK)?

BUT, the automated operation is still as before, i.e. VERY intermittent, so it's starting to appear that there's something totally different at work in that case and all the above is just a red herring.

JarrettH
22nd October 2015, 16:37
The test patterns currently only support 32bit media players.

Could I just as well test using a video? I've done this before - looking for the dither noise to vanish. Does it need to be in motion?

Shiandow
22nd October 2015, 16:43
The difference doesn't seem so dramatic to me. But yes, there is a difference. But look at the roof ceiling line of the left most building. The line is noticably fatter in the linear light image. Once again, as I said before, ideally linear light should be enabled if the source was downscaled in linear light, or if it wasn't downscaled at all. But if the source was downscaled in gamma light from a higher resolution master, then disabling linear light should produce results that are nearer to the original master.

I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.

As far as I can tell the only reason gamma light seems to thin black lines is that it makes the image lighter. Admittedly this can look nice for Anime, but it will make white lines look too fat. It's hard too say which is better, but I think using linear light will give a more consistent result. If for example you draw a black line and white line of equal thickness and scale them with SuperRes then I suspect that they will still have equal thickness with linear light but different thickness when you use gamma light, maybe somebody could try this out?

Anima123
22nd October 2015, 19:49
Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).

That happened when GPU is not powerful enough while 'present a frame for every VSync' enabled.

You can try disabling the option and the jumping back and forward would have gone.

aufkrawall
22nd October 2015, 21:12
The difference doesn't seem so dramatic to me.

That may be because the brightness already has increased for some structures by using SuperRes, despite of LL on or off (yeah, sorry, I didn't post a picture without SR).
LL off gives some increase on top of that. But the increase by SuperRes with LL may be "wanted", e.g. also NNEDI3 256 looks brighter than bilinear in this case.


I'm aware of that it's pretty hard to say when linear light should be enabled and when not. So maybe I should remove the option. But which option should I set it to then? Especially with Anime content the difference between linear light and gamma light can be *huge*. Black lines are very noticably fatter when using linear light.

Well, you know that I'd like to avoid that artifical sharpened look that comes with unwanted brightness increase.
I'm not sure if anyone would ever notice that LL thickens dark lines without a direct comparison. This gets worse when increasing the sharpness, but with a sharpness of 2, I think it's not critical.

No chances that a solution can be found which doesn't increase brightness and doesn't boost dark lines at the same time?

Magik Mark
22nd October 2015, 21:47
@Francois76l

Hi, indeed is what I have inputed manually in ReClock because I'm using SVP which takes my 23,976 movie and interpolate frames up to 59.94 (23,976*5 /2) and hence ReClock should just marginally adjust vs my display resolution.

Can u try 29.97. It's a multiple of 59.94. Your cpu by the way may not be powerful enough

Raimu
22nd October 2015, 21:57
Madshi, your speculative fixes for the out-of-order frame flickering have completely eliminated the problem for me when using DX9 new windowed.

It kept happening so much on my PC it completely made the mode unusable. It's completely gone now. Thank you.

madshi
22nd October 2015, 22:15
Currently on 0.89.12. Never experienced a problem anymore after our fixing session.
:)

Only DX11 still doesn't work on my Intel HD 4000. It still has the ugly jumping back and forward. DX11 seems to work properly with the renderer inside KODI Jarvis though (which is of course far less complex).
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.

Kodi Jarvis does everything in DX11, I believe, with no trace of DX9 left. madVR instead still renders most stuff in DX9, just shares the final rendering result with a DX11 device for presentation. I believe this sharing, and maybe the combination with presenting many frames in advance is responsible somehow for this back & forth jumping.

Anyway, you don't lose much by staying with DX9, and DX9 is active by default, so it's not a show stopper, IMHO.

With the latest XySubfilter beta, using SRT. It happens with every video and SRT I play, of course when moving the subtitles to the bottom of the window...
At least some screenshots would be nice, so that I could see what you're talking about.

No menu option at all. Both RS232 and TCPIP are available at all times
Interesting, they must have changed this in the X500+ series.

Yes (as I said).
Yes (as I said).
Yes (as I said).
Yeah yeah. Clarification questions to make sure I understood everything correctly have never harmed yet. It's better to ask one time too much than to draw conclusions based on a misunderstanding.

This is where the result was not as I expected it. Both of them DO work interchangeably for this case.

Could it be that your software turns on the JVC in a different way than I do? Do you do the full handshaking (PJ_OK/PJREQ/PJACK)?
I've very carefully implemented the network protocol according to specification, of course with full handshake and stuff. I've also had this all tested by an X500 user and he had no problems at all.

I'm sending 0x21 0x89 0x01 0x50 0x57 0x31 0x0A (after handshake) to turn the projector on. Do you send something different?

After you've sent your power on command, do you wait for a reply from the projector? (You should.)

BUT, the automated operation is still as before, i.e. VERY intermittent, so it's starting to appear that there's something totally different at work in that case and all the above is just a red herring.
Well, as I said, a logic bug could be involved, too. Can you confirm (once more) that my test tool works perfectly and 100% reliable (!!) if you turn your projector on via remote? And at the same time madVR does *not* work correctly under the same circumstances? If you can confirm that, I'll spend some time to add logging to madVR, so we can see what madVR tried to do (and why), and whether it succeeded or not. Don't want to invest that time before getting 100% confirmation about the test tool working perfectly. Because if the test tool doesn't work perfectly reliable, either, then it's hard to be sure where a specific problem comes from, and logging would not help.

Could I just as well test using a video? I've done this before - looking for the dither noise to vanish. Does it need to be in motion?
I don't fully understand what you mean.

As far as I can tell the only reason gamma light seems to thin black lines is that it makes the image lighter. Admittedly this can look nice for Anime, but it will make white lines look too fat. It's hard too say which is better, but I think using linear light will give a more consistent result. If for example you draw a black line and white line of equal thickness and scale them with SuperRes then I suspect that they will still have equal thickness with linear light but different thickness when you use gamma light, maybe somebody could try this out?
No chances that a solution can be found which doesn't increase brightness and doesn't boost dark lines at the same time?
Maybe we'll need to experiment a little. Doing some more tests to find out whether there are situations where using gamma light is more faithful. E.g. one good test would be to downscale one big ground truth image to 50% by using (a) gamma light and (b) linear light, and then scaling both up again, then applying SuperRes on top. I suppose the image (a) should look better with SuperRes in gamma light, while (b) should look better with SuperRes in linear light. But I might be wrong. Maybe SuperRes linear light will look more faithful to the ground truth in both cases? That would be worth a check...

madshi
22nd October 2015, 22:18
Madshi, your speculative fixes for the out-of-order frame flickering have completely eliminated the problem for me when using DX9 new windowed.

It kept happening so much on my PC it completely made the mode unusable. It's completely gone now. Thank you.
Wow, that's good to hear! :)

aufkrawall
22nd October 2015, 22:54
Maybe we'll need to experiment a little. Doing some more tests to find out whether there are situations where using gamma light is more faithful. E.g. one good test would be to downscale one big ground truth image to 50% by using (a) gamma light and (b) linear light, and then scaling both up again, then applying SuperRes on top. I suppose the image (a) should look better with SuperRes in gamma light, while (b) should look better with SuperRes in linear light. But I might be wrong. Maybe SuperRes linear light will look more faithful to the ground truth in both cases? That would be worth a check...
I did a quick search and found this image:
http://www.shaderhacker.com/wp-content/uploads/2015/01/DyingLightGame-2015-01-29-22-08-39-58.png
It looks extremely different when linear light downscaling is used or not.

DigitalLF
22nd October 2015, 22:59
Ooops, good catch! Here's a fixed madHcCtrl.exe for you:

http://madshi.net/madHcCtrlSony.rar

Does that fix the problem for you? It might also make lens memories work for your Sony.

yes it does! thank you! :)


AR is often not *exactly* one of those numbers. E.g. imagine a Cinemascope Blu-Rays with 1920x796 active pixels. That's an AR of 2.4120603015075376884422110552764. You can't write the script in such a way to handle every possible AR. So instead of using "if AR = something" use "if AR > something". So your script could read:

if (AR > 1.9) "2.40:1" else
if (AR > 1.8) "1.85:1" else "1.77:1"

That said, do you really need different profiles for 1.85:1 and 1.77:1? Your call, though. Personally, with my CIH setup I just have 2 profiles, one for Cinemascope movies, and one for every other AR. So I'm just using "if (AR > 1.9) "21:9" else "16:9"".


Thank you for this! Oh and i meant 1.78:1! Sorry! But it is nice to have one for 1.85:1 at least for me! But thank you for the help with my problems regarding this and scripting! This and the possibility to move subtitles is the best things about MadVR if you don't count the picture aspect!

Only thing missing now would be to be able to move the search bar and OSD into active picture area! and "Go back to 16:9 on exit".

You MadShi are one crazy skilled person and i really want to thank you for all work you have done for all of us! it really means a LOT!!!



I still have one problem that i have a work around for but it would be nice if the problem was not there!

When i start a movie and go into fullscreen mode and exit fullscreen back to window mode and then try to go back into fullscreen mode again the movie plays very wierdly ut stutters until i reopen in the same file in MPC-HC BE is it MadVR or a MPC-HC BE related?

jmonier
23rd October 2015, 00:17
I've very carefully implemented the network protocol according to specification, of course with full handshake and stuff. I've also had this all tested by an X500 user and he had no problems at all.

I'm sending 0x21 0x89 0x01 0x50 0x57 0x31 0x0A (after handshake) to turn the projector on. Do you send something different?

That's exactly what I send

After you've sent your power on command, do you wait for a reply from the projector? (You should.)

My software ALWAYS waits for an acknowledgement before sending the next command in the queue.

Well, as I said, a logic bug could be involved, too. Can you confirm (once more) that my test tool works perfectly and 100% reliable (!!) if you turn your projector on via remote? And at the same time madVR does *not* work correctly under the same circumstances? If you can confirm that, I'll spend some time to add logging to madVR, so we can see what madVR tried to do (and why), and whether it succeeded or not. Don't want to invest that time before getting 100% confirmation about the test tool working perfectly. Because if the test tool doesn't work perfectly reliable, either, then it's hard to be sure where a specific problem comes from, and logging would not help.

Here's what I did:

Shut down everything and unplugged the JVC to reset it. Shut down my control program completely.

Started up everything locally starting with the projector then Denon and finally computer.

Started Zoomplayer (via mouse) then used the keyboard to start a 2.39 video playing. Auto zoom did NOT work and no pause. (At this point madVr should have been the only thing controlling the JVC via TCPIP or RS232 since it was plugged in).

Tried your test program at this point and it did NOT work (reported "emergency" for power state).

Shut down computer, it still did not work.

Shut down Denon and the test program started working.

Powered up Denon and computer, test program still working.

Started up Zoomplayer to the point where the next keystroke would start the video, test program still working.

Started the video, auto zoom did NOT work and no pause.

The test program was still working after this.

Are you confused? I certainly am.

I'd already written a JVC simulator that works 100% with your test tool. It is not connected to the projector, but it does report power on correctly. I've then run my system normally with madVR pointed to the simulator.

What happens is this:

I play a video that should activate a different lens memory so I can be sure that madVR should do something.

The first time I play the video, madVR sends a Power Inquiry (PW) followed by INML2. It also pauses the video, but it never comes out of pause. Is it expecting any response other than an acknowledgement of each command and a Power On response from the inquiry?

If I then stop playback and then restart it, it does nothing (no pause, no PW, no INML2). If I close the player and then restart it, it will work as above once (but only once).

It seems from this that it's expecting some other response that the test tool doesn't check for.

I'm wondering if the only way this will work reliably is if I get the simulator to work correctly with madVR and then use it as an interface between madVR and my JVC control program. What do you think?

agustin9
23rd October 2015, 00:48
At least some screenshots would be nice, so that I could see what you're talking about.
Ok, here they are...

xysubfilter - 0 bottom margin:
http://oi60.tinypic.com/34yw5fd.jpg

internal mpc - 0 bottom margin:
http://oi58.tinypic.com/1530hu1.jpg

xysubfilter - 20 bottom margin:
http://oi61.tinypic.com/av1ua.jpg

internal mpc - 20 bottom margin:
http://oi60.tinypic.com/2mfdj6d.jpg

xysubfilter - 60 bottom margin:
http://oi61.tinypic.com/a9ts1g.jpg

internal mpc - 60 bottom margin:
http://oi59.tinypic.com/2ekj3n9.jpg

On xysubfilter is always at the same position, I even tried some high numbers like 150...

6233638
23rd October 2015, 01:38
When switching from D3D11 windowed to 10-bit FSE mode, I just had a video start flickering frames back-and-forth, which I think is the first time I've seen that happen on Windows 8.1 - at least in recent memory.
Smooth Motion was not on, as the video was 30 fps at 60Hz.
So whatever changed recently does not seem to have fixed it and may in fact have caused this issue to appear on my system.
If nothing else, I can say that it is infrequent as this is the first time that I've seen it happen so far.

I actually have had a number of issues when switching between FSW and FSE modes ever since D3D11 was introduced, which I think I mentioned at the time (black screens, frames dropping until I do another switch between FSW/FSE, exclusive mode failing) but have not had the time to fully investigate them as I have been unable to reliably reproduce any of them.

nijiko
23rd October 2015, 06:58
The problems got pretty severe after 0.88.16 with the introduction of Stop/Pause rendering. DXVA errors, crashes, freezes...

Me too, when use DXVA, pausing or resizing may cause black screen or red screen for a while (a few frame). But it doesn't affect using.

CiNcH
23rd October 2015, 07:56
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.
I am still using Windows 7 (32-Bit) on my TV PC to prevent potential driver issues. Intel GPU drivers I tried several. Currently I am on the latest official one.

I might move to Windows 10 soon though.

dansrfe
23rd October 2015, 08:04
I'm confused by the bar chart comparison between super-xbr and NNEDI3 for chroma upscaling.

It seems as if super-xbr is superior in all parameters and faster compared to NNEDI3. Is this true? Are there other parameters which influence the quality of scaling which are not shown in the chart?

madshi
23rd October 2015, 08:27
I did a quick search and found this image:
http://www.shaderhacker.com/wp-content/uploads/2015/01/DyingLightGame-2015-01-29-22-08-39-58.png
It looks extremely different when linear light downscaling is used or not.
Looks somewhat psychedelic. Might be a test candidate, but I think it would be better to use a screenshot from Mononoke or some other Anime Blu-Ray. And then in addition to that some image where there are also white lines.

Only thing missing now would be to be able to move the search bar and OSD into active picture area!
It's already there! Check the option "move OSD into active video area" in the screen config page. It affects the madVR fullscreen exclusive mode seekbar, and *tries* to move other OSD elements, too. But depending on which media player you're using, it may or may not affect the media player's OSD. If your media player's OSD does not react to this option, please complain to the media player devs. I've written a PDF for them that explains how they can make it work:

http://madshi.net/89notesForDevs.pdf

and "Go back to 16:9 on exit".
Maybe later.

When i start a movie and go into fullscreen mode and exit fullscreen back to window mode and then try to go back into fullscreen mode again the movie plays very wierdly ut stutters until i reopen in the same file in MPC-HC BE is it MadVR or a MPC-HC BE related?
Please create a debug log for this problem. For the debug log, please reproduce this problem, then let it stutter for 20 seconds, then close the media player immediately (Alt+F4) without switching to windowed mode again, or doing anything else.

Here's what I did:

Shut down everything and unplugged the JVC to reset it. Shut down my control program completely.

Started up everything locally starting with the projector then Denon and finally computer.

Started Zoomplayer (via mouse) then used the keyboard to start a 2.39 video playing. Auto zoom did NOT work and no pause. (At this point madVr should have been the only thing controlling the JVC via TCPIP or RS232 since it was plugged in).

Tried your test program at this point and it did NOT work (reported "emergency" for power state).

Shut down computer, it still did not work.

Shut down Denon and the test program started working.

Powered up Denon and computer, test program still working.

Started up Zoomplayer to the point where the next keystroke would start the video, test program still working.

Started the video, auto zoom did NOT work and no pause.

The test program was still working after this.

Are you confused? I certainly am.

I'd already written a JVC simulator that works 100% with your test tool. It is not connected to the projector, but it does report power on correctly. I've then run my system normally with madVR pointed to the simulator.

What happens is this:

I play a video that should activate a different lens memory so I can be sure that madVR should do something.

The first time I play the video, madVR sends a Power Inquiry (PW) followed by INML2. It also pauses the video, but it never comes out of pause. Is it expecting any response other than an acknowledgement of each command and a Power On response from the inquiry?

If I then stop playback and then restart it, it does nothing (no pause, no PW, no INML2). If I close the player and then restart it, it will work as above once (but only once).

It seems from this that it's expecting some other response that the test tool doesn't check for.

I'm wondering if the only way this will work reliably is if I get the simulator to work correctly with madVR and then use it as an interface between madVR and my JVC control program. What do you think?
Thanks!

Writing a simulator sounds like a lot of work. And it would only make it work for you, but not for other X500 users. Still wondering why the other X500 user had no problems at all, though.

Anyway, wouldn't it make more sense to use a network sniffer like e.g. WireShark to compare how our two tools differ? E.g. in the situation in which my tool doesn't work, you could capture my network traffic, and yours. There should be a noticable difference then.

Or we could also exchange source code for the ip config stuff. Maybe you can see something wrong in my code, or I can see something I've missed in your code?

My tool does wait for a reply when changing lens memories. With my X35 this reply comes with many seconds delay, exactly when the activation of the lens memory has completed. This is very nice because it tells me exactly when the lens memory activation has completed. I'm using that to pause and resume video playback at exactly the right times. Works perfectly here. I suppose maybe the X500 behaves differently there? Would be strange, though, the network protocol is pretty clear about what should be sent by either side...

Ok, here they are...

On xysubfilter is always at the same position, I even tried some high numbers like 150...
Ah, thanks, I see what you mean!

The bottom margin option is a private subtitle renderer value which madVR doesn't know about. But the moving of the subtitles is done by madVR, so madVR doesn't use that "bottom margin" option because it doesn't even know it exists, or which value it's set to.

Are you not happy with madVR's positioning? Looking at your screenshots, I think the madVR position is by far the best one. Do you find it too high or too low?

When switching from D3D11 windowed to 10-bit FSE mode, I just had a video start flickering frames back-and-forth, which I think is the first time I've seen that happen on Windows 8.1 - at least in recent memory.
Smooth Motion was not on, as the video was 30 fps at 60Hz.
So whatever changed recently does not seem to have fixed it and may in fact have caused this issue to appear on my system.
If nothing else, I can say that it is infrequent as this is the first time that I've seen it happen so far.

I actually have had a number of issues when switching between FSW and FSE modes ever since D3D11 was introduced, which I think I mentioned at the time (black screens, frames dropping until I do another switch between FSW/FSE, exclusive mode failing) but have not had the time to fully investigate them as I have been unable to reliably reproduce any of them.
If you find a way to reliably reproduce this issue, please let me know.

madshi
23rd October 2015, 08:32
I am still using Windows 7 (32-Bit) on my TV PC to prevent potential driver issues. Intel GPU drivers I tried several. Currently I am on the latest official one.

I might move to Windows 10 soon though.
I'll try the latest driver, maybe I can reproduce it then. I will probably move my dev PC to Windows 10 sooner or later, too.

I'm confused by the bar chart comparison between super-xbr and NNEDI3 for chroma upscaling.

It seems as if super-xbr is superior in all parameters and faster compared to NNEDI3. Is this true? Are there other parameters which influence the quality of scaling which are not shown in the chart?
The size of the "ringing" bar is probably misleading. The difference in ringing is bigger than that bar suggests. Also NNEDI3 produces rather nice thin lines, while super-xbr produces thicker lines, which is not visible in any of the bars. Overall I consider NNEDI3 superior in image quality. Mainly due to lower ringing and producing thinner lines.

ionutm80
23rd October 2015, 09:36
Yeah, this is being reported by several Intel users. Unfortunately my HD4000 doesn't show this problem, for some weird reason. Might depend on the OS and GPU driver, I'm not sure. I'll probably get an Intel laptop sooner or later and hope to be able to reproduce the problem then.



Hi Madshi, can you share with us what are your settings for HD4000 or point me to a thread where you already did that? :)

Thanks a lot in advance.

CiNcH
23rd October 2015, 10:47
I'll try the latest driver, maybe I can reproduce it then. I will probably move my dev PC to Windows 10 sooner or later, too.
I also still have the problem with way higher GPU usage compared to EVR when purely using DXVA and other enhancements disabled (dithering a.s.o.). So something is for sure different.

Do you have Windows 7 on that machine or Windows 8/8.1?