[madshi]

Originally Posted by cyberbeing

And yes, the CPU load regression began in the very first deband test build. CPU load in 0.87.0 is slightly higher (+0.4%), but the significant doubling in madVR CPU usage started with this first deband test build.

Ok, can you please retest with the 87g build? If the problem is still there, please try the "madVR - cyber.ax" in the 87g rar file. Does that fix the problem? If not, how can I reproduce the problem? I've tested with DXVA2 decoding here with my AMD card, to avoid having the software decoder screw CPU consumption measurements up, and I'm getting 0.7% CPU usage in MPC-HC, both with v0.86.11 and v0.87f.

Originally Posted by DragonQ

Nope, all the new features, including debanding, are definitely off.

Ok. Can you please try 87g? If the problem still occurs, please try the "madVR - dithermod.ax" instead. Does that fix the problem? If not try setting the display to 7bit instead of 8bit. That will switch to a simpler dithering method. Does that fix the problem? If not, please try turning dithering completely off for both v0.86.11 and v0.87.0g and compare whether that makes them perform identically or not. If not, at least I'll know that the problem is not caused by the changes in the dithering pixel shader...

Originally Posted by noee

Clocked the chip to 3.5Ghz (NB @ 2.4Ghz) and everything works great, no drops, full queues. Back to bone stock BIOS (2.6Ghz), no joy.

At stock, when upload queue goes empty, CPU is at ~55-60% per ProcessExplorer. On .86, it hovers ~34%, same video, same settings.

Ok. Can you please try 87g with debanding turned *off*? Does that fix the uploading problem for you? If so, does turning debanding on - and choosing a higher setting for fades bring the problem back?

Originally Posted by DarkSpace

Thanks for the explanation. The unwanted shift is exactly why I was asking... I'm curious: What kind of interpolation pass are you running?

Lanczos3AR in only one dimension (Y, IIRC) to shift the image 0.5 pixels.

Originally Posted by djfred93

ccc 13.12

Does 87g fix the problem? Make sure you disable all OpenCL related options, just to be safe...

Originally Posted by livache

.87 with smooth motion turned on returns black image when playing videos with mod2 height in normal window (100% - unresized). After resizing the window or turning to full screen, the image appears. > mod2 seem to play fine with smooth motion on.
GPU: GTX560Ti.

Originally Posted by Q-the-STORM

