madVR - high quality video renderer (GPU assisted)

[madshi]

The desync is subtle and constant, but I didn't have time to let the video go longer to see if it's better or worse. I'm pretty sure the new option is responsible. I turn it on and increase present frames, I get desync. I turn it off and go back to present 3 frames in advance, it goes away. I've only tried 2 video sources with the new option (first time I didn't notice desync with car sound effects and overdubbed narration in Donnie Darko, second time I did by watching lip movements vs voice timing in an episode of House) I haven't used D3D9 presentation for a long time, will try later. Last time I used it it gave me hundreds of presentation glitches per minute but with no or very few dropped frames.

I'm on ATI. The Crimson driver control panel doesn't allow manual tweaking of flip queue size. I have no idea what it is at default. My MPC-HC is renamed, so it shouldn't be triggering any per-app settings in the driver.

When I have a moment I'll troubleshoot this a bit more and let you know what happens.

I've been perfectly happy with 2-3 frames for the present queue with "present a new frame per vsync" unchecked (and 24 GPU 128 cpu) for quite some time now. FRC seems to work just fine even with a small present queue. The stats show it's constantly between 1-3 and I never get presentation glitches or dropped frames (though this could be misreporting). I've kept it this low because the GPU queue drops to a max of 2/24 when I increase present queue to 4 or above, and the present queue fails to fill higher than 4 regardless of how high I set it.
Would be great if you could test all 3 variations (D3D9, D3D11 without the new option checked, D3D11 with new option checked) with the same presentation queue size to make sure that any desync you're seeing isn't caused by the present queue size. Of course if you get frame drop or presentation glitches all the time with a small presentation queue, when using D3D9 etc then you can't test it that way.

[har3inger]

I've gone ahead and done that. I tested:

D3D11 old, 3 present queue: Everything's fine.
D3D9, 3 present queue: Everything's fine.
D3D 11 new, 3 present queue: Everything's fine.

Here's where it's interesting:
D3D9, 16 present queue: a/v desync. Video is noticeably earlier than audio, but you'd have to be looking for it to see it. Didn't bother checking if it gets better/worse over time. I feel like it's a constant displacement.
D3D11 New, 15 present queue (setting it to 16 makes it 15): a/v desync. Exact same amount of perceived desync as D3D9, with video noticeably earlier than audio.
D3D11 Old, 15 present queue: Never fills the present queue above 4-5/15, never fills GPU queue above 3-4/24. Oddly enough, starts with mad stuttering and tons of dropped frames, but after queues stabilize, it settles down and stops dropping frames, with no A/V desync.

All of these above tests are using FSE mode, and I quit the program and reload after each setting just to be sure they're getting applied properly. The OSD reports that the present queues and D3D mode are set as I wanted. Oh yeah, D3D9 isn't throwing tons of glitches anymore. Everything is 0 glitches, 0 dropped frames after queues fill.

Now, in windowed, playing with backbuffer sizes:
D3D9: backbuffer 16, present queue 16: A/V desync in FSE, back out into windowed mode, desync is gone.
D3D11 new: present queue (windowed) 15, present queue FSE 15: A/V desync in FSE, gone in windowed.

It's definitely a problem with the present queues in FSE, and isn't a result of whether I use D3D11 or D3D9, since it affects both. The problem exists in FSE, but disappears in windowed mode with the same number of backbuffer/present frames. I suspect there's desync as well with smaller present queues, but it's been unnoticeable since I set it to max of 3.

[Werewolfy]

Glad to hear that! Looking forward to your screenshots.


Here is a screenshot that shows clearly the difference between Linear Light on and off for Crispen Edges.

http://screenshotcomparison.com/comparison/164352

The value I used was 1.0 in upscaling refinement but the issue is also present in image enhancements. I guess it's ringing after all but it's pretty bad...

[XMonarchY]

Does "Use Alternative Glitch-Handling Mode" option reduce visual quality and/or performance in any way?

[AngelGraves13]

Does "Use Alternative Glitch-Handling Mode" option reduce visual quality and/or performance in any way?

Nope. While I'm not too sure what it does exactly, it does seem to be something along the lines of "alternate vsync" basically having less glitches than regular vsync.

[madshi]

I've gone ahead and done that. I tested:

D3D11 old, 3 present queue: Everything's fine.
D3D9, 3 present queue: Everything's fine.
D3D 11 new, 3 present queue: Everything's fine.

Here's where it's interesting:
D3D9, 16 present queue: a/v desync. Video is noticeably earlier than audio, but you'd have to be looking for it to see it. Didn't bother checking if it gets better/worse over time. I feel like it's a constant displacement.
D3D11 New, 15 present queue (setting it to 16 makes it 15): a/v desync. Exact same amount of perceived desync as D3D9, with video noticeably earlier than audio.
D3D11 Old, 15 present queue: Never fills the present queue above 4-5/15, never fills GPU queue above 3-4/24. Oddly enough, starts with mad stuttering and tons of dropped frames, but after queues stabilize, it settles down and stops dropping frames, with no A/V desync.

All of these above tests are using FSE mode, and I quit the program and reload after each setting just to be sure they're getting applied properly. The OSD reports that the present queues and D3D mode are set as I wanted. Oh yeah, D3D9 isn't throwing tons of glitches anymore. Everything is 0 glitches, 0 dropped frames after queues fill.

Now, in windowed, playing with backbuffer sizes:
D3D9: backbuffer 16, present queue 16: A/V desync in FSE, back out into windowed mode, desync is gone.
D3D11 new: present queue (windowed) 15, present queue FSE 15: A/V desync in FSE, gone in windowed.

It's definitely a problem with the present queues in FSE, and isn't a result of whether I use D3D11 or D3D9, since it affects both. The problem exists in FSE, but disappears in windowed mode with the same number of backbuffer/present frames. I suspect there's desync as well with smaller present queues, but it's been unnoticeable since I set it to max of 3.
Ok, that means the new mode isn't worse than the old, which is good.

Can you roughly quantify the desync amount?

In any case, it kinda looks like a driver issue. My impression is that for some reason your driver doesn't allow a higher than 4 frame queue. The "old" D3D11 mode just had different problems with that than the "new" mode. I assume you have tried different drivers already, and also a "clean" driver install with default settings etc?

Found this:

http://forums.guru3d.com/showthread.php?t=403389

So it seems there is a registry setting for the flip queue size for AMD drivers. Maybe it's set to a non-standard value for your GPU for some reason? Try setting it to 16 as a test.

Here is a screenshot that shows clearly the difference between Linear Light on and off for Crispen Edges.

http://screenshotcomparison.com/comparison/164352

The value I used was 1.0 in upscaling refinement but the issue is also present in image enhancements. I guess it's ringing after all but it's pretty bad...
Uh, that does look ugly!

Can you please make the original unsharpened frame available (PNG should suffice), so that I can test with that?

[AngelGraves13]

If your queue isn't filling up, you're probably overtaxing the GPU. Test and see what happens when you set all the scaling to bilinear for example and don't use doubling. Does it still not fill up? Then...as madshi said, it's a driver issue.

[Unr3aL]

You probably rather downloaded the same picture twice. ;)
I checked the image for different pixels (I downloaded them from the image hoster as well), each red pixel differs:
http://abload.de/thumb/diffh9suu.png (http://abload.de/image.php?img=diffh9suu.png)

