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

Grmpf
3rd January 2011, 09:07
I'm a bit confused by this statement. Isn't a madVR reported refresh rate of 95.90409 a perfect match for 23.976 video? You can't get any more perfect then that, yet it still reports frame repeats every few minutes. Is this being caused by clock deviation alone? If so, what could I do to fix it without using Reclock?

Hello cyberbeing, take a look into this website (autotranslated from german) (http://translate.google.de/translate?hl=de&sl=de&tl=en&u=http%3A%2F%2Fwww.d65.de%2Fwiki%2FHTPC_Bildfrequenz_Optimierung), there is a script (phyton, from the author of eventghost) to download and used together with a movie + using dts/ac pakets (passthrough) to get a count of pakets lost/repeated and calculate the best matching refreshrate for your graphicscard (works only with powerstrip useable cards - ati 5xxx i think will work) by adjusting front/back porches/etc. to get a much better matching result than just setting your refreshrate inside your driver to a multiple of 23.976hz...

madvr
3rd January 2011, 14:04
Grabbed a 200px square with top-left corner (400,100) in all 3 pics, labeled correctly. Contrasted it so that a 5.3bit dithered peon like myself can see the difference between images.

http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6t.jpg (http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6.png)

It looks like SmoothL actually under-dithers. Zooming in, it also seems to use sort of a diamond dithering pattern. Maybe its the noise generated from madvr's dithering thats bothering you?

... I think the smoothL one looks better than the madVr one. Whether it would make much difference in an actual movie, I don't know.
But I dont suppose the smoothL coder is going to donate his code to madshi...

leeperry
3rd January 2011, 15:13
I think the smoothL one looks better than the madVr one.
Even Stevie Wonder can see that SmoothL is "smoother", but madshi might say that it overdithers and "blurs" vital informations...time will tell.

BTW, I can confirm that my lockups w/ CoreAVC CUDA seem to be over...it was most likely due to my overclocking, as increasing the MCH voltage one notch seems to have straightened things out.

gliderzone
3rd January 2011, 15:25
Hi,

I have a minor bug to report, as well as a question, as follows.

1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)

2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...? I like the card since it's passively cooled (no fan), but I have noticed some issues that might be related to the card cannot handle the load when using madVR. I would like to get this confirmed, and if the card is to weak for madVR, what would you recommend as a replacement...? ATI or nVidia, is there maybe some passively cooled card powerful enough?

madvr
3rd January 2011, 15:32
2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...? I like the card since it's passively cooled (no fan), but I have noticed some issues that might be related to the card cannot handle the load when using madVR. I would like to get this confirmed, and if the card is to weak for madVR, what would you recommend as a replacement...? ATI or nVidia, is there maybe some passively cooled card powerful enough?

I too had a HD4550 before my current card. It was fine unless I set everything to Lanczos - -which you wouldnt anyway... You may find it gets a bit too hot though and needs a fan placing against it! Just keep an eye on its temp in CCC.

pie1394
3rd January 2011, 15:36
On my 20" Samsung 203B TN monitor, it shows the same result just like what scoz saw.

madVR dithering is smoother and less obvious visual banding regardless which brightness area. But madVR dithering is a little bit noisier at some places than smoothL dithering.

I guess I will not see any difference between them except to the sharpness on my 42" PDP TV from 2.8 meter away.

leeperry
3rd January 2011, 17:09
ok, fair enough! It boils down to your display and how its internal dithering is implemented, as expected.

and I wasn't trolling when I said that many LCD panels were 6bit: http://www.widescreengamingforum.com/forum/viewtopic.php?p=121750
All 20" and 19"s with TN panel are 6bit, just like all 22"s with TN panel.
reason why it's so handy to be able to finetune your media player dithering, in order to output the subjectively nicest picture to the end-user IMHO http://forum.slysoft.com/images/smilies/agreed.gif

robpdotcom
3rd January 2011, 17:37
1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)

I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.

Press CTRL-J to bring up the OSD, it will say there if you are in windowed or exclusive mode.

madshi
3rd January 2011, 17:40
Personally, Iīve never encountered any of this. I have absolutely no delay at all, when I press "edit madVR settings" either for the first time or about a dozen times in a row and close the dialog afterwards. To be sure about that, I just tried to open/close the dialog about a 100 times, and as fast as I am able to click on it. The dialog opens and can be closed instantly without any delay.
Yeah, it's the same for me. I can't reproduce any problems.

It's happening again...

Log 1: I've opened a mkv file and after playing start I've picked MPC-HC's window title bar and moved the window quickly in several circle movements (clockwise and counter-clockwise). Then, I've right clicked on the window for opening the properties dialog and when clicking the edit settings button the error message appeared.

I had another problem with madVR, a very annoying one. Whenever I opened it to watch any movie its response was very sluggish. Sometimes I had to wait several seconds just when trying to move the player's window, or when right clicking for the properties dialog. I've decided to try a clean install, so I uninstalled it and deleted madVR dir, and reinstalled it. Now it seems to be better, but sometimes the sluggish still happens. Log 2 was made with the sluggish in action. Any clues why this happens? With any other renderer it works fine, this only happens with madVR.

I'm using Win7 x64, MPC-HC v1.4.2808, and ffdshow 3712 (happens with other decoders too).

