madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by mzso

Does this have any change that might cause potplayer to leak? Because that's what I'm experiencing since around the time I installed it. +~80MB for every new playback cycle with fullHD videos.

No, I don't think so. Anyway, it's just a test build to test one fix.

[madshi]

@XMonarchY,

Graeme has replied to the problem you reported here:

http://www.avsforum.com/t/1471169/madvr-argyllcms

Can you please follow-up there and answer any questions he might have? Specifically he's asking for the .ti3 file you used and the collink options etc.

[Asmodian]

I posted my calibration files there as I have a similar issue. I hope it helps.

[seiyafan]

Actually with the currently inflated price of AMD cards, I have more hope with maxwell.

[Asmodian]

Based on feedback at avsforum it looks like it is actually a feature to allow wtw representation when possible (it is only possible when using -a in collink and linear GPU gamma ramps). It is only that on my display (and I assume XmonarchY's) blue cannot get any more blue so the brighter whites turn yellow. As only test videos should have any wtw beyond ~237 and the color isn't very off at 237 we probably shouldn't worry about it.

It does make interpreting test patterns trickier.

Edit: OR not! I'll just keep watch for a bit and see.

[madshi]

No. It's a bug in ArgyllCMS (at least Graeme explicitly said that what we're seeing is not as intended) and needs to be fixed.

[mzso]

Originally Posted by madshi

No, I don't think so. Anyway, it's just a test build to test one fix.

Okay. I installed over the madvr files with v0.87.4 and the memory usage normalized.

Test: vs. Stable:

[Ceremony]

Fantastic presenter madshi! Danke schön!

However, I can't really get smooth motion to work, without serious judders, while the delayed (and dropped) frames numbers climb.

decoder, subtitle, upload, render and backbuffer queue is always full and I went with the maximum amount for each.

This is most noticeable when I do something while the video is playing, like minimizing some random window or so.

With smooth motion disabled, actions such as these have no impact on the video.

PC/environment specs of interest:
NVIDIA GTX480 1.5GB @ Stock
INTEL i7-2600k @ 4.8GHz
12GB DDR3 RAM @ 1600MHz
2x Samsung PX2370 1920x1080 displays @ 70Hz

Test with various videos (720p, 1080p, 480p), result remains the same: Smooth Motion is unfortunately unusable
However, lower resolutions are less prone to the issue.

P.S. using mpcbe with lav(split+decode), ffdshow tryouts (filter video, mix audio), reclock and xysub

[madshi]

Originally Posted by mzso

Okay. I installed over the madvr files with v0.87.4 and the memory usage normalized.

If this problem occurs with v0.87.5, then please let me know. Otherwise please ignore this problem for now.

Originally Posted by Ceremony

However, I can't really get smooth motion to work, without serious judders, while the delayed (and dropped) frames numbers climb.

decoder, subtitle, upload, render and backbuffer queue is always full and I went with the maximum amount for each.

Maximum queue size is not always the best idea. If you run out of GPU RAM, this can have all kinds of bad effects. Anyway. Have you tried fullscreen exclusive mode? That's the best mode to use for smooth motion to work reliably.

[Ceremony]

Originally Posted by madshi

If this problem occurs with v0.87.5, then please let me know. Otherwise please ignore this problem for now.


Maximum queue size is not always the best idea. If you run out of GPU RAM, this can have all kinds of bad effects. Anyway. Have you tried fullscreen exclusive mode? That's the best mode to use for smooth motion to work reliably.

not an issue:
still ~1/3 of VRAM left and plenty of RAM too.

exclusive works much better, however, as i am using two monitors, its not really an option. Plus, it causes visual defects:
Minimizing, maximizing or closing windows will freeze the animation of said window in a state inbetween, till you exit exclusive mode on the other monitor.

[madshi]

Well, exclusive mode is the recommended mode. Of course if you have a dual monitor setup and want to continue working on the primary monitor while playback is running on the secondary, that might currently be problematic. I'm not sure if I can improve that. Maybe, but not soon. You could also try Overlay mode.

[cyberbeing]

Originally Posted by cyberbeing

I'd be curious what the underlying cause is, once you track it down.

Since you've now mentioned fully resolving this, what did the 'proper fix' end up being?

[Ceremony]

Originally Posted by madshi

Well, exclusive mode is the recommended mode. Of course if you have a dual monitor setup and want to continue working on the primary monitor while playback is running on the secondary, that might currently be problematic. I'm not sure if I can improve that. Maybe, but not soon. You could also try Overlay mode.