You are probably right. After downloading the two a third time (already did twice before) it finally showed the difference... Maybe some firefox caching problem or something along the lines...

Sorry though.

Greetz, Unr3aL

[Werewolfy]

Uh, that does look ugly!

Can you please make the original unsharpened frame available (PNG should suffice), so that I can test with that?

Sure, here you go ;)

Original (http://postimg.org/image/bi173r7ur/)

[har3inger]

If your queue isn't filling up, you're probably overtaxing the GPU. Test and see what happens when you set all the scaling to bilinear for example and don't use doubling. Does it still not fill up? Then...as madshi said, it's a driver issue.

They "fill" from zero and get stuck. It's definitely not dropping queues, which is what it would look like if GPU isn't keeping up. Render times can be <5ms and it wouldn't matter.

The A/V delay is probably on the order of 25-75 ms. It's slight, but it's there. Has anyone else noticed this problem? Only exists when you use very high present queues in FSE.

I've tried only 16.2 crimson for testing the A/V delay. The driver is kinda cruddy and has lots of broken UI/settings functions on laptop, but otherwise runs applications well. Things are all set at default. I don't really want to revert to 15.12 crimson because the new driver is needed for a couple games I have.

Radeonpro doesn't actually work on my computer. It can't find the ATI card. Regedit search shows that the reg key doesn't exist by default. I'll go add it in manually at some point later once I find where my GPU reg settings are.

For now, I might just go back to using a 3 frame queue for present queue. Honestly, I don't really see any difference between 3 and something huge like 12, and FRC behavior doesn't seem to change based on the queue size. I've read before that you need more frames in present queue for FRC, but haven't actually found this to be the case. What would I be looking for, if it's not working properly at low queue sizes?

[AngelGraves13]

Are you limiting your frames to 3 or less in your AMD control panel? Does it ONLY affect FSE?

[har3inger]

Only affects FSE. It's not possible to limit frames to anything in AMD control panel. This problem with weird queues is the entire reason madshi rolled out a new fix for the d3d11 render code.

[madshi]

Sure, here you go ;)

