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

webs0r
6th April 2014, 01:18
Here's a new test build:

http://madshi.net/madVRwindowedTest.rar

This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.

Give it a try and let me know how it works for you!

The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.

OK initially I installed this test package over a madVR version slightly older than v0.87.9 and then the player wouldn't connect madVR (fell back to EVR or something).

I installed v0.87.9, then put this package on top and it works.

Not sure if I accidentally did something wrong the first time, but just FYI if anyone has problems initially.

With my testing, the mode works fine, but I'll report some strange behaviour.
Setup: Win7, NV GTX680 user here (v331.65 driver)
Typically I've always been using windowed mode with no flushes, and have no issues.
Queues always full.

With the present frames in advance enabled:
Works fine, but if I obscure a large part of the video playback area with another window (Firefox), or even with madVRs own settings dialog, I notice the present queue drops from full to 1-3/8.
The render queue is affected as well.
It doesn't drop frames, until I moved the obscuring window away - then it starts dropping some frames slowly. The act of moving it away makes the queue state worse!
Pausing the video and unpausing restores all the queues.

I'm doing this with the player window maximised but not fullscreen.

madshi can you reproduce this or would you like logs?

ryrynz
6th April 2014, 01:32
Sounds like the same issue I had. Looked to be chrome which was in the background. I shut it down and queues were good but after restarting the player with chrome still not loaded the queues were low again. Might try disabling desktop composition n see what happens.

Anime Viewer
6th April 2014, 03:30
NNEDI3 doesn't seem to behave well with Smooth Motion enabled.
Without Smooth Motion I could set twice the neurons (ex:32) without dropped frames than I could with it enabled (ex:16).
With them both enabled watching two 720p videos of the same video format (h264,8 bit, 4:2:0-> NV12, 8 bit, 4:2:0) two very different results occurred with one (Akuma no Riddle episode 1) there were no dropped frames, but with the other (One Piece episode 638) it started dropping lots of frames right away.

Watching a 1080p video on my 1920x1080 screen with both NNEDI3 and Smooth Motion enabled it reported dropping lots of frames very quickly (with the movie resolution and target rectangle being identical NNEDI3 chroma upscaling should have been disabled). I changed the NNEDI3 to Jinc (which also should be disabled at that resolution) and the drops completely stopped. (Running with NNEDI3 enabled, and Smooth Motion disabled there were no dropped frames).

huhn
6th April 2014, 03:54
is your one piece ep maybe VFR or straight 29 fps? normally or at least i think one piece needs that. higher FPS = more work.

(with the movie resolution and target rectangle being identical NNEDI3 chroma upscaling should have been disabled)

a 1080p video/BD normally got a chroma resolution of 540p. are you sure nnedi3 wasn't used for chroma?

cyberbeing
6th April 2014, 04:09
Unfortunately, it appears that madVR 0.87.8 introduced a bug with NNEDI3 Chroma Doubling + Smoothmotion. Tested on my GTX 770 with new and old drivers.