seems like that fixed it! thanks a bunch!

Also, is there a way to stop it from reinitializing when dragging the player to the other screen? My display have the same resolution and framerate/Hz, so there is no need to clear the queues, at least some of them.

EDIT: oh yeah, its probably been covered before, but searching a thread with 1200+ pages is like looking for that infamous needle in a haystack: Why doesnt OpenCL dithering work with NVIDIA? shouldnt it properly support OpenCL by now?

[madshi]

Originally Posted by cyberbeing

Since you've now mentioned fully resolving this, what did the 'proper fix' end up being?

The fix was 2-part: (1) A very small stretch of the data (~ 1.0000008 stretch factor) to move pure black below BTB and peak white above WTW. (2) I had to use a trick to get more precision out of the 16bit float format I have to use for D3D9 <-> DirectCompute interop.

Originally Posted by Ceremony

Also, is there a way to stop it from reinitializing when dragging the player to the other screen? My display have the same resolution and framerate/Hz, so there is no need to clear the queues, at least some of them.

That is necessary, because every monitor is driven by a separate "GPU", even if it's just 2 output ports of the same PCIe card.

[Ceremony]

Originally Posted by madshi

That is necessary, because every monitor is driven by a separate "GPU", even if it's just 2 output ports of the same PCIe card.

ah, okay, but is there a chance to improve upon that? e.g. when I use the enhanced video renderer (custom) with "reset when changing dispay" unchecked, it only seems to reset audio, not video.

well, this is probably the lowest priority request one can make^^

[madshi]

Originally Posted by Ceremony

EDIT: oh yeah, its probably been covered before, but searching a thread with 1200+ pages is like looking for that infamous needle in a haystack: Why doesnt OpenCL dithering work with NVIDIA? shouldnt it properly support OpenCL by now?

The next release will use DirectCompute for error diffusion (but not for NNEDI), which will work fine for NVidia users, too. But NNEDI/OpenCL still seems to be broken, NVidia's fault.

Originally Posted by Ceremony

well, this is probably the lowest priority request one can make^^

Yes, too many more important things to do.

Well... I am glad that 3DLUT WTW issue is now being worked on. It appears that at the moment, the only way to create a proper WTW is to make sure that all 256 bits of R, G, and B are present for the original LUT. That isn't possible on my TV - my B at 100% gray level is at 110% or so, which means 10% of bits are be missing to make up for imbalances in the rest of the LUT. This is why bars are yellow. Someone who is missing R, or G, instead of B, has pink or whichever other color bars. It is only my luck that Asmodian has a similar issue or my feedback/report would be dismissed...

Where should people submit the nVidia OpenCL <-> D3D9 interlop bug? nVidia's official bug reporting channel? Should any more information be provided, like a generic letter? I think the more people submit the bug, the more likely it is to be fixed in the next driver release or some time in the future...

Can D3D10 or D3D11 be used with OpenCL instead of D3D9 to run NNEDI3?

[cyberbeing]

Originally Posted by XMonarchY

Where should people submit the nVidia OpenCL <-> D3D9 interlop bug? nVidia's official bug reporting channel? Should any more information be provided, like a generic letter? I think the more people submit the bug, the more likely it is to be fixed in the next driver release or some time in the future...

Driver surveys

Posting in ManualG's stickied Driver Release threads on Geforce Forums

Bug reports

NVIDIA's CUDA Registered Developer bug reports (for madshi only, since NVIDIA's implements OpenCL via their CUDA compiler) Or probably a similar bug reporting mechanism which may exist through NVIDIA's Graphics/Game Development Registered Developer Program for Direct3D/OpenGL bugs (because of past abuse, they are more strict on accepting applications for that program, compared to the CUDA program where they'd accept anyone easily).

[tp4tissue]

Hello... for 24fps FRC'ed to 30hz... in 1/6 of a second, there are 2 real frames, and 3 blended frames, is that right?

[*Touche*]

Originally Posted by madshi

The fix was 2-part: (1) A very small stretch of the data (~ 1.0000008 stretch factor) to move pure black below BTB and peak white above WTW. (2) I had to use a trick to get more precision out of the 16bit float format I have to use for D3D9 <-> DirectCompute interop.

Will this fix the higher blacks when colored dithering is enabled?

BTW: FSE works without problems on secondary screen while normal work is done on the primary.