Edit: I also have a ~2 seconds delay between clicking the edit settings button and the dialog showing up. I can live with that, but would be happier without it... ;)
The logs don't help much with any problems related to opening the settings dialog, because the settings dialog itself doesn't log anything (it's even a different process).

From the log I can see that there's a 2 second delay everytime madVR starts up. But the delay doesn't seem to be caused by madVR. I just see a 2 second gap in the log with no explanation where it could be coming from.

Yeah I meant 0.36 sorry. In windowed mode it is totally fine, the issue is only from fullscreen exlusive. Although when going into fullscreen exclusive and back to windowed, the windowed mode is also messed up.

Im unsure how to run windowed mode in fullscreen without activating exclusive , to test that.

Edit: Just checked with ZoomPlayer, issue is the exact same, fine in windowed or with crossfire disabled, but when enabled in fullscreen exlusive, a jittery mess. Also figured out how to get into fullscreen without exclusive mode, and it is also fine, just like windowed.
I would guess the current multi threaded exclusive mode rendering confuses the crossfire logic, so you simply can't use it for now. Might be fixed by a future madVR version. You can disable the exclusive mode in the madVR settings dialog.

Choosing an algorithm that matches chroma resolution to luma resolution well to avoid colour bleeding, and choosing an algorithm that does not desaturate chroma should be your main priority.
You're forgetting to mention that it's also very important to choose an algorithm which works around chroma aliasing.

I've also noticed a problem where madVR Exclusive Mode seems to be hanging MPC-HC in the taskbar when I right-click (which reverts to Windowed) and close MPC-HC when in fullscreen, if I don't have the 'wait 3 seconds' setting enabled. Is there anyway to fix this without using that '3 second' option?
I'm well aware that disabling the "3 second" option can make problems. Originally this option didn't even exist and they was always a 3 second delay. I've implemented the option on request. Maybe I should add a warning like "use on your own risk".

I think the bug where madVR gets out of sync if you leave the video paused for an extended period of time still exists as well. I've seen this happen occasionally on both computers.
Can anybody confirm this? I've not seen it on my PC, I think. If anybody can reproduce this, a log would be helpful.

I'll be really glad if you look into it.
Ok, will do.

alright, Kazuya has been kind enough to encode a 16-235 black>white gradient in YV12 h264...available here: Banding_720p.rec709.mkv (http://www.mediafire.com/?to56a070x43dskn)
Why didn't you simply use the madTestPatternSource shipping with madVR? :)

2)-the default dithering strength(50) in SmoothL provides smoother gradients than the default dithering in mVR...call if oversmoothing if you like, but it does look "smoother" and does provide a more enjoyable PQ IME(and others). Besides LaTo claims that it doesn't deband per se, it only smooths the TV>PC conversion.
Ok, from what I can see, LaTo uses Floyd Steinberg dithering, or some variation of it. madVR uses random dithering. With low bitdepths (e.g. 1 bit), Floyd Steinberg looks noticeably better. But the higher the bitdepth, the lower the advantage. With 8bit, the difference is almost not noticeable to the naked eye, without zooming in. When zooming in, you'll notice that madVR adds random noise, while Floyd Steinberg has a more geometrical dithering pattern.

I would offer a Floyd Steinberg or similar dithering algorithm in madVR if it was technically possible, but the pixel shader architecture doesn't really allow it.

There's one thing to note, though: The best solution is always to maintain the highest possible bitdepth throughout the whole processing chain and do the dithering step only at the very end. So ideally it should be something like this:

(1) 8bit YCbCr 4:2:0 source
(2) convert to 16bit+ YCbCr 4:4:4
(3) convert to 16bit+ RGB
(4) scale in 16bit+
(5) adjust gamma and levels (video -> PC) in 16bit+
(6) correct color in 16bit+
(7) adjust brightness, contrast, saturation, hue etc in 16bit+
(8) dither down to final output bitdepth

This is exactly what madVR is doing. However, with SmoothL the situation is different. You have the following processing chain, I would guess?

(1) 8bit YCbCr 4:2:0 source
(2) convert to 8bit YCbCr 4:4:4
(3) convert to 8bit RGB
(4) scale in 8bit
(5) correct color in 8bit
(6) SmoothL 8bit input, internally higher bitdepth, output dithered 8bit
(7) adjust brightness, contrast, saturation, hue etc in 8bit

Can you see the problem? All the steps are done in 8bit, so you're summing up rounding errors in every step. Just imagine you change brightness or contrast after SmoothL, and the whole nicely dithered SmoothL output will be damaged again. Or if you feed the SmoothL output into a 3dlut, the 3dlut output will need to be dithered once more. Or if you scale the SmoothL within madVR, again the output needs to be dithered. And adding two dithering operations on top of each other isn't the best solution.

I still would enjoy the ability to tweak the dithering strength in mVR if any possible, I hope this will be considered.
I don't think the strength has anything to do with it. It's Floyd Steinberg vs. random dithering. They look slightly different. My personal opinion is that the difference is very small, though. I'm not even sure which one is "better". As you've seen the opinions in this thread vary.

Using MPC-HC (tried several versions) and the Cyberlink Video Decoder results in a green video.
It doesn't seem to happen on my PC with the Cyberlink Decoder version I've installed and with one MPEG2 MKV I've tried. Does it happen for you with *every* MPEG2 video? Or just with some?

1) full screen exclusive is much slower than windowed mode. I have to turn it off to avoid stuttering. I thought FSE should provide better performance. Rendering times go from ~30-35 to ~45 ms and that causes stuttering on 1080p 24Hz (23.971xxx Hz reported by CRTL+J) TV.
Try replacing all "flush & wait" settings with "flush" only. Does that help?