Reset madVR to default settings
Enable Smooth Motion
Enable NNEDI3 Luma & Chroma Doubling
Open a small video in MPC-HC which triggers smooth motion (https://www.mediafire.com/?6192wf8w56bwbb7)
Either maximize the MPC-HC window or enter fullscreen
ALT+3 to have MPC-HC zoom to 200%
Result: Black flashing when viewed at 200%


I'll open a new issue on madshi's bug tracker after I wake up tomorrow.

Anime Viewer
6th April 2014, 05:34
is your one piece ep maybe VFR or straight 29 fps? normally or at least i think one piece needs that. higher FPS = more work.

a 1080p video/BD normally got a chroma resolution of 540p. are you sure nnedi3 wasn't used for chroma?

Now that you brought up fps I looked at the two videos from a frame rate comparison the one piece file is a slightly higher frame rate at 29.97 vs 23.97 for riddle.

By VFR you're referring to variable frame rate, correct?

One Piece 638 720p file stats:
Video: MPEG4 Video (H264) 1280x720 29.97fps [V: h264 high L4.0, yuv420p, 1280x720 [default]]
Audio: AAC 44100Hz stereo [A: Japanese [jpn] (aac, 44100 Hz, stereo) [default]]

Riddle 720p file stats:
Video: MPEG4 Video (H264) 1280x720 23.976fps [V: h264 high L4.1, yuv420p, 1280x720 [default]]
Audio: AAC 48000Hz stereo [A: Audio [jpn] (aac, 48000 Hz, stereo) [default]]

I just tossed a 480p One Piece episode 639, and the Smooth Motion NNEDI3 combination couldn't handle that either. (Even when I dropped the NNEDI3 neurons to the minimum 16). Once again the dropped frames was eliminated by either disabling smooth motion or switching to Jinc. Looks like fps may be more of a hindrance then resolution when it comes to what cripples NNEDI3 upscaling. To try to balance out the fps difference I tried using ReCock with both files, but that made it repeat a ton of frames and crippled the sound.

One Piece 639 480p file stats:
Video: MPEG4 Video (H264) 848x480 (247:139) 30.303fps [V: h264 main L3.1, yuv420p, 848x480 [default,forced]]
Audio: AAC 44100Hz stereo [A: aac, 44100 Hz, stereo [default,forced]]

The 1080p video had the following stats (perhaps it being 10-bit as opposed to 8-bit could be an issue):
Video: MPEG4 Video (H264) 1920x1080 23.976fps [V: H.264 (h264 high 10 L5.1, yuv420p10le, 1920x1080) [default]]
Audio: AAC 48000Hz 6ch [A: Japanese 5.1 AAC [jpn] (aac, 48000 Hz, 5.1) [default]]

Might NNEDI3 have a weakness when it comes to handling 10-bit files in perhaps a similar way to how hardware acceleration doesn't work with 10-bit files?



I'm guessing deintFps which is listed as framerate after deinterlacing in the rules coding (http://forum.doom9.org/showthread.php?p=1271417#post1271417) has to do with the videos frame rate as opposed to the displays playback frame rate because I tried to create the rule:

if (deintFps <= 30) "SM on"
else "SM off"

In "SM on" profile I set it to Smooth Motion on
In "SM off" profile I set it to Smooth Motion off
To try to tell it to when playing on a display that is capable of playing at 30 hz or less to turn Smooth Motion on, and that way if it is played on a display of 59hz or 60hz it will run with Smooth Motion off.

masshi is that something you might be able to add coding for some where down the road? (Perhaps call it something like "displayHz"). It might prove useful, and could be used for processing and scaling rules as well...

huhn
6th April 2014, 06:12
are you using ED? ED plus smoothmotion can be hard too.

29 fps is a lot hardwe then 23 fps.
about the 480p are you using nnedi3 with always and quadrupling, or is nnedi3 chroma doubling set to 2x?

what about vram?

10 bit doesn't matter to madvr, madvr stores everything in 16 bit so it real doesn't matter at all.

michkrol
6th April 2014, 09:11
I'm guessing deintFps which is listed as framerate after deinterlacing in the rules coding (http://forum.doom9.org/showthread.php?p=1271417#post1271417) has to do with the videos frame rate as opposed to the displays playback frame rate

Yes, just as it says. After deinterlace means you get 23/24/25fps for progressive and usually double that for interlaced video, so it's the number of frames per second that madVR has to actually process (scale, deband, etc.).

I tried to create the rule:

if (deintFps <= 30) "SM on"
else "SM off"

In "SM on" profile I set it to Smooth Motion on
In "SM off" profile I set it to Smooth Motion off
To try to tell it to when playing on a display that is capable of playing at 30 hz or less to turn Smooth Motion on, and that way if it is played on a display of 59hz or 60hz it will run with Smooth Motion off.

Wouldn't you normally want to disable SM for displays that are capable of running at the movie's framerate and enable it for displays capable of running only at 59/60Hz?

madshi is that something you might be able to add coding for some where down the road? (Perhaps call it something like "displayHz"). It might prove useful, and could be used for processing and scaling rules as well...

It's already there: 'refreshRate' is your current display refresh rate in Hz ;) Take note Windows' 59Hz is actually 59,94..Hz, so you might need to use > or < instead of = to detect it correctly.

--------------

@madshi Maybe it would be possible to add a boolean value for "smoothMotion" to the profiles' auto select rules, so we can easily check whether it's enabled or disabled (same value the OSD displays), especially since you can't (easily) check something like refreshrate/fps = integer, but you get options to only use SM if there would be judder.

StinDaWg
6th April 2014, 13:25
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?

ryrynz
6th April 2014, 13:34
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?

It's not NNEDI 16 neurons that's the issue, it's your card's coil noise. There's nothing you can do really but change the card, preferably a different manufacturer.
Other options include using nail polish or hot glue to fix the problem.

The best thing to do would be to get a recommendation from another user that owns a "quiet" card.

6233638
6th April 2014, 13:35
I'm having a strange issue with NNEDI image doubling on my Sapphire 7770. If set to 16 neurons, it makes my card give off an audible whine or electrical interference noise. It's not the fan, but the chip itself. GPU load is about 60%. With 32 neurons the noise completely goes away, gpu load is 91%. Nothing else makes my card do this, gaming, ect. Only NNEDI 16 neurons. Is there any explanation for this?Sounds like load-induced coil whine.

http://www.youtube.com/watch?v=HP73edpQwgc#t=0m07s

It's not that madVR is causing this to happen, it's just that those specific settings are putting a load on your GPU that happens to have coil whine.

annovif
6th April 2014, 13:45
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray? 270-280-280x-290-290x ? Or do you think i have to buy an nvidia now?

Thank you, Fabio

flashmozzg
6th April 2014, 13:53
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray? 270-280-280x-290-290x ? Or do you think i have to buy an nvidia now?

Thank you, Fabio

By bluray you mean 1080p? And what is your target resolution? If you going to watch it on 1080p display nnedi won't be even used(or needed).

Werewolfy
6th April 2014, 14:09
Here's a new test build:

http://madshi.net/madVRwindowedTest.rar

This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.

Give it a try and let me know how it works for you!

The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.

Overlay mode is broken for me too but the new Windowed mode seems to work just fine, I don't see any issues for now.

StinDaWg
6th April 2014, 14:38
It's not NNEDI 16 neurons that's the issue, it's your card's coil noise. There's nothing you can do really but change the card, preferably a different manufacturer.
Other options include using nail polish or hot glue to fix the problem.

The best thing to do would be to get a recommendation from another user that owns a "quiet" card.
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.

I'm thinking of getting an ASUS DirectCU II model, those as well as MSI TWIN FROZR IV seem to have the lowest noise levels in professional reviews.

QBhd
6th April 2014, 15:19
Loving my ASUS Direct CU II R9 270x... it's very quiet, I have to physically get up from the couch and go over to the PC (it's only about 8' away and in the open) to hear the faintest of fan noise. And I have madVR profiles that push my GPU to over 90% for all video formats I watch.

I will add this disclaimer, it's in a HAF 932 with 3x230mm fans and I also have an H80i sitting on the CPU... so it's a very cool case, but any noise can be easily heard due to it's open design nature.

QB

Anime Viewer
6th April 2014, 17:59
It's already there: 'refreshRate' is your current display refresh rate in Hz ;) Take note Windows' 59Hz is actually 59,94..Hz, so you might need to use > or < instead of = to detect it correctly.


Thanks for pointing that out. Don't know how I missed the "displayMode.x/y, refreshRate display mode information" listing there.

I tried creating the rule:
if (refreshRate <= 31) "SM on"
else "SM off"

with SM on being a profile with Smooth Motion on, and SM off being a profile with Smooth Motion off, but it doesn't seem to work as Smooth Motion never turn on when a video with a frame rate of 29.97 is running on a monitor (tv) that is set to run at 30hz. That makes me think that perhaps I need to include "displayMode.x/y," in the rule. Anyone know what's supposed to replace the ".x/y"?



Wouldn't you normally want to disable SM for displays that are capable of running at the movie's framerate and enable it for displays capable of running only at 59/60Hz?


When Smooth Motion (along with NNEDI3 chroma upscaling) is running on the 59hz/60hz display (notebook screen) it reports dropped frames, but with Smooth Motion off it doesn't. Therefore I thought it would be a good idea to create a profile/rule where it shuts off Smooth Motion when running on the notebook screen, but turns it on when running on the tv screen.


are you using ED? ED plus smoothmotion can be hard too.

29 fps is a lot hardwe then 23 fps.
about the 480p are you using nnedi3 with always and quadrupling, or is nnedi3 chroma doubling set to 2x?

what about vram?

I am running with Error Diffusion - option 1 selected for dithering. I'll experiment with using the two dithering options as opposed to Error Diffusion in combination with SM and NNEDI3 to see if that makes a difference, but if it does I'll probably decide to use Jinc with Smooth Motion on and Error Diffusion on as opposed to NNEDI3 at 16 neurons with Error Diffusion (and/or Smooth Motion) off.

I'm not using any of the NNEDI3 doubling (or quad) features, because as soon as I do (even with chroma upscaling only set to 16 neurons, and Smooth Motion disabled) it drops frames right at the start of playback. That and the general consensus on this board seems to be that its better to use (more noticeable benefits) to use chroma upscaling compared to chroma doubling.

As for VRam my Nvidia GeForce GTX 680M has 12GB VRam (4096 MB GDDR 5 dedicated, and 8137 MB system shared), so I doubt that would be bottle-necking in this situation.

Stereodude
6th April 2014, 19:23
By bluray you mean 1080p? And what is your target resolution? If you going to watch it on 1080p display nnedi won't be even used(or needed).The chroma has to be resized for 1920x1080 playback of FHD content, so that's not entirely true.

Mangix
6th April 2014, 19:28
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.

I'm thinking of getting an ASUS DirectCU II model, those as well as MSI TWIN FROZR IV seem to have the lowest noise levels in professional reviews.

NNEDI3 is implemented through OpenCL which more or less uses the compute units directly. Which kind of means that it's using the GPU in a more direct fashion.

michkrol
6th April 2014, 19:41
It's just weird that only NNEDI 16 does this, regardless of gpu load. Some videos with N16 will stress the card to near 100% and others only 30% and yet both make the card whine/buzz. Switching to 32 or higher stops it every time.

Maybe it's the power state/frequency it's in while NNEDI works? Still, probably not much can be done in software to fix this.

Thanks for pointing that out. Don't know how I missed the "displayMode.x/y, refreshRate display mode information" listing there.

I tried creating the rule:
if (refreshRate <= 31) "SM on"
else "SM off"

with SM on being a profile with Smooth Motion on, and SM off being a profile with Smooth Motion off, but it doesn't seem to work as Smooth Motion never turn on when a video with a frame rate of 29.97 is running on a monitor (tv) that is set to run at 30hz. That makes me think that perhaps I need to include "displayMode.x/y," in the rule. Anyone know what's supposed to replace the ".x/y"?

As for the smooth motion not being enabled, check OSD to see what refresh rate madVR detects, maybe it's close enough to the movie's fps to disable SM, unless you have it set to 'always'. Also check whether correct profile is loaded - after starting playback open settings and see which profile is bolded or just make the "SM on" first by drag&drop.

Your rules should work. For the resolution you use either x or y for horizonal or vertical resolution respectively, so to check if horizontal (x) dimension is 1920 use:
if (displayMode.x = 1920) "fhd tv" else "notebook"

When Smooth Motion (along with NNEDI3 chroma upscaling) is running on the 59hz/60hz display (notebook screen) it reports dropped frames, but with Smooth Motion off it doesn't. Therefore I thought it would be a good idea to create a profile/rule where it shuts off Smooth Motion when running on the notebook screen, but turns it on when running on the tv screen.

Since it's a notebook are you sure it's not throttled for some reason, lowering your performance? Are you sure you're using the nVidia's GPU and not the Intel one or both somehow? Your GPU is quite powerful so it should be able to handle those settings, probably even with screen bigger than 1920x1080.

You can check you GPU usage with GPU-Z (free download) to make sure which GPU is used.

the general consensus on this board seems to be that its better to use (more noticeable benefits) to use chroma upscaling compared to chroma doubling.
Actually it's more like luma doubling > chroma upscaling > chroma doubling, but that's for SD content. You results will vary greatly depending on your source and target resolution (and many other things).
For HD content I personally prefer smooth motion over NNEDI chroma upscaling on my 60Hz display, but I am limited by the performance of my Intel HD4000 right now ;)