Original (http://postimg.org/image/bi173r7ur/)
Thanks!

The A/V delay is probably on the order of 25-75 ms. It's slight, but it's there. Has anyone else noticed this problem? Only exists when you use very high present queues in FSE.
Weird. If the queue only fills to 4 frames with the "old" D3D11 mode, then a desync of maybe 15-4 = 11 frames would have been logical.

Radeonpro doesn't actually work on my computer. It can't find the ATI card.
There are a bunch of ATI tweak tools, this was just one which had a nice picture to it, showing the flip queue size GUI element. I suppose most/all of them will have the setting, so you could try a different tool. But if the desync is that small, I've kinda changed my mind and doesn't really expect this tweak to produce a difference. If you had a delay of ~11 frames then it would be a different situation.

For now, I might just go back to using a 3 frame queue for present queue. Honestly, I don't really see any difference between 3 and something huge like 12, and FRC behavior doesn't seem to change based on the queue size. I've read before that you need more frames in present queue for FRC, but haven't actually found this to be the case. What would I be looking for, if it's not working properly at low queue sizes?
If you neither get frame drops nor presentation glitches, and if everything looks smooth to your eyes, too, then all is fine and you can just continue using the small queue size.

This problem with weird queues is the entire reason madshi rolled out a new fix for the d3d11 render code.
The original reason I implemented that was to fix shaky 3D playback. But after I implemented it, I thought it might help with non-filling presentation queues, too.

[Werewolfy]

I've found a really weird issue, I don't know if it has been reported.

The queues are not filling (all of them) when I upscale a video in 2160p using D3D11 exclusive mode (10 bit).
It's the only situation when this issue happens. I have no issues with D3D11 windowed mode or with D3D11 exclusive mode (8bit) or when I select 1080p for the desktop (whatever the resolution of the movie).

I was using Windows 7 x64 and never saw this issue. I've noticed it since I installed Windows 8.1 x64.

[madshi]

I've found a really weird issue, I don't know if it has been reported.

The queues are not filling (all of them) when I upscale a video in 2160p using D3D11 exclusive mode (10 bit).
It's the only situation when this issue happens. I have no issues with D3D11 windowed mode or with D3D11 exclusive mode (8bit) or when I select 1080p for the desktop (whatever the resolution of the movie).

I was using Windows 7 x64 and never saw this issue. I've noticed it since I installed Windows 8.1 x64.
That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.

[6233638]

That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.

[Werewolfy]

That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.
I tried the "alternative glitch handling mode" but it didn't really help. Sometimes when I move forward or backward (I don't mean when displyaing the seekbar) into the video the queues filled but it's pretty rare.

If I reduce the prepresented frames to 4 frames, the queues fill correctly but I don't really want to modify that... The only combination that doesn't give me dropped frames with interlaced DVD are :
- CPU queue size : 23
- GPU queue size : 14
- Frames presented in advance : 6

Deinterlacing seems to be pretty erratic most of the time.

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.

Strange, 6 doesn't work for me. I have to use 4.

[har3inger]

Okay, this is weird. I tried turning off FSE and just using windowed FS for longer queues, and D3D11 windowed full screen has a delay, but windowed (downsized 1080p-> 1080p plus window frames) has no delay.

Whatever. Back to tiny queue sizes it is :P

[GCRaistlin]

Jump to time (by clicking on the time scale in MPC-HC) is broken since 0.90.4 (WinXP). To be precise, the first click works but the second one is not and the player may hang after it.
Sample: http://mir.cr/2XNEHWTK

[CarlosCaco]

with d3d11 "old" my queues don´t fill, with the new alternate now my queues fill and the a/v are perfect synced, but i have a slight perfomance loss because the present a frame for every vsync option