2) 1 frame repeat is listed as every couple of minutes. If I use ReClock it improves to more than 4 hours, but that introduces regular stutter every few seconds. ReClock is green, madVR CTRL+J shows good values, but this phantom stutter appears and I have no idea what causes it. I have to remove ReClock but then get the 1 frame repeat every 3-4 minutes. Any ideas why the regular hiccup occurs.
Not sure why you get problems with ReClock. Try cleaning up the Reclock timing database. That has helped some people in the past.

1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)
Ok, I'll see if I can reproduce that.

2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...?
It should be powerful enough if you're satisfied with maybe not being able to use the latest and most consuming algorithms etc.

leeperry
3rd January 2011, 18:15
Why didn't you simply use the madTestPatternSource shipping with madVR? :)
I wanted to test as much as possible as in real world conditions...going through CoreAVC CUDA and all.

With 8bit, the difference is almost not noticeable to the naked eye, without zooming in.
The diff is truly a night and day on my CRT(plugged in 30bit VGA), of course I would guess that this would change -for the worse- on a 6bit LCD. I haven't tried on my Darkchip3 DLP(12bit processing) yet, but I'd expect the same very visible improvement. It's sad that those cheapo LCD panels seem to dumb things down, like all those terribly blurry "Cleartype" fonts in Vista/7...this looks horrid on CRT/DLP :(

I would offer a Floyd Steinberg or similar dithering algorithm in madVR if it was technically possible, but the pixel shader architecture doesn't really allow it.
Oh yah, choosing the dither algorithm/strength would be really sweet! possibly using a built-in quick calibration helper...like a "which one looks better? 1/2/3" a few times, to choose the noise pattern and strength http://forum-images.hardware.fr/images/perso/neuf.gif

There's one thing to note, though: The best solution is always to maintain the highest possible bitdepth throughout the whole processing chain and do the dithering step only at the very end.[..]

Can you see the problem? All the steps are done in 8bit, so you're summing up rounding errors in every step. Just imagine you change brightness or contrast after SmoothL, and the whole nicely dithered SmoothL output will be damaged again. Or if you feed the SmoothL output into a 3dlut, the 3dlut output will need to be dithered once more. Or if you scale the SmoothL within madVR, again the output needs to be dithered. And adding two dithering operations on top of each other isn't the best solution.
Yes, you're entirely right...but the SmoothL/mVR gradients are really a night and day on my CRT...post-processing sharpening and so on SmoothL's output provides a much more natural looking picture. I fully understand that dithering should only be used at the very last stage, but you can see that this is not the case in the 48bit ProTools mixer: http://akmedia.digidesign.com/support/docs/48_Bit_Mixer_26688.pdf
http://www.pixelz.fr/1/f/1/e73fac6b827cc3b34ced921a07352.pnghttp://www.pixelz.fr/2/5/5/458244106ec3ddac658a19d36f841.png

All processing is done in 48bit, then dithered to 24bit, and sent to the TDM mixer "as is", then processed in 48bit again etc etc...there's so many values that the dithering "artifacts" hardly matter as I understand it.

Surely, SmoothL provides a very impressive PQ through LSF :eek:

You can see in my dither.rar (http://www.mediafire.com/download.php?mov7dj5pais1wa2) file that mVR's dithering is hardly visible on top of SmoothL's, but still makes up for a nice improvement :cool:

SmoothL: http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093t.jpg (http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png) / SmoothL+mVR: http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528ft.jpg (http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528f.png)

I don't think the strength has anything to do with it. It's Floyd Steinberg vs. random dithering. They look slightly different. My personal opinion is that the difference is very small, though
Did you try on CRT/DLP? HD movies are still mastered on CRT for a good reason IMHO. LCD is up to no good for proper video mastering/visualization..this CRT will remain the industry standard for many more years to come: http://www.sony.co.uk/biz/product/bvm/bvm-a14f5m/
This monitor is intended for the most critical picture evaluation in the high-end production and post-production environments.

Snowknight26
3rd January 2011, 19:03
JPGs for comparison. Tsk, tsk.

leeperry
3rd January 2011, 19:17
Not sure what you're referring to, but my comparisons are PNG:
http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png
http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528f.png

madshi
3rd January 2011, 19:44
Oh yah, choosing the dither algorithm/strength would be really sweet! possibly using a built-in quick calibration helper...
Read again what I wrote. I think you missed half of what I said.

I fully understand that dithering should only be used at the very last stage, but you can see that this is not the case in the 48bit ProTools mixer
The noise floor on a 16bit audio track is so low that it's almost not audible. With 24bit audio the noise floor is 264x lower. So if dithering is applied multiple times it's not such a big problem at 264x lower than audible levels. Video 8bit processing is a whole different beast. I would say that video dithering noise with 8bit video is more noticeable than audio dithering noise with 16bit audio. So you can't really compare one thing to the other.

HD movies are still mastered on CRT for a good reason IMHO. LCD is up to no good for proper video mastering/visualization..this CRT will remain the industry standard for many more years to come
Your information is out of date, I think. According to my information, many studios are using a combination of CRTs, LCDs and plasma displays for mastering these days. LCDs are useful because they show compression artifacts much clearer than CRTs.

leeperry
3rd January 2011, 20:32
Read again what I wrote. I think you missed half of what I said.
Well, you said that it wouldn't be easily doable..which is too bad, maybe you'll find a way to overcome those limitations someday..that's all I meant.

The noise floor on a 16bit audio track is so low that it's almost not audible. With 24bit audio the noise floor is 264x lower. So if dithering is applied multiple times it's not such a big problem at 264x lower than audible levels. Video 8bit processing is a whole different beast. I would say that video dithering noise with 8bit video is more noticeable than audio dithering noise with 16bit audio. So you can't really compare one thing to the other.
Indeed, but it's usually interesting to compare audio and video dithering...and even though SmoothL works in 32fp internally and then dithers back later on, the PQ improvement on a CRT is *very* real...I hope you'll check out my test patterns on something else than a LCD someday.

16-235 SMPTE-C(the smallest gamut) might very well not contain as much genuine data as we'd think....less than 0-255 xvYCC(twice bigger than SMPTE-C) by a long shot.

Your information is out of date, I think. According to my information, many studios are using a combination of CRTs, LCDs and plasma displays for mastering these days. LCDs are useful because they show compression artifacts much clearer than CRTs.
Well, that's what the french ISF CEO and what the industry insiders are saying...surely LCD is improving, but most(if not all) BD's are still mastered on a SMPTE-C CRT..it's rather obvious when playing around w/ LUT's in mVR on a perfectly calibrated D65/2.4 projector. And even the best LCD's only output 1000:1 native CR apparently, good luck w/ that.

Anyway, I've made my point and you've said that Pixel Shaders couldn't output the same kind of dither as SmoothL uses, case closed http://forum-images.hardware.fr/images/perso/the%20bloodhound%20gang.gif

robpdotcom
3rd January 2011, 22:13
I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.

FWIW, this also happens with "Medium" text if I use 1280x720 resolution.

mark0077
3rd January 2011, 22:55
madshi, using your latest build 0.36, with "enable automatic fullscreen exclusive mode" enabled, and the two sub options to "show seek bar" and "delay switch to exclusive mode by 3 seconds" disabled. When in fullscreen exclusive mode, if I move the mouse down to the bottom of the screen, madvr goes out of exclusive mode, and of course soon afterwards goes back into it.

Is this a madvr bug or a mpc-hc bug? Its like as if the mpc-hc seekbar is still being selected / hovered over when I move the mouse down to the bottom of the screen.

yesgrey
4th January 2011, 00:06
From the log I can see that there's a 2 second delay everytime madVR starts up. But the delay doesn't seem to be caused by madVR. I just see a 2 second gap in the log with no explanation where it could be coming from.
Ok. I will try to see if I find where it comes from, but since this only happens with madVR it would be more likely to be its responsibility... with all the other renderers the response is immediate, but with madVR there is always some kind of delay. Sometimes is barely noticeable, but other times it completely stalls the media player for several seconds... I've quit completely using ZoomPlayer because it's even worse than with mpc-hc, and I really liked using ZP...
If it wasn't for its quality and for being the only option for using the 3DLUTs I would consider not using it, unfortunately that's not an option for me, so I've decided to accept its humours... but I would be a lot happier if we could solve this. ;)

madshi
4th January 2011, 00:22
madshi, using your latest build 0.36, with "enable automatic fullscreen exclusive mode" enabled, and the two sub options to "show seek bar" and "delay switch to exclusive mode by 3 seconds" disabled. When in fullscreen exclusive mode, if I move the mouse down to the bottom of the screen, madvr goes out of exclusive mode, and of course soon afterwards goes back into it.

Is this a madvr bug or a mpc-hc bug? Its like as if the mpc-hc seekbar is still being selected / hovered over when I move the mouse down to the bottom of the screen.
This is actually as intended. MPC HC doesn't know whether madVR is in exclusive mode or not. So it always tries to show its own seekbar. Whenver it does, madVR has to exit exclusive mode to make the MPC HC seekbar visible. Nothing wrong with that. As intended.

When you enable madVR's own seekbar, madVR hacks into the mouse messages to make MPC HC think that the mouse would never go lower than the middle of the screen. This way madVR manages to stop MPC HC from showing its own seekbar. madVR does this only if the madVR seekbar is enabled, though. Why would you want to have *both* the MPC HC *and* the madVR seekbar disabled? Doesn't make too much sense to me.

Ok. I will try to see if I find where it comes from, but since this only happens with madVR it would be more likely to be its responsibility... with all the other renderers the response is immediate, but with madVR there is always some kind of delay.
Well, from the logs I can't see anything. It doesn't appear to be madVR's fault. But who knows, the logs don't always tell everything. It's before the network initialization, in case you are tempted to ask, so the net init is definitely not at fault in your case.

mark0077
4th January 2011, 00:58
Thanks madshi, well I want one taskbar, either the mpc one or the madvr one. It doesn't matter to me.

Unfortunately

1) The madvr one doesn't work.... I primarily am watching blu-rays with multi m2ts files involved so some sort of workaround would be needed here between madvr and software players to allow its seekbar to work correctly.

and

2) I had set madvr to go to exclusive mode immediatly so of course when I attempt to use the mpc seekbar, as you described madvr will immediatly go back to exclusive mode.

I guess I'll have to reenable the madvr seekbar and just not use it until some potential workaround comes along in the future for multi m2ts blu-rays.

pankov
4th January 2011, 01:17
mark,
why don't you enable the 3 seconds delay?
As far as I know this delay is used only when going from Fullscreen windowed to Fullscreen exclusive. If you go from window to fullscreen it will go directly in Exclusive mode. It's the same when you start the playback directly in fullscreen. So in most cases you get immediate Exlusive mode, only when it's needed you get delay.
On both of my PCs (either NVidia or AMD video card) I have the problem that the mouse is automatically moved to the center of the screen when I go out of Exclusive mode and if I don't enable the 3 seconds delay I'll never be able to use the popup menu, but I guess you don't have such a problem.