madshi
6th April 2014, 20:07
Replies to your posts coming tomorrow. Thanks for the feedback about the test build so far.

Ok, Overlay is broken, please ignore that, that's an easy fix. What I'd like to know is whether the new windowed rendering mode is working better, the same, or worse for you? If it's worse, please be as specific as possible. I'd like to enable the new mode by default for the next build (after doing fixes, if necessary), if it works better for the majority of users (or at least not worse). Rendering times are not un-interesting, but really important is if playback is more reliable/stable with the new mode or not. E.g. Smooth Motion FRC working with the new mode, but stuttering with the old mode is a "good" test result. If the new mode clearly works worse for you, please let me know that, too. I'm mostly interested in playback stability/reliability. Possibly cosmetical problems of the new rendering mode are also worth mentioning, but less important.

aufkrawall
6th April 2014, 21:12
Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.

I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)

trip_let
6th April 2014, 21:37
Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.

I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)

I can't remember using old windowed mode in a while, but the above is about what I've seen too.

Rendering times are pretty much the same after they stabilize between new windowed and FSE.

dansrfe
6th April 2014, 22:49
@madshi

There is an issue with videoLUTs using windowed mode: http://bugs.madshi.net/view.php?id=124

seiyafan
6th April 2014, 23:55
I had a 290x and it could only do 64 neurons doubling from 1080 to 1440, so if you want to do 256 neurons, better wait for 490x, I doubt 390x can even handle it. :D