i don´t output 10 bit and 3d, so there any advantage for me to use d3d11 ? or should i stay on d3d9?

i´m usinf FSE with the standard settings:

- CPU queue size : 16
- GPU queue size : 8
- Frames presented in advance :8

theres any advantage if i increase my queues? i have the trade quality option don´t render frames when fade... checked

[ryrynz]

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.
I have a 960 also. For what content and settings? Upscaling to 4k using d3d11 10-bit?

[Dlget]

something wrong with fullscreen scaling.
http://screenshotcomparison.com/comparison/164548

Tested with Zoom control disabled & Only move subtitle to inactive video area.
Video is not cropped.I can decrease width with "Num4" & it looks perfect then.
Why in fullscreen width is increased????hence some content in both side is lost.
How to fix this.

I'm using MadVR 0.9.12 with MPC-BE

[huhn]

can you make a screen with the osd (control+j)?

[Dlget]

can you make a screen with the osd (control+j)?

ahh.forgot basic setting.
Anyway solved now.
Thanks:thanks:

[Aikibana]

A more general question: Does anyone know how to fix the display number ID's?

I'd like my pc monitor to be number one, so it's ID number will STAY UNCHANGED when my second display (tv) is turned on for movie viewing.
My tv is connected via HDMI to the graphics card and always hijacks the ID number one spot when turned on.

The problem, however small, is that I always have to reconfigure the fullscreen options in MPC-HC because the display numbers have changed.

PS: This has no negative impact on my desktop positioning or icons, because I set my pc monitor as the primary default screen in win 10.

Any help would be greatly appreciated

[jmonier]

A more general question: Does anyone know how to fix the display number ID's?

Windows seems to be a power on to itself for display ID's. I've had occasional problems with this and I've never been able to find a solution other than to have all monitors on all the time.

[aufkrawall]

madshi, have you already taken a look at the latest super-xbr update? Seems like a big deal to me.
There are new versions of Adaptive Sharpen and SuperRes too. :)

Edit: Latest version on Github is from February:
https://github.com/bacondither/Adaptive-sharpen/

[Sunset1982]

madshi, have you already taken a look at the latest super-xbr update? Seems like a big deal to me.


https://github.com/libretro/common-shaders/blob/master/xbr/xbr-lv2-accuracy-multipass.cgp

You're right. It looks nice. Maybe Madshi could use it in madVR...

[Hyllian]

https://github.com/libretro/common-shaders/blob/master/xbr/xbr-lv2-accuracy-multipass.cgp

You're right. It looks nice. Maybe Madshi could use it in madVR...

I think you two are a bit mistaken. Those updates are for the xBR shaders, not for the super-xbr ones. They're very different shaders.

Though the new color distance code I'm using on standard xbr might some way improve other filters (including sxbr).

Instead using just luma, I found a source that presents a different way to calc distance between colors. See the source here (thanks to Sp00kyfox): http://www.compuphase.com/cmetric.htm

I played a bit with that formula and modified it a bit for my needs. So, the new xBR shaders are using that and it improves color, specially in sharp red/blue transitions. I don't know if these sharp color transitions are critical in movies as they are for games, maybe cartoons could benefit.

My color distance (a bit different from that source):

// Originally, these are the values
//#define XBR_RED_COEF 2.0
//#define XBR_GREEN_COEF 4.0
//#define XBR_BLUE_COEF 3.0

// These are better for my tastes. Other good combination is (3, 6, 1).
#define XBR_RED_COEF 17.0
#define XBR_GREEN_COEF 20.0
#define XBR_BLUE_COEF 3.0

float df(float3 A, float3 B)
{
float rmean = (A.r+B.r)/2.0;
float3 diff = A - B;
float3 K = float3(XBR_RED_COEF+rmean, XBR_GREEN_COEF, XBR_BLUE_COEF-rmean);

return sqrt(dot(K*diff, diff));
}



I have a CIECAM02-UCS shader implementation, which are considered the best way to calc color distances. It's just too much calculations for my needs. The results with that new color distance algo are very comparable with this ciecam02-ucs, at least on my tests. I think it's very good performance for much less computation.

Here's a comparison where it's easy to see how the new color distance algo fixes red/blue sharp transitions when compared to the standard color distance algo based only on luma: http://screenshotcomparison.com/comparison/164239/picture:0

[aufkrawall]