mark0077
4th January 2011, 01:26
Well even with the 3 second delay, madvr seems to lose fullscreen exclusive mode when I hover down over the mpc menu (expected), but then immediately madVR is going into fullscreen exclusive, its not waiting 3 seconds, ie its not giving me a chance to use mpc-hcs seekbar. I have restarted mpc-hc after making this change but still no 3 second delay.

The time I went into the settings dialog however I got a "madVR instance didn't reply properly" message, first time I have seen it....

Yes I also have the problem where the right click on the screen when in exclusive mode, and when the 3 seconds delay isn't used, I can never use the right click menu. Can madVR listen for right clicks and always have some sort of delay even when the option for the delay is disabled? I suppose madVR could listen for right click events, not pass them onto mpc-hc (is this possible?), come out of exclusive mode, then send a right click event to mpc-hc. That way madvr comes out of exclusive mode AND the menu appears with one only right click as the user would expect.

iSunrise
4th January 2011, 01:31
Some more feedback for 0.36.

Can anybody confirm this? I've not seen it on my PC, I think. If anybody can reproduce this, a log would be helpful.
I could not reproduce it.

I woke up today and opened PotPlayer (internal source and decoding filters enabled, using haali, but no ffdshow) and played back a 1080p trailer (MOV, H264) and I paused it. After breakfast I came back (about 1 hour later) and clicked on play again. The trailer was still perfectly in-sync. A little bit later I did the same with an .AVI (XVID) and a .FLV (H264) and paused them for about 20 minutes and unpaused them. Both were perfectly in-sync, too.

This sounds to me like it may rather be MPC HC or ffdshow specific or itīs the source encoding that is at fault here. Thereīs always some encodings that are just awfully done.

hdboy
4th January 2011, 03:15
I'm curious: with version 0.35+, why does the screen flash so many times when opening and closing a video with MPC? With 0.34 it was a 2-3 times; now it's like 6.

I'm using FSE.

gliderzone
4th January 2011, 11:11
I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.

Press CTRL-J to bring up the OSD, it will say there if you are in windowed or exclusive mode.

Thanks for your comment, I have checked the OSD but in my system, madVR never switches to FSE when using "Larger" text. I'm running Windows 7 in 1920x1080. Tried with both KMPlayer and MPC HC...

dansrfe
4th January 2011, 14:55
I'm using madVR v3.6 on Windows 7 x64 with the latest MPC-HC MSVC 2010 and latest ffdshow and I get substantial frame dropping if I pause a video and play it back again after more than 1-2 minutes. The only way to stop the frame dropping is to restart the file.

*Touche*
4th January 2011, 15:09
Try replacing all "flush & wait" settings with "flush" only. Does that help?

Flush & wait (sleep) was only on "after last render step". Changing it to flush didn't help. I've tried changing all to flush, but it was worse. The best performance by far is with all set to "flush & wait (loop)", but it's still a bit slower than windowed mode with default settings.

Not sure why you get problems with ReClock. Try cleaning up the Reclock timing database. That has helped some people in the past.

I've tried cleaning the database several times, but it didn't help. It's strange how everything is reported to be perfect, but the strange skipping comes up in a regular interval.

rmp459
4th January 2011, 15:37
I am coming to you friends here @ madVR because my question is mostly but not entirely related to using madVR as my renderer, however I am stumped and no one elsewhere seems to be able to point me in a new direction.

I just reformatted... Starting again one more time.

My issues is that I am trying to run in windowed mode w/ aero off and w/ reclock in mpc-hc, but no matter what I do or change... 1080p content has a tearing issue ~ 30-50 pixels from the bottoms of the screen whether I am just windowed or fullscreen windowed. This also only occurs when my HDTV is set to 23/24hz... which is unfortunately my goal... (hdtv does not support a 48 hz rate... i didnt really expect it to.)

When I go to 60hz or fullscreen exclusive, the tearing is gone, but in fsX, my rendering times are very high.


My other option which seems to work relatively well, was to leave aero on and have a script run each time a file launches to turn off the windows desktop manager services in order to "reset" the aero composition rate and get it to match each file. This works well, but last time i tried it, it felt like the clocks were wandering a bit w/ audio vs video and there is still an occasional stutter in the playback... (which i could live with if the sync looked right to me)

Ideally I want to get this tear gone, but no matter what I set the vsync in reclock to, it is in the same spot...it doesnt occur the entire time things are playing... just at intense scenes of a movie... panning... credits... it comes and goes..

anyone have any idea? could I also find a way to use reclock with fsX and turn off vsync in reclock but let it adjust the clocks for perfect match ?

thanks for any help... im losing my mind.. this is weeks now...

Im starting to think im never going to find a perfect solution... regardless of how much time i put into this...

(I am running mpc-hc as my player ffdshow for audio and subtitles. I have tried both the internal 264 decoder w/ mpc-hc and the one that is in ffdshow... both produce the same result w/ 1080 content @ 23/24hz)

mark0077
4th January 2011, 15:38
I've tried cleaning the database several times, but it didn't help. It's strange how everything is reported to be perfect, but the strange skipping comes up in a regular interval.

Well it may not be the same issue but I had very similar strange effects as you describe a few weeks back. My problem was madVR was detecting my displays refresh correctly, reclock was not. Reclock was detecting it as 24 when it was actually 23.976 or the other way around.

Just check what reclock detects as your display refresh rate vs madVR's stats because even the nvidia control panel I have found to show incorrect refresh rate recently. madVR was the only 1 of the 3 to be correct 100% of the time.