p.s. or wait till AMD fixed the interop issue.

aufkrawall
7th April 2014, 00:06
How is your GPU usage with NNEDI3 on AMD?
Does it come near to 100% when it's getting to slow?

johnniedoo
7th April 2014, 02:09
I have been updating builds with MPC BE and MADvr on my AMD FX8120 , Sapphire 7950 OC and trying NNEDI3 w/16,32, 64, etc or jinc 3tap to check frame drops and stability for all videos , either virtual dvd iso mpeg2s or streaming videos in many formats. I mostly read posts from nvidia gpu users and get confused as to which features are better for AMD or which just do not work with the catalyst drivers, i am also up to date with the most current CCC driver versions beta release 14.3 as of today.
I just noticed that when i use NNEDI3 with SM enabled i can go up to 128 neurons and notice no frame drops but as soon as i disable SM the frames begin to drop off very quickly. I had to stay with jinc 3tap up till the last MADvr or i got frame drops even with SM enabled. GPU usage is still OK either way.
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch , also temps go up immediately
I keep checking the stats and refresh them after each change in MADvr as I go along to see which will be best and most efficient for my machines and interests. I appreciate all the great information i get from reading these posts only trying to keep track as to what is working or not with AMD vs nvidia gets a bit confusing.
John

seiyafan
7th April 2014, 04:52
Well, because all the movies I watch were about 24 fps, so I need to keep rendering time above approx. 41 ms. But for 60 fps, the frame dropping threshold is 16 ms. I think on my 290x, 16 neurons gets ~30% GPU utilization, however rendering time is above 20 ms (that's with everything in the lowest setting, debanding and ED are disabled and so on), so there is no way not to drop frame no matter what. This is for 1080 to 1440. 720 to 1080 has rendering time in the high 10's.

seiyafan
7th April 2014, 04:55
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch
John

Actually, it's about not seeing things.


p.s. someone told me this earlier, I thought this is a very deep sentence, hence want to share it with you.

markanini
7th April 2014, 05:08
I have been updating builds with MPC BE and MADvr on my AMD FX8120 , Sapphire 7950 OC and trying NNEDI3 w/16,32, 64, etc or jinc 3tap to check frame drops and stability for all videos , either virtual dvd iso mpeg2s or streaming videos in many formats. I mostly read posts from nvidia gpu users and get confused as to which features are better for AMD or which just do not work with the catalyst drivers, i am also up to date with the most current CCC driver versions beta release 14.3 as of today.
I just noticed that when i use NNEDI3 with SM enabled i can go up to 128 neurons and notice no frame drops but as soon as i disable SM the frames begin to drop off very quickly. I had to stay with jinc 3tap up till the last MADvr or i got frame drops even with SM enabled. GPU usage is still OK either way.
I get good playback using Jinc 3tap and do not really notice much benefit to using NNEDI3 with 16 to 128neurons. I tried to use image doubling but that really taxes the gpu up to 100% and do not see any improvement in what i watch , also temps go up immediately
I keep checking the stats and refresh them after each change in MADvr as I go along to see which will be best and most efficient for my machines and interests. I appreciate all the great information i get from reading these posts only trying to keep track as to what is working or not with AMD vs nvidia gets a bit confusing.
John

What's the source resolution and display resolution? If you have you're watching 1080 video on a 1080 display the no scaling is taking place.

Asmodian
7th April 2014, 05:37
There would still be scaling for the chroma unless watching a 4:4:4 or RGB video.

QBhd
7th April 2014, 06:04
One thing I have noticed about trying to tell the differences between algorithms... watching stills/frozen frames/same scene over and over doesn't seem to help. But I DO notice the differences if I watch for extended periods of time. It's more about NOT noticing things.


@seiyafan:

I'm glad my ramblings found an audience :)

QB

leeperry
7th April 2014, 06:44
I'd gladly try the new build but I don't have Aero enabled and AMD GPU's can't do overlay.

How is your GPU usage with NNEDI3 on AMD?
Does it come near to 100% when it's getting too slow?
Yeah, that's also what I was thinking about as it might very well be that the interop lag doesn't matter (all that) much after all..at least with 24<>30fps content. We might be overloading the GPU before the effects of the interop lag would even matter(at least on Haswell 3.0).

madshi
7th April 2014, 09:29
It actually solves my issues, wonderful. It brings (me) better performances than FSE while suppressing the UI lag.
Cool. How does it compare to the old windowed mode?

Madshi, any idea's what might be hampering FSE mode in comparison to the new windowed mode at least in John's case?
There has been a number of posts between John and me about his madVR problems in this thread. If you want to know that, just look back and read them.

regular Windowed Mode seems to be working fine.

It did not solve the issue I had where certain things changing the video LUT during playback (e.g. f.lux (http://justgetflux.com/) set to a 60 minute transition) would cause it to drop frames though, which only FSE manages to avoid.
Ok. So basically you don't see any difference worth mentioning between old and new windowed mode?

Btw, please check the bug tracker, it's waiting for your feedback. Don't you get email notifications from the tracker?

the new windowed mode in full screen on my HD4000/Windows 7 PC using MPC-BE, there's lowish render and present queues (f.lux disabled) 2 or 3-4/8 and 5-6/8, simply pausing video and pressing play brings them both up to 7-8/8 where they remain rock solid.
Strange, I don't see that here. What happens if you increase the GPU queue sizes?

Is it normal that the queues get reloaded when going from windowed to full screen windowed mode?
Yes.

Is there any way you could recompile it with a less exotic VC++ runtime please?
The tool wasn't really meant for users, it was meant for AMD support.

I works, even better than the regular windowed mode, and faster.
Better how?

Very good job. On my system, the new windowed mode is definitely faster. Watching a 720p 23.976fps movie I get an average of 0.06ms and max stats 0.09ms with the new windowed mode path. After enabling (and restarting the player and the movie to make it comparable) the old windowed mode I get present times of 0.10ms and 0.11/0.12ms. Nice improvement. Stats also seem more stable, but don't take that as granted, just an observation by looking at the stats for several seconds.
Ok, thx. From what you're writing it seems the old windowed mode worked just fine for you, too, without any frame drops or other glitches? So you can only see an improvement in the OSD stats?

There seems to be a bug when disabling and re-enabling the "present several frames in advance" checkbox. At least on my system the renderer comes to a complete halt and only shows a still picture and video doesn't advance anymore (even though audio continues in the background). That's 100% reproducible, tried MPC-HC and PotPlayer.
Does this happen both when disabling and enabling that option? Or only when enabling the checkbox?

smooth motion seems to like this new windowed mode better than the old one on my Intel HD4000. I used to get some kind of judder in windowed (with SM), that's gone with the new mode. [...] Overall it works as good or better than the old mode for me.
Great - that's what I wanted to hear! I know several users had problems with smooth motion with the old windowed mode.

New windowed test works fine here. I still need to use FSE though, since sometimes the desktop composition stays stuck in a previous Hz which causes massive frame drops.
You could probably fix this by upgrading to Windows 8.

@madshi. On the new test build, i get the message "madvr reports: -creating Direct3D device failed (8876086c)"when i enable windowed overlay. I'm running windows 8.1 x64 with a i5-3470 and a gtx 660 with 8gb RAM.
It's a test build for windowed mode, so it doesn't matter much whether overlay mode is broken or not. I'm interested in how the old vs new windowed mode compares for you?

When switching off overlay, it works but with vsync issues, which I didn't notice in the latest stable release.
Which OS are you using? Aero enabled or disabled? Can you describe the vsync issues you're having? You mean you have tearing? Or do you mean something else? And do these issues go away if you disable the "present several frames in advance" option in the madVR windowed mode settings section?

Is it possible to create a profil in madvr that takes the bit rate of the video in consideration?
No, because madVR doesn't know the bitrate.

New windowed mode works well here with every sample I got. I will definitely keep using it as long as no issues appear.
Does it work better than the old mode?

Visually unpleasing black flashes with madVRwindowedTest when resizing the video window, though I guess something like that is necessary side-effect of presenting in advance? If you could somehow mask what I assume is madVR flushing the present queue on resize, that would be nice.
Tried, but failed. At this point I don't think I can fix that, unfortunately. But I don't find it too much of a problem, to be honest. I think the Overlay resizing artifacts (although improved in recent builds) are uglier...

Same results as everyone else with the new test build, overlay broken but presenting frames in advance window mode finally 0 dropped frames over a 42 minute episode, never seen that before. Madvr was also using ivtc with 0 cadence breaks which is more impressive.
Cadence breaks should not depend on the presentation mode (old vs new windowed mode), I think. Have you been using windowed mode in the past? You're not using FSE mode? And your impression is that the new windowed mode works better, correct?

Desktop Composition was quite improved with Windows 8, I've personally encountered quite a few issues with the Windows 7 composition mode (which can be solved by restarting the compositor) that just went away when testing on Windows 8 instead.
Yes, I'm seeing the same thing here. Basically desktop composition seems to work exactly as it's supposed to work in Windows 8 which wasn't always the case in Windows 7. When I originally heard that desktop composition couldn't be disabled in Windows 8, anymore, I was seriously annoyed. Not so, anymore. I never felt any need for disabling desktop composition in Windows 8 yet.

So far its worked well in my testing on single screens, and when displaying on multiple monitors (notebook screen and tv) if I use an HDMI cable directly between them.
Similar to the old windowed mode or better than the old mode?

However when I try to use Intel Widi/Miracast it drops frames quite quickly in both extend and duplicate modes whenever its set to present frames in advance (regardless of if its one or sixteen). I'll continue to experiment, and see if I can find a workaround for Widi/Miracast that doesn't involve shutting off the presenting frames in advance feature. Edit: Duplicate mode starts dropping them right at the start of the video, but Extend mode seems to go just short of 1 minute before it starts dropping frames.

(I was hoping the frames in advance feature might eliminate the issue of tearing on secondary monitors when using duplicate mode when using direct HDMI cables, but it looks like it unfortunately still exists).
These issues are probably not fixable from my side of things.

Using windows 8.1, I seem to be getting slightly better performance than FSE mode with this build! Although, only marginally better by .20-40 ms.

Checking and unchecking 'use a separate device for presentation' didn't seem to affect performance either way, so leaving that disabled.

Bumped windowed mode 'frames in advance' to 16, so queues are respectfully 24/20/16. Queues remained full, didn't receive any dropped frames except when starting the playback and going fullscreen.

I didn't notice any visual glitches with smooth motion enabled. I'm loving the new build and windowed mode, just for the performance and a responsive seek bar!
Sounds good. But how does it compare to the old windowed mode? That's the key question for me.

Is there any specific advantage to FSE that it should be used instead of windowed mode? I also do not have 'windowed overlay' enabled. Is there any advantage to enabling that option?
FSE mode should bring even more reliability and protection from frame drops. But if you have perfect playback with windowed mode, there's no need for FSE mode, really, at least not atm. Overlay is just another rendering mode, which has advantages and disadvantages. Again: If you have perfect playback with windowed mode, no need to use anything else.

@madshi: With new windowed mode, either with SM FRC enabled or disabled madVR draw 60fps. I guess it's expected? Before without SM it was just drawing at movie framerat IIRC.
Yes, with the new windowed mode, madVR presents 60fps. It only renders as many frames as necessary, though, so rendering performance shouldn't suffer (much). So e.g. with 24fps@60Hz with SM FRC turned off, madVR renders 24fps but presents 60fps, which means that some rendered frames may be presented multiple times. The "present several frames in advance" feature requires madVR to do one D3D9->Present() call per VSync refresh rate. Both in windowed and FSE mode.

With my testing, the mode works fine, but I'll report some strange behaviour.
Setup: Win7, NV GTX680 user here (v331.65 driver)
Typically I've always been using windowed mode with no flushes, and have no issues.
Queues always full.

With the present frames in advance enabled:
Works fine, but if I obscure a large part of the video playback area with another window (Firefox), or even with madVRs own settings dialog, I notice the present queue drops from full to 1-3/8.
The render queue is affected as well.
It doesn't drop frames, until I moved the obscuring window away - then it starts dropping some frames slowly. The act of moving it away makes the queue state worse!
Pausing the video and unpausing restores all the queues.
I can't reproduce this problem with my AMD. Haven't tested Intel and nVidia yet.

Could this be Windows 7 specific? Does everyone who uses Windows 7 have the same problem?

Sounds like the same issue I had. Looked to be chrome which was in the background. I shut it down and queues were good but after restarting the player with chrome still not loaded the queues were low again. Might try disabling desktop composition n see what happens.
If you disable desktop composition the new windowed mode will be disabled by madVR, too. It requires desktop composition.

Maybe it would be possible to add a boolean value for "smoothMotion" to the profiles' auto select rules, so we can easily check whether it's enabled or disabled
Possible, but I'm a bit afraid of profiles influencing each other. E.g. one rule set activating smooth motion FRC, another rule set reacting to that and turning something else off, which could again result in SM FRC being turned off, which then [...]. In theory this could result in profiles constantly switching back and forth all the time.

What purpose would you use a "smoothMotion" boolean value for? Which other settings would you change if that value is true or false? The performance hit of smoothMotion FRC is not *that* big, so I wonder if such a profile boolean is really of any practical use.

Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray?
For chroma upsampling or luma doubling or what? In any case, I'm not sure if any of today's GPUs can do that. NNEDI3 performance is more or less proportional to the neuron count. Which means that 256 neurons cost almost 16x as much performance as 16 neurons. Maybe for chroma upscaling 256 neurons could work with the fastest of today's GPUs, but I've not tested it, so I'm not sure. I don't think the benefit is high enough for chroma upscaling. I think 32 or 64 neurons is the max that is useful for chroma upscaling. But that's just my personal opinion, of course.

the new Windowed mode seems to work just fine, I don't see any issues for now.
Do you see any improvements over the old mode? Or do both work equally fine for you with no differences worth mentioning?

Results of new windowed mode seem totally comparable to FSE for me.
I have pretty much the same GPU usage with both, old windowed mode uses less ressources (since there are no frames rendered ahead, I guess).
No problems with FRC, NNEDI3 etc. with new windowed mode.

I was hoping for a better seekbar in FSE, but now this is redundant with new windowed mode. :)
So you're saying the old windowed mode used less resources. Which means is worked better for you?

I'm not sure why so many users report overlay issues or compare to FSE mode. The key question is: Is the new windowed mode better than the old windowed one? Or is it identical or worse? Everything else doesn't matter.

I can't remember using old windowed mode in a while, but the above is about what I've seen too.

Rendering times are pretty much the same after they stabilize between new windowed and FSE.
How does the old windowed mode compare to the new one on your PC? That's the one and only thing I would like to know.

@madshi

There is an issue with videoLUTs using windowed mode: http://bugs.madshi.net/view.php?id=124
Yes, I know. I get email notifications about every single change in the bug tracker, there's no need for you to post links to it here.

However, are you aware that you have 3 open bugs in the bug tracker which wait for a reply from you?

6233638
7th April 2014, 09:39
Ok. So basically you don't see any difference worth mentioning between old and new windowed mode?I don't, but I haven't noticed any problems with it either - though I haven't actually compared rendering times.

Btw, please check the bug tracker, it's waiting for your feedback. Don't you get email notifications from the tracker?I uploaded a new set of logs yesterday.

madshi
7th April 2014, 09:41
I uploaded a new set of logs yesterday.
Oh, missed that, thanks.

michkrol
7th April 2014, 10:21
What purpose would you use a "smoothMotion" boolean value for? Which other settings would you change if that value is true or false? The performance hit of smoothMotion FRC is not *that* big, so I wonder if such a profile boolean is really of any practical use.

I wanted to have error diffusion on my Intel HD4000, as it can barely manage it, but it looks like I'd need to sacrifice scaling quality in addition to smooth motion for this to work, so it's a no-go anyway.
Turns out I also get some random tearing-like artifacts every few seconds with error diffusion, but that's probably because of the GPU/memory being oversaturated, so I don't consider it as a bug and won't pursue this farther. It's high time I've gotten a "real" GPU it seems.

As always, thanks for your hard work and dedication.

ryrynz
7th April 2014, 10:34
Strange, I don't see that here. What happens if you increase the GPU queue sizes?


Doesn't change a thing. I found disabling desktop composition also disables the new path. No problems with the queues in FSE mode.

When I play in full screen windowed the render queue just sits on 1-3/16 as soon I pause the render queue jumps up to 0-16/16, then after pressing play, the queues just fill up normally.

madshi
7th April 2014, 10:43
When I play in full screen windowed the render queue just sits on 1-3/16 as soon I pause the render queue jumps up to 0-16/16, then after pressing play, the queues just fill up normally.
Can I please have a log from this? Let it play for 10 seconds with 1-3/16, then pause, then let it play until the queues are full. Then close. Thanks.

madshi
7th April 2014, 10:58
Here's a new test build with fixed Overlay and one very small presentation improvement for the new windowed mode:

http://madshi.net/madVRwindowedTest2.rar

@ryrynz, does this one fix the problem? If not, please create a log, as described above, thanks.

John Carmack
7th April 2014, 11:01
Cool. How does it compare to the old windowed mode?

See for yourself:

http://t.imgbox.com/eSpyFVqf.jpg (http://imgbox.com/eSpyFVqf)

Siso
7th April 2014, 11:02
Regarding the new windowed mode, the render queue, goes up and down something like if it is set to 5-6, it goes 4-6, every 3-4 seconds, with the old windowed mode it doesn't happen. The rendering times are very close to FSE :)
Just saw the new build, with the new test build2 render queue is stable here, getting one presentation glitch around 1 min after playback tho, sometimes goin' in fullscreen results in 2-6 presentation glitches.

ryrynz
7th April 2014, 11:19
@ryrynz, does this one fix the problem? If not, please create a log, as described above, thanks.

Fixed. :)

nikola
7th April 2014, 12:59
Which OS are you using? Aero enabled or disabled? Can you describe the vsync issues you're having? You mean you have tearing? Or do you mean something else? And do these issues go away if you disable the "present several frames in advance" option in the madVR windowed mode settings section?

Windows 7. Aero enabled. Tearing, yes. Haven't tested disabling that option, but I'm happy to report that with the latest test release it's working correctly, no tearing, both in overlay and non-overlay mode.

Another question: On madshi.net, do you happen to host a text file with just the latest non-test release version number in it? If not, may I ask if it's possible that you place it somewhere? e.g. http://madshi.net/madvr-version.txt

Anime Viewer
7th April 2014, 14:14
As for the smooth motion not being enabled, check OSD to see what refresh rate madVR detects, maybe it's close enough to the movie's fps to disable SM, unless you have it set to 'always'. Also check whether correct profile is loaded - after starting playback open settings and see which profile is bolded or just make the "SM on" first by drag&drop.

Your rules should work. For the resolution you use either x or y for horizonal or vertical resolution respectively, so to check if horizontal (x) dimension is 1920 use:
if (displayMode.x = 1920) "fhd tv" else "notebook"

Since it's a notebook are you sure it's not throttled for some reason, lowering your performance? Are you sure you're using the nVidia's GPU and not the Intel one or both somehow? Your GPU is quite powerful so it should be able to handle those settings, probably even with screen bigger than 1920x1080.

Actually it's more like luma doubling > chroma upscaling > chroma doubling, but that's for SD content. You results will vary greatly depending on your source and target resolution (and many other things).
For HD content I personally prefer smooth motion over NNEDI chroma upscaling on my 60Hz display, but I am limited by the performance of my Intel HD4000 right now ;)