I think with the reduced ringing, super-xbr is almost as good as NNEDI3, but with much lower performance impact. NNEDI3 is still a bit better regarding aliasing (however, it also seems to remove some of the source on the other hand).
Kudos for your work!

[Hyllian]

I think with the reduced ringing, super-xbr is almost as good as NNEDI3, but with much lower performance impact. NNEDI3 is still a bit better regarding aliasing (however, it also seems to remove some of the source on the other hand).
Kudos for your work!
Thanks. I agree with you, NNEDI3 provides the better IQ, specially because it doesn't produce thick black/white lines in sharp edges. This is something I think about but couldn't figure out how NNEDI3 does it.

[madshi]

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.
Ok. Behaviour was the same? Meaning presentation queue simply didn't fill?

I tried the "alternative glitch handling mode" but it didn't really help. Sometimes when I move forward or backward (I don't mean when displyaing the seekbar) into the video the queues filled but it's pretty rare.

If I reduce the prepresented frames to 4 frames, the queues fill correctly but I don't really want to modify that... The only combination that doesn't give me dropped frames with interlaced DVD are :
- CPU queue size : 23
- GPU queue size : 14
- Frames presented in advance : 6

Deinterlacing seems to be pretty erratic most of the time.

Strange, 6 doesn't work for me. I have to use 4.
I'm a bit confused. You say 6 doesn't work for you, but then you say the only way that doesn't give you dropped frames with interlaced DVD is 6. Can you explain?

Are we talking about a totally separate issue here, with interlaced DVD? Or is it the same issue? It seems to be the first time you mentioned interlaced DVD...

Jump to time (by clicking on the time scale in MPC-HC) is broken since 0.90.4 (WinXP). To be precise, the first click works but the second one is not and the player may hang after it.
Sample: http://mir.cr/2XNEHWTK
Works for me! Are you 100% sure that this problem was introduced in 0.90.4? When the player hangs, does the player still react to mouse or keyboard actions? Or is it totally frozen? In the latter case please press Ctrl+Alt+Shift+Pause/Break and wait a few seconds. Hopefully a freeze report text file is then created on your desktop?

with d3d11 "old" my queues don´t fill, with the new alternate now my queues fill and the a/v are perfect synced, but i have a slight perfomance loss because the present a frame for every vsync option
What does the "present a frame for every vsync" option have to do with this?

i don´t output 10 bit and 3d, so there any advantage for me to use d3d11 ? or should i stay on d3d9?
There should be no quality difference, so use what works best for you.

madshi, have you already taken a look at the latest super-xbr update? Seems like a big deal to me.
There are new versions of Adaptive Sharpen and SuperRes too. :)
I'm aware. FWIW, the new super-xbr weights are mostly for game upscales. For real videos I found them to be slightly worse than the old ones. I need to test the new anti-ringing code, though, maybe that it an improvement, although I've been using my own code for that, anyway, so I'll have to compare.

Though the new color distance code I'm using on standard xbr might some way improve other filters (including sxbr).

Instead using just luma, I found a source that presents a different way to calc distance between colors. See the source here (thanks to Sp00kyfox): http://www.compuphase.com/cmetric.htm

I played a bit with that formula and modified it a bit for my needs. So, the new xBR shaders are using that and it improves color, specially in sharp red/blue transitions. I don't know if these sharp color transitions are critical in movies as they are for games, maybe cartoons could benefit.
I suppose you're using the color distance to calculate the angles and weights? But the actual interpolation is still done with the original RGB values? To be honest, I'm not fully sure if this would make things better or worse for movies. Would have to be tested.

[madshi]

madVR v0.90.14 released

http://madshi.net/madVR.zip

* fixed: using NNEDI3 sometimes resulted in black screen or crash
* fixed: 3D playback resulted in stuttering after about 1 hour of playback
* fixed: non-frame-packed 3D had scaling errors when using odd window sizes
* small performance improvement for non-frame-packed 3D rendering
* log file now never exceeds 512MB space, old log data is discarded if needed
Didn't really get around doing much this weekend. Hopefully more changes next week.

[Hyllian]

I suppose you're using the color distance to calculate the angles and weights? But the actual interpolation is still done with the original RGB values? To be honest, I'm not fully sure if this would make things better or worse for movies. Would have to be tested.

The color distance is used to calculate the edge directions (diagonals and horizontal/vertical). But I suppose movies wouldn't benefit much from it, because you hardly see sharp color transitions on them. Maybe cartoons could benefit, though. BTW, I didn't implement it on super-xbr shaders.