*Touche*
4th January 2011, 17:22
Well it may not be the same issue but I had very similar strange effects as you describe a few weeks back. My problem was madVR was detecting my displays refresh correctly, reclock was not. Reclock was detecting it as 24 when it was actually 23.976 or the other way around.

Just check what reclock detects as your display refresh rate vs madVR's stats because even the nvidia control panel I have found to show incorrect refresh rate recently. madVR was the only 1 of the 3 to be correct 100% of the time.

I've checked and ReClock reads the refresh rate correctly. One repeated frame every few minutes w/o ReClock is tolerable, but it would be nice if I could figure out where's the problem.

Unfortunately, it's my friends laptop+TV, so my testing time is limited and his patience too :)

mark0077
4th January 2011, 17:49
Well the only other two things I can think of are the fact that madVR reads the framerate of the video from the decoder which can be inaccurate if filters inbetween are changing its speed? Is this a possibility?

Otherwise, perhaps you could make sure reclock's vsync is off and let madVR's do the sync work? I hope you can figure it out.

*Touche*
4th January 2011, 18:21
As I've said, everything is reported properly, stats are great, values are great...it just doesn't work right :)

I've tried with turning ReClock's vsync control off too, no change.

iSunrise
4th January 2011, 19:09
I'm using madVR v3.6 on Windows 7 x64 with the latest MPC-HC MSVC 2010 and latest ffdshow and I get substantial frame dropping if I pause a video and play it back again after more than 1-2 minutes. The only way to stop the frame dropping is to restart the file.
I cannot reproduce this with Vista x64, with either using PotPlayer (no ffdshow) or MPC-HC and ffdshow. Neither the OSD nor the movie itself shows dropped frames (apart from the expected dropped frames because of a not perfectly in-sync display, that is).

Are you using reclock? If yes, does it also happen when reclock is disabled in your chain?

Razoola
4th January 2011, 19:09
I am coming to you friends here @ madVR because my question is mostly but not entirely related to using madVR as my renderer, however I am stumped and no one elsewhere seems to be able to point me in a new direction.

I just reformatted... Starting again one more time.

My issues is that I am trying to run in windowed mode w/ aero off and w/ reclock in mpc-hc, but no matter what I do or change... 1080p content has a tearing issue ~ 30-50 pixels from the bottoms of the screen whether I am just windowed or fullscreen windowed. This also only occurs when my HDTV is set to 23/24hz... which is unfortunately my goal... (hdtv does not support a 48 hz rate... i didnt really expect it to.)

When I go to 60hz or fullscreen exclusive, the tearing is gone, but in fsX, my rendering times are very high.


My other option which seems to work relatively well, was to leave aero on and have a script run each time a file launches to turn off the windows desktop manager services in order to "reset" the aero composition rate and get it to match each file. This works well, but last time i tried it, it felt like the clocks were wandering a bit w/ audio vs video and there is still an occasional stutter in the playback... (which i could live with if the sync looked right to me)

Ideally I want to get this tear gone, but no matter what I set the vsync in reclock to, it is in the same spot...it doesnt occur the entire time things are playing... just at intense scenes of a movie... panning... credits... it comes and goes..

anyone have any idea? could I also find a way to use reclock with fsX and turn off vsync in reclock but let it adjust the clocks for perfect match ?

thanks for any help... im losing my mind.. this is weeks now...

Im starting to think im never going to find a perfect solution... regardless of how much time i put into this...

(I am running mpc-hc as my player ffdshow for audio and subtitles. I have tried both the internal 264 decoder w/ mpc-hc and the one that is in ffdshow... both produce the same result w/ 1080 content @ 23/24hz)

I take it you have a nividia card? If so you are in the same situation as me currently. I can tell you the tearing you see is caused by the nvidia driver version you are using. I have to go back to 258.96 to remove that tear at the bottom of the screen in fs windowed mode. I have not yet tried the just released beta drivers from nvidia though to see if this is fixed.

rmp459
4th January 2011, 20:32
I take it you have a nividia card? If so you are in the same situation as me currently. I can tell you the tearing you see is caused by the nvidia driver version you are using. I have to go back to 258.96 to remove that tear at the bottom of the screen in fs windowed mode. I have not yet tried the just released beta drivers from nvidia though to see if this is fixed.

I do indeed. I have tried this with both my GTX 470 and my GT 220...


I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.

Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?

DigitalLF
5th January 2011, 00:19
MadShi: 0.36 is really stable for me... and i have ONLY tested this version with default settings on my setup... but 0.34, 0.33 was never stable for me... but i did not change anything in settings on any of versions ... all default. (0.34, 0.33, 0.34, 0.35, 0.36)

Plutotype
5th January 2011, 01:51
Hi all,
Im not sure if this will be ffdshow related bug, but I have a problem with correct show/hide timing on subtitles using ffdshow 3712. This problem occurs only with VC-1 video streams. The subtitles loaded via ffdshow simply flicker/blink when they show or hide at playback.

- MPC HC latest build
- madvr, outputting YV12 via ffdshow
- subtitles are external in srt format loaded via ffdshow
- win7 64bit, all filters 32bit including reclock 1.8.7.3

I have done tests on several videos ( m2ts format with mostly HD audio tracks ) and H.264/AVC and MPEG-2 videos are ok regarding this issue - subtitles play without any blinking. In FFDshow I have wmv9 as VC-1 decoder enabled.

This problem will be probably attached to the mpc-hc splitter because when I activate Haali, the problem disappears. Haali does not "see" some HD audio streams, so I can not use this splitter generally.