I'll do some experimenting with luma doubling with SD content later, and see how noticable it is to me. Perhaps I'll test with a combination of NNEDI3 doubling and Jinc for the upscaling in SD content (if that sort of combination functions), and see how well that works compared to NNEDI3 for all three.

The rules was working as confirmed by what was bold in madVR's settings while the video was playing. Initially it was set to use only if there would be jitter without it, but I changed that to the "of if it is an exact match for the display rate" option. Odd thing was even with that checked it didn't turn on, and in the OSD for the video I was testing it reported the display 23.97207 and the movie 23.976 I'm not sure why it wasn't turning it on there. I could force it on with the "always" checked, but it madVR doesn't think it needs to be on then I'll trust its judgment. There is no benefit to forcing it "always" on, correct?

Another slightly odd thing was that that was with the direct HDMI cable connecting the notebook. When I used Intel Widi/Miracast instead of the direct HDMI with the same madVR settings, and the same video it turned Smooth Motion on.

I'm 99% sure its using the Nvidia GPU because both because its set in Nvidia control panel for the renamed mpc-hc2.exe, and because of the forced registry string madasi had me put it in registry and its results compared to when the Intel is forced in the registry. Power settings are at maximum performance while plugged in, so its not throttling the GPU there.
I'll try testing with GPU-z later.




