madVR - high quality video renderer (GPU assisted)

[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]

Originally Posted by huhn

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

ahh.forgot basic setting.
Anyway solved now.
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]

Originally Posted by Aikibana

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-s...-multipass.cgp

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

[Hyllian]

Originally Posted by Sunset1982

https://github.com/libretro/common-s...-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/comp...4239/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]

Originally Posted by 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!

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]

Originally Posted by 6233638

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?

Originally Posted by Werewolfy

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...

Originally Posted by 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

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?

Originally Posted by 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

What does the "present a frame for every vsync" option have to do with this?

Originally Posted by CarlosCaco

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.

Originally Posted by 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.

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.

Originally Posted by Hyllian

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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, 0.90.3

[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]

Originally Posted by GCRaistlin

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, 0.90.3

Ok, thanks, will try to implement a workaround for this next weekend.

Originally Posted by playa21

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.