So the question is, what causes the blinking subtitles. Splitter, decoder or maybe madvr renderer?

Thanks
Plutotype

rmp459
5th January 2011, 01:56
I do indeed. I have tried this with both my GTX 470 and my GT 220...


I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.

Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?

To follow up. No more tearing at the bottom of the screen in windowed full screen mod with the new nvidia beta drivers.

However, i still get delayed video compared to audio when i go full screen. Same result In windowed or exclusive. Anyone have his happen before? And this doesnt uhappen with evr cus.

pie1394
5th January 2011, 02:03
I do indeed. I have tried this with both my GTX 470 and my GT 220...


I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.

Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?

My setup is Win7 x64 & GTX260+ & Forceware 260.99...

To prevent the tearing issue for FILM type contents with madVR, the FSX mode is the only solution at p24 output signal. With p60 output signal at Window mode, it is less obvious, but still exists just at the place you mentioned. I remembered it was observed on my TV before.

Before madshi finishes the madVR embedded auto refresh rate changer for ver0.3x, I think Aero-off + MPC-HC auto refresh rate changer + madVR ver0.26 at FSX mode is the only most convenient solution to prevent tearing with various frame rate contents.

ps: My PDP TV supports 23.976, 24, 50, 59.94, 60 fps modes at 1920x1080 ...

dansrfe
5th January 2011, 02:09
I cannot reproduce this with Vista x64, with either using PotPlayer (no ffdshow) or MPC-HC and ffdshow. Neither the OSD nor the movie itself shows dropped frames (apart from the expected dropped frames because of a not perfectly in-sync display, that is).

Are you using reclock? If yes, does it also happen when reclock is disabled in your chain?

I'm not using reclock at all. I think Windows 7 x64 might react a little differently.

rmp459
5th January 2011, 02:27
My setup is Win7 x64 & GTX260+ & Forceware 260.99...

To prevent the tearing issue for FILM type contents with madVR, the FSX mode is the only solution at p24 output signal. With p60 output signal at Window mode, it is less obvious, but still exists just at the place you mentioned. I remembered it was observed on my TV before.

Before madshi finishes the madVR embedded auto refresh rate changer for ver0.3x, I think Aero-off + MPC-HC auto refresh rate changer + madVR ver0.26 at FSX mode is the only most convenient solution to prevent tearing with various frame rate contents.

ps: My PDP TV supports 23.976, 24, 50, 59.94, 60 fps modes at 1920x1080 ...

The new 265 beta drivers fixed the tear for me, but with mad vr my video comes in noticeably behind my audio and it gets even worse at full screen. This happens in both fsx and fsw.

I just spent a good 20 mins testing with evr custom and other stock renderers and i dont really have the problem at all. Its so frustrating. Over 100 hours into this and a dozen reformats and im still having problems show up.

*Touche*
5th January 2011, 11:01
To follow up. No more tearing at the bottom of the screen in windowed full screen mod with the new nvidia beta drivers.

However, i still get delayed video compared to audio when i go full screen. Same result In windowed or exclusive. Anyone have his happen before? And this doesnt uhappen with evr cus.

Interesting. I've noticed a slight delay in video on my friends setup, a laptop with Nvidia 210M. It is very small, but it's there. I found it very strange because I would have expected the sound to be little delayed since it was going via hdmi from the laptop to TV and then via optical to the receiver, but never for it to be early.

Don't know the exact version of drivers, but they were downloaded from the official site two weeks ago. Do you know what version doesn't have this problem?

Mark_A_W
5th January 2011, 12:24
Just fix delays with ffdshow - just add the ffdshow video decoder in the path and tweak the delay in "Queue & misc".

Delays are nothing to worry about, just fix it.

Mark_A_W
5th January 2011, 12:28
Oh, and some feedback:

I've had nothing but trouble with the last few versions (running fullscreen windowed, as exclusive won't work on an interlaced res). I'd even reverted to v0.18.

But 0.36 is rock solid. It "feels smooth" again. I'm using the default flush settings.

Thanks madshi!

rmp459
5th January 2011, 13:28
Interesting. I've noticed a slight delay in video on my friends setup, a laptop with Nvidia 210M. It is very small, but it's there. I found it very strange because I would have expected the sound to be little delayed since it was going via hdmi from the laptop to TV and then via optical to the receiver, but never for it to be early.

Don't know the exact version of drivers, but they were downloaded from the official site two weeks ago. Do you know what version doesn't have this problem?

No idea which version this didnt occur on... I too run HDMI to my TV and coax spdif to my AVR...

Also its the same that the delay is EXTREMELY small, but with 1080 content i still see the difference between EVR and MadVR... its like the audio/video sync wanders in the XXms range and the sound comes in just before the lips move...

Id love to use fullscreen exclusive if I could, but I get rendering times over 40-50ms regardless of which GPU i use (have a 470 and a gt 220) and the render queue drops... some flush changes seemed to help a bit but I couldnt iron it out with the audio at the same time... guess i just have bad luck.

worst part about it is how perfect it works on my 5 year old laptop w/ a NVS 140m gpu.


Just fix delays with ffdshow - just add the ffdshow video decoder in the path and tweak the delay in "Queue & misc".

Delays are nothing to worry about, just fix it.

I would, but it doesnt seem to be the same with 720 vs 1080 content and it seems to wander... some scenes seem decent... others seem off up to 100ms or so.