Similar to the old windowed mode or better than the old mode?


These issues are probably not fixable from my side of things.



I vote for better than the old mode. While it reported dropping ~10 frames per second with the Intel Widi/Mircast mode I didn't see (or hear) any issues while watching (aside from glitches that have always existed with WiDi/Miracast and have as far as I know nothing to do with madvr or mpc). I suspect I don't see any issue even though its dropping frames thanks to the 16 frames in advance setting. I suspect the 16 frames in advance is canceling out the 10 dropped frames either that, or the reports of dropped frames is incorrect. Regardless it doesn't matter its not something I expected to be fixable from your end. I prefer to use a direct HDMI cable from the notebook as opposed to the Widi/Miracast when watching videos, and don't run with the widi unless I want to run run a game in duplicated mode (because the widi duplicate doesn't show taring which normally occurs when systems are running in duplicate mode with straight HDMI).

I haven't tested the new Test2 windowed mode, but I will after work today, and if I feel there is anything worth mentioning I'll do so then.

dansrfe
7th April 2014, 17:29
Yes, I know. I get email notifications about every single change in the bug tracker, there's no need for you to post links to it here.

However, are you aware that you have 3 open bugs in the bug tracker which wait for a reply from you?

My apologies. :o I've replied to the 3 other bugs.

MokrySedeS
7th April 2014, 17:49
Old path never caused me any problems so all I can compare is performance.
With smooth motion disabled, new path is slightly faster, but with SM enabled is a lot slower. OSD comparison here: http://i61.tinypic.com/2qjkbhu.png

But then again my gpu is so crappy that I have to dumb madVR down pretty much all the way to get smooth playback (bilinear resizing, all trade quality options enabled and even dithering has to be disabled...)
Radeon 3000 with 512MB ram on Windows 8.1...
I'll test again when I'll get back my gtx650ti (probably tomorrow).

annovif
7th April 2014, 18:06
Quote:
Originally Posted by annovif View Post
Hello everybody, can i know what kind of ATI i have to buy to set Needi 3 256 neurons with bluray?
For chroma upsampling or luma doubling or what? In any case, I'm not sure if any of today's GPUs can do that. NNEDI3 performance is more or less proportional to the neuron count. Which means that 256 neurons cost almost 16x as much performance as 16 neurons. Maybe for chroma upscaling 256 neurons could work with the fastest of today's GPUs, but I've not tested it, so I'm not sure. I don't think the benefit is high enough for chroma upscaling. I think 32 or 64 neurons is the max that is useful for chroma upscaling. But that's just my personal opinion, of course.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
I intended chroma upsampling bluray 23.976 over 1080p display . I hoped that 280x was good enough, but now i am not so sure. Thank you

mark0077
7th April 2014, 18:55
madshi, testing the new windowed mode on my machine with Nvidia GTX295 / Windows 8.1 and I notice a nice improvement in windowed mode. You might remember this bug http://bugs.madshi.net/view.php?id=153 where frames dropped on the first subtitle appearance in windowed mode. I got around it and saw 0 drops by using overlay mode but now I can also get 0 drops using the new windowed mode (although the queues do still take quite a drop :) ). So definitely an improvement over the old windowed mode, 0 drops.

One tiny issue I'm sure you'll solve before the final release. When testing with the new "windowed mode" -> "present several frames in advance" disabled. If I enable it mid playback and hit OK, the image freezes.

sandman7920
7th April 2014, 20:53
Is it possible for madVR to report Content Type to Display.
Movie, General, Game etc.

My tv support auto scene with option auto+24hz synchronization for cinema mode (madVR display mode switch 1080p24), but if video >24 in windowed mode tv stay in Desktop mode and in FSE switch to game mode.

P.S.
Sorry for my poor English