also, some files give a black screen, until i resize them (doesn't matter if up or down)... what these files have in common is that they are 1280x718 with DAR set to 16:9 according to mediainfo...
so it's black until i resize the window, but when I resize the window back to the original size, the frame is black again...
1280x720 content is working fine, so there might to be an issue with DAR... but 960x720 content with DAR set to 16:9 is also working fine, so it's not a universal problem with DAR...

9MB sample file

//just disabled smooth motion and there is no more black frame with the 1280x718 file.... it might have nothing to do with DAR... might be the mod2 problem livache is talking about...

Thanks guys, yes, same problem. Was a bug in the modified frame cropping logic, in combination with Smooth Motion FRC. Should be fixed in 87g.

Originally Posted by Q-the-STORM

there is a issue with deinterlacing... when I play 1080i MBAFF interlaced content or telecined NTSC DVDs (basically content that has some kind of interlacing), I get a black screen when having deinterlacing enabled (if in doubt, deactivate deinterlacing)... works fine when I disable deinterlacing in madVR...

Does it still occur with 87g? If so, can I have a small sample, just to make sure I'm testing with the same stuff? This is with video mode deinterlacing, not forced film mode, right? Does the problem also occur with forced film mode? Does it have anything to do with Smooth Motion FRC?

Originally Posted by noee

madshi, to follow up on your question regarding the impact of "use OpenCL to process DXVA NV12 surfaces...", yes, this has quite an impact here on my setup (HD6570). With that option enabled, I get dropped and repeated frames, video is not quite a slideshow, but close. All is well with that option disabled (default).

Ok, interesting. Seems the 6570 doesn't like this option. It has pretty much zero impact on my 7770.

Originally Posted by Deim0s

Except OpenCL, stopped working algorithms "image downscaling" (...or something else).
While playing content UHD (4k):
in windowed mode slideshow (madVR output),
when switching to full screen - black screen

In version 0.86.11 worked perfectly.

latest nightly MPC-HC, latest LAV Filters
Win7 32bit, i7-2600K, ASUS GTX770 2GB, ASUS VG278 27" 120Hz

Does the problem still occur with the 87g test build, if you disable all OpenCL related options and if you disable debanding? (Make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled.)

Originally Posted by kasper93

I have a problem with DXVA deinterlacing. "DXVA processing fail" when I open interlaced content. Log from latest test build https://dl.dropboxusercontent.com/u/16282309/madVR/madVR_deint.7z

I can manually enable deinterlacing later, but initially it fails.

Does it still occur with 87g? Which GPU, which OS?

Originally Posted by truexfan81

even a simple rule such as:
if (srcFps == 60) "Profile 2" else "Profile 1" fails to use the correct profile

The FPS information is coming from the decoder in a weird format. After convertion to something we humans can make sense of, it's not perfectly exact, anymore. Furthermore, it's likely to be around 59.940 and not 60.000. Your check "if (srcFps == 60)" would only work as intended if the FPS information coming from the decoder were exactly 60.000000000, without the slighest deviation. That's not going to happen. So it's better to use ">" or "<" instead of "==". E.g. use "if (srcFps > 59)" to give it a bit of safety margin.

Originally Posted by Nachbar

Same here. All i did was copy the new madvr over the previous version. I tried the uninstall and install.bat after mpc-hc crashed and that did not fix it. Weird thing is even though it will display a window that mpc-hc crashed unexpectedly the video still plays in the background fine.

My system: Intel Core i5 3570k, Nvidia Geforce 560 Ti, Windows 7, MPC-HC 1.7.1, madvr 1.8.8.1 (also tried 1.8.8.0 since it recently updated but the problem still occurs), LAV 60.1, xy-vsfilter 3.0.0.211

Does it still happen with 87g? Even with all OpenCL related options turned off ("use random dithering..." turned *on* in the "trade quality" section)?

Originally Posted by SecurityBunny

Figured I'd report my findings to help narrow down bugs.

Using MadVR 0.87.1, according to control panel. (AKA 0.87f)
MPC-HC 1.7.1.383 (Latest nightly.)

Nvidia GTX 780 graphics card. Quadro Driver 334.67.
Intel 3770k @ 4.2 GHZ

Tested with lav hardware acceleration 'none' and 'dxva2 (native)'. Tested in windowed mode.

No 'trade quality for performance' options checked with smooth motion enabled, black screen.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion enabled, flashing screen between picture and black until completely black.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion disabled, video plays back normally.

Can you please retest with 87g?

Originally Posted by TheProfileth

Have you considered adding in a upscale/downscale gaussian resize kernel, it just happens to my favorite blurring kernel so I thought I would ask.

Do you really want to blur things for realtime playback? Why?

Originally Posted by za222

I had the same problem in 0.87.

But for me the problem is not fixed in test build 0.87f.
Instead, when opening a video file the whole screen flickers very shortly, and then i get a *green* video screen with some weird artifacts on the top-left:
http://i.imgur.com/CstoDBp.png

Windows 7 x64 / MPC-HC x86 / LAV / Geforce 8800GTS

Weird. Does this still happen with 87g? If so, does it happen with *all* videos or just with some? Is it related to Smooth Motion FRC or not?

Originally Posted by AngelGraves13

Playback freezes when dragging the window to another monitor or to the TV. Dragging it back does not fix it.

MPC-BE and latest 0.87f. all 0.87 versions do this...going back to old version.

Does it still happen with 87g?

Originally Posted by ryrynz

Have had this happen on the c as as f builds, bringing up the OSD and then using CTRL-J again doesn't make the OSD disappear on the black bars of the window (4:3 image on 6:10 screen)

This is exactly the Intel driver problem everyone is talking about. The "BorderColor" tweak mentioned in the v0.87.0 release notes should fix this.

Originally Posted by pie1394

Test 0.87f build + MPC-BE 1.3.0.3 + XySubFilter 3.1.0.546 + GeForce driver 320.49 and 332.32 with IonLE(GF9300) on Win7 x64 SP1. The most ordinatory options available in 0.86.x build + debanding option work fine except following:

1. P10 contents shows nothing on the video window.
2. SmoothMotion option causes black rectangle box on ASS sub-title text. (this time it always presents no matter what option or configuration reset operation...)
3. Chroma NNEDI3 scaling option causes GREENish video
4. Any other option which requires OpenCL causes BSOD... @_@

OpenCL not working is currently to be expected, sadly. Will work on that later. BSOD is very very bad, of course. I kind of hate NVidia right now...

P10 and SmoothMotion making problems: Does this still occur with 87g? Even with debanding turned off?

Originally Posted by G_M_C

Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?

It's not just you. It's the pretty bad NVidia OpenCL support which is causing a lot of trouble. For now I'd advise all NVidia users to stay away from the new OpenCL options, until I found some time to investigate a proper workaround. Some problems are not related to OpenCL/NVidia, though.

Originally Posted by huhn

using exclusive fullscreen and switching the file with page up or mouse button 4/5 in mpc-hc frezzes the image but sound is still working like using opencl with nvidia but this happens with amd and no opencl options! it is still possible to stop playback with pressing the left mouse button but to close or leave the frozen image alt f4 is needed.

a vfr file runs almost fine with 86.9 6.5 ms but is runs very very bad with 87f 11 ms i can use spline3 ar with 86.9 but 87f doesn't work with bilinear. i don't think this is related to the "high" cpu usage from the debanding+ builds.

Does this still happen with 87g, even with debanding disabled? If so, please try the "madVR - dithermod.ax" file with the other related things I suggested somewhere above. Thanks.

Originally Posted by sdancer75

1) IVideoWindow Interface does not support windowless mode and the interface
IVMRWindowlessControl is not supported. How to make madVR windowless ?

madVR currently does not support windowless, unfortunately. This is planned for a future version. But not any time soon.

Originally Posted by sdancer75

2) 3RD PARTY SOFTWARE RESTRICTIONS : The software "madVR" may not be distributed together with any 3rd party
software without the written consent of the "madVR" author.

So, do I have to pay license fees ?

Don't stop reading there. Read to the end of the "3RD PARTY SOFTWARE RESTRICTIONS" section.

-------

So here's 87g:

http://madshi.net/madVR87g.rar

NVidia users, please stay away from all OpenCL related options for now. Also make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled. I'll look into making OpenCL work for NVidia once all the other problems (introduced by v0.87) are solved.