I've tried two different sound devices and the same result... there has to be something common that im missing... tried different audio and video decoders... Seems to vanish when I use EVR instead of madvr tho... which makes me 99% sure its something with how i have the renderer working... i just dont know what i could have possibly screwed up with this happened across like 3 fresh installs.

yesgrey
5th January 2011, 23:22
Ok. I will try to see if I find where it comes from
Well, from the logs I can't see anything. It doesn't appear to be madVR's fault. But who knows, the logs don't always tell everything. It's before the network initialization, in case you are tempted to ask, so the net init is definitely not at fault in your case.
It seems to be related with the Release version. The Debug version rarely stalls, but the release version is very bad. Would it be a compiler bug? Could you try different optimization settings or a different compiler?

dansrfe
6th January 2011, 04:39
Still having a stutter/frame drops on return from pause after 5 mins or so. No way to fix it but restart the file. Don't know what to do :(

EDIT: Never mind, I just switched to Exclusive mode and everything is smoooooooth. :)

On a side note, what exactly is the down side to using exclusive mode besides all the gui related stuff?

Razoola
6th January 2011, 09:52
Id love to use fullscreen exclusive if I could, but I get rendering times over 40-50ms regardless of which GPU i use (have a 470 and a gt 220) and the render queue drops... some flush changes seemed to help a bit but I couldnt iron it out with the audio at the same time... guess i just have bad luck.

Don't worry, you are not alone with the poor rendering times in full screen exclusive mode, I have the same issue. I have a feeling this will be fixed once madshi completes exclusive mode implementation.

Its intresting, like you I have an SLI setup (gtx 295 and gt240).

rmp459
6th January 2011, 15:33
Don't worry, you are not alone with the poor rendering times in full screen exclusive mode, I have the same issue. I have a feeling this will be fixed once madshi completes exclusive mode implementation.

Its intresting, like you I have an SLI setup (gtx 295 and gt240).

TL;DR - Solved my sound problems and sync issues and to anyone who experiences tearing with aero off using nvidia cards, please uninstall your current drivers, reboot, run driver sweeper 2.8.0 (current version) and then install the newest Nvidia drivers (GeForce/ION Release 265 BETA 266.35 January 4, 2011) They fixed some serious tearing problems.

SLI would require two of the same card and having SLI enabled? (Perhaps just a terminology mix up?)

By SLI do you just mean that you are running two cards independently?

(also, that GTX 295 has two GPUs onboard one PCB anyways, which I am sure that you know.)

Regardless,

Good news for once. I put my Xonar STX back in and used some guys "Unified Xonar Drivers" which are like Asus's sound drivers done correctly by some random guy in his free time. I had to enable test mode and then manually sign the "cmudaxp.sys" system file, but it has much lower latency and is rock solid stable so far (these cards are known to bsod on 64bit OS)

Guess I won't be selling this card... haha

After that I rigged up a config of everything using ffdshow decoders for audio and video, with madvr and reclock. But! I want to do bitstream so I am simply using reclock for an easy way to use wasapi exclusive for my sound output for the time being until I find a better way to do it. Also just letting madvr handle its own vsync.. (which results in No tearing w/ the new Nvidia Beta Drivers (GeForce/ION Release 265 BETA 266.35 January 4, 2011)) Seems to be playing back sync'd perfect w/ no major stutters or lags @ 24hz now...

Razoola
6th January 2011, 18:02
SLI would require two of the same card and having SLI enabled? (Perhaps just a terminology mix up?)

By SLI do you just mean that you are running two cards independently?

(also, that GTX 295 has two GPUs onboard one PCB anyways, which I am sure that you know.)


By SLI I was refering to the gtx295. Like you say its basically 2 gpus on one pcb (though I have the older two pcb version of the card).

Like you the latest drivers solved the tearing at the bottom of the screen in windowed mode for me also.

Plutotype
7th January 2011, 21:31
Hi all,
Im not sure if this will be ffdshow related bug, but I have a problem with correct show/hide timing on subtitles using ffdshow 3712. This problem occurs only with VC-1 video streams. The subtitles loaded via ffdshow simply flicker/blink when they show or hide at playback.

- MPC HC latest build
- madvr, outputting YV12 via ffdshow
- subtitles are external in srt format loaded via ffdshow
- win7 64bit, all filters 32bit including reclock 1.8.7.3

I have done tests on several videos ( m2ts format with mostly HD audio tracks ) and H.264/AVC and MPEG-2 videos are ok regarding this issue - subtitles play without any blinking. In FFDshow I have wmv9 as VC-1 decoder enabled.

This problem will be probably attached to the mpc-hc splitter because when I activate Haali, the problem disappears. Haali does not "see" some HD audio streams, so I can not use this splitter generally.

So the question is, what causes the blinking subtitles. Splitter, decoder or maybe madvr renderer?

Thanks
Plutotype

Just to let you all know, that after invidual communication with madshi, clsid and tetsuo55 we came to an conclusion, that the wrong timed appearing and disappearing of ffdshow subtitles in madvr setup in MPC-HC has its reason in one of the old and still non-resolved VC-1 bugs described already here:
http://c-a376e655.024-44-73746f50.cust.bredbandsbolaget.se/showthread.php?p=1236128#post1236128

The key bug is in the MPC HC m2ts splitter, not handling VC-1 correctly, producing garbled timestamps.The subtitle flickering is probably a follow up problem. Most probably the subtitle renderer is confused by the garbled timestamps.

I have tried the newcairels LAVFSplitter and although not all VC-1 videos did work well ( will report this on the thread later ), the timing of the subtitles using VC-1 videos was correct.
Pluto