You should see if the new soft anti-ringing is good enough for madVR.

[madshi]

For movies we usually have 4:2:0 color subsampling (even for cartoons!), so I suppose it wouldn't help there much. It might even harm, because it could reduce edge calculation accuracy for the luma channel, which is the most important channel. Anyway, might still be worth a try, at some point...

Yes, I'm planning to try your anti-ringing code and compare it to my own super-xbr AR code. Maybe your's is better now for super-xbr, or maybe I can combine both or something.

[aufkrawall]

I need to test the new anti-ringing code, though, maybe that it an improvement, although I've been using my own code for that, anyway, so I'll have to compare.

Please also try the infamous American Dad cartoon example, the difference in ringing is very visible with it after quadrupling.

[mogli]

v0.90.14 seems to work fine but when playback starts OSD shows:

madVR reports:
- creating shader file failed

[madshi]

Argh, will have to create a new build.

[GCRaistlin]

Are you 100% sure that this problem was introduced in 0.90.4? When the player hangs, does the player still react to mouse or keyboard actions? Or is it totally frozen? In the latter case please press Ctrl+Alt+Shift+Pause/Break and wait a few seconds. Hopefully a freeze report text file is then created on your desktop?

Yes, the issue was introduced in 0.90.4. But my issue decription was incorrect, sorry. When clicking on the time scale, it takes a few secs for the player to react. Then the playback continues (both with 0.90.3 and 0.90.4+), but with 0.90.4+, the player stops responding to controls.
To be precise, I was able to reproduce the issue on 0.90.3 a couple of times, too, when I clicked on the time scale again too early (i. e. before the playback resumes after my previous click), but it is rarely. With 0.90.4+, the issue is always reproducible.
Freeze reports: 0.90.4 (http://pastebin.com/bAcU6paq), 0.90.3 (http://pastebin.com/VhTdymbA)

[playa21]

Hi,
I have a bug with subtiles move feature.
In a movie 2:35, at a certain point of time, the subtiles are moved back to the original position(outside black bars)
My options :
disable scaling if image size changes by only 2 lines
Moved subtiles at bottom.
Detect hard coded black bar
Keep bar visible forever
Crop black bar
Using xvsubfilter

Cheers

[madshi]

Yes, the issue was introduced in 0.90.4. But my issue decription was incorrect, sorry. When clicking on the time scale, it takes a few secs for the player to react. Then the playback continues (both with 0.90.3 and 0.90.4+), but with 0.90.4+, the player stops responding to controls.
To be precise, I was able to reproduce the issue on 0.90.3 a couple of times, too, when I clicked on the time scale again too early (i. e. before the playback resumes after my previous click), but it is rarely. With 0.90.4+, the issue is always reproducible.
Freeze reports: 0.90.4 (http://pastebin.com/bAcU6paq), 0.90.3 (http://pastebin.com/VhTdymbA)
Ok, thanks, will try to implement a workaround for this next weekend.

I have a bug with subtiles move feature.
In a movie 2:35, at a certain point of time, the subtiles are moved back to the original position(outside black bars)
My options :
disable scaling if image size changes by only 2 lines
Moved subtiles at bottom.
Detect hard coded black bar
Keep bar visible forever
Crop black bar
Using xvsubfilter
I'll need a sample with which I can reproduce this problem.

[madshi]

madVR v0.90.15 released

http://madshi.net/madVR.zip

* fixed: "creating shader file failed" (introduced in v0.90.14)

[Georgel]

madVR v0.90.15 released

http://madshi.net/madVR.zip

* fixed: "creating shader file failed" (introduced in v0.90.14)

Thanks!

After a short test, seems to be working fine!

I wanted to ask this, is it possible to implement more aggressive edge thinning algorithm?

[ryrynz]

I wanted to ask this, is it possible to implement more aggressive edge thinning algorithm?

Madshi, I asked about raising the max value for edge thinning earlier, would you mind raising it to 5?

[ionutm80]

Hi guys, madshi,

I really need your help on a specific bug.
But first my specs: GTX 960 4GB, GeForce driver 362.00 (clean instal), MPC-HC x64 1.7.10, LavFilters Nightly 0.67.0-142, madVR 0.90.13, SVP 4 Pro, Philips TV 1080p 60Hz. I don't know at exact which version of madVR the bug started to appear but for sure it was after 0.89, however I've only tested 90.12 and 90.13 for the moment. I have 4 profiles set in madVR: 2160p, 1080p, 720p and SD. For the last 2 I'm using luma doubling with NNEDI3 32 and 64 neurons respectively. When I try to play SD material (720x576 PAL DVDs ripped to mkvs) if MPC-HC is not in full screen or maximized windowed screen than madVR crashes (I can post tonight the crash report). This does not happen when I play 720p or 1080p material, I can squeeze MPC-HC size or drag from its margins in all directions and it still playing smooth. I have repeated the test on another PC, this time an Intel Core I3 NUC with HD4400 and there madVR does not crash no matter what material I play and what is the size of the MPC-HC window. It seems that the bug is strictly related to NVidia and playback of 720x576 material. I have also tested with MPC-HC launched from Kodi and since it's going directly fullscreen there is no issue on both computers. What is annoying however is that even if I select in MPC-HC the option to launch files in full screen it does not do this leading to crash of madVR when I play 720x576 material. Again the bug is non existent if I put manually MPC-HC in fullscreen or in maximized windowed mode. Do you have any suggestion on fixing this?

Kind Regards.

[Vyral]

Hi,
I have a bug with subtiles move feature.
In a movie 2:35, at a certain point of time, the subtiles are moved back to the original position(outside black bars)
My options :
disable scaling if image size changes by only 2 lines
Moved subtiles at bottom.
Detect hard coded black bar
Keep bar visible forever
Crop black bar
Using xvsubfilter

Cheers

Same thing here. madVR v0.90.13.
Whenever I play a video with back bar, the subtitles appear in the balck bar during the 5 first minutes of playback and then return inside the video.
The only option I've checked in zoom control is "Moved subtiles to bottom of the screen" everything else is unchecked.
I'm also using the lastest version of XYSubFilter.
I can't say for sure which version of madVR introduced it but it was introduced recently.

[kabal223]

Madshi, sorry to bother you, but do you have any plans to improve the 60hz 3:2 pulldown playback? Because after some further testing 58hz is still choppy for me, the only workaround Ive found is using the framerate doubler in the deinterlace options of ffdshow, but I have to also use reclock with forced 24fps, this way I get a perfect 3:2 pulldown playback, the problem is that reclock is not reliable for me and overall this workaround uses to many resources, I might have issues with really high bitrate files.

Thanks!

[playa21]

Same thing here. madVR v0.90.13.
Whenever I play a video with back bar, the subtitles appear in the balck bar during the 5 first minutes of playback and then return inside the video.
The only option I've checked in zoom control is "Moved subtiles to bottom of the screen" everything else is unchecked.
I'm also using the lastest version of XYSubFilter.
I can't say for sure which version of madVR introduced it but it was introduced recently.

In 90.10, I have the problem :sly:

[Werewolfy]

I'm a bit confused. You say 6 doesn't work for you, but then you say the only way that doesn't give you dropped frames with interlaced DVD is 6. Can you explain?

Are we talking about a totally separate issue here, with interlaced DVD? Or is it the same issue? It seems to be the first time you mentioned interlaced DVD...


When I said 6 doesn't work for me, I'm talking about the issue that the queues don't fill with 4K upscaling in D3D11 exclusive mode (10 bit). I have to use 4 in that case or desactivate 10 bit.

My problems with interlaced DVD (I'm talking about DVD but I think it's related to all interlaced content, it's just that 99% of my interlaced content is DVD) are nothing related to D3D11 exclusive mode or the latest MadVr version, you're right I never mentioned it. I've always found it very hard to avoid dropped frames with deinterlacing activated and "don't rerender frames when fade in/out is detected" unchecked because I can't use high CPU or GPU queue, the queues don't fill completely with deinterlacing activated. The only way I've found so far is to use 23-14-6 queues but even with that combination, I'm not totally confident to avoid dropped frames with some DVD...

[fedpul]

Hi madshi, the problem with black screens during playback when using NNEDI is not fixed, for me at least. I tried 90.15 last night and got two black screens in 40 minutes.

Settings used:
DX 11 Max Queues
Chroma: NNEDI 32
Luma: Jinc AR
Downscaling: SSIM 2D 100% AR LL
Doubling: (Always) NNEDI 32

System:
Windows 7 Ultimate x64
i5 3570k @ 4.4 GHz
GTX 970 @ 1400/1950
16 GB RAM

Thanks in advance!