Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd June 2013, 00:22   #18941  |  Link
Yups
Registered User
 
Join Date: Sep 2011
Posts: 362
Quote:
Originally Posted by DragonQ View Post
So what's the difference between 9.17.10.3071 and 9.18.10.3071? Is one for desktops and one for laptops?

This is the same driver, there is no 9.17.10.3071, that's just a mistake from Intel.
Yups is offline   Reply With Quote
Old 2nd June 2013, 01:04   #18942  |  Link
karamancho
black stain
 
karamancho's Avatar
 
Join Date: Apr 2013
Posts: 46
Quote:
Originally Posted by madshi View Post
try to decrease the GPU queue and present queue to lower values. E.g. try using 4 for both. Then check how much RAM is used.
video memory usage decreased by about 20 mb but the present queue still stays empty

btw. enabling smooth motion results in render queue 1-3/4 (and 1-3/8 when gpu queue set to 8)
karamancho is offline   Reply With Quote
Old 2nd June 2013, 01:54   #18943  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
There seems to be an issue filling the present queue (at least for me) on the HD 4000. As I reported in the bugtracker increasing the FSE frames in advance and continuing playback without restarting the player the present queue fills better.
I am wondering if this is another limitation of Intel's driver or something MadVR can do better in regards to the present queue.

Quote:
Originally Posted by madshi View Post
For those having problems with newer Intel GPU drivers...

It seems that Intel drivers 9.18.10.3071 (and .3111) have a bug which occurs when using the madVR option "use a separate device for presentation".
*update* I've just upgraded to the .3190 drivers from the site ajp2k11 linked us and the bug I informed Madshi about above has been fixed. This update is available for both Ivy and Sandy Bridge processors and use the older non tile based UI.

My present queues in FSE are still low 0/4-1/4 and nothing I change improves that but haven't had any glitches or drops. Windowed mode and it's backbuffers fill just fine.

Last edited by ryrynz; 2nd June 2013 at 04:16.
ryrynz is offline   Reply With Quote
Old 2nd June 2013, 04:04   #18944  |  Link
sgraves66
Registered User
 
Join Date: Sep 2012
Posts: 10
Quote:
Originally Posted by madshi View Post
Well, I guess you could create a thread which disables and de-focuses your window once every second. Wouldn't that workaround the problem?
I was thinking about trying something similar, but the mouse wheel issue is a bit more complicated. I would explain more, but it's a bit off topic. Don't want to take too much time away. Thanks for the suggestion.

On a different note, is there something special that needs to be done to display the seek bar in madVR? I simply query IAMStreamSelect on the filter graph to perform absolute positioning. i.e:

this.MediaSeeking.SetPositions(DsLong.FromInt64(next), AMSeekingSeekingFlags.AbsolutePositioning, DsLong.FromInt64(0), AMSeekingSeekingFlags.NoPositioning);

Unlike MPC-HC, the seek bar doesn't show. I do have it enabled it in settings (rendering\exclusiveSettings\enableSeekbar). I planned to look through MPC source, but figured I'd ask here. It's been 4-5 years since working with DirectShow, so I'm sure I'm overlooking something obvious.

Playback quality is unsurpassed with madVR. Between this and LAV filters, it's the combination I've been searching for since the late 90's, early 2000's. Thanks so much for the hard work.
sgraves66 is offline   Reply With Quote
Old 2nd June 2013, 07:35   #18945  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by leeperry View Post
OK, thanks for the help but I don't have any "trade quality for performance" option checked and changing those lines didn't help either

BTW, problem is identical whether it's used before or after scaling.
Then I don't know where the problem comes from. I don't think it's madVR's fault, but then who knows?

Quote:
Originally Posted by karamancho View Post
video memory usage decreased by about 20 mb but the present queue still stays empty

btw. enabling smooth motion results in render queue 1-3/4 (and 1-3/8 when gpu queue set to 8)
Don't know why this happens. You could try re-installing the GPU drivers, just as a test. If that doesn't help, you could create a debug log, covering maybe 30 seconds of playback and upload it somewhere (zipped, please) for me to look at. Maybe I can see something...

Quote:
Originally Posted by ryrynz View Post
There seems to be an issue filling the present queue (at least for me) on the HD 4000. As I reported in the bugtracker increasing the FSE frames in advance and continuing playback without restarting the player the present queue fills better.
I am wondering if this is another limitation of Intel's driver or something MadVR can do better in regards to the present queue.
As I mentioned in the bug tracker, I can't reproduce this issue on my HD4000 (win8 x64). My present queue fills perfectly fine. Without being able to reproduce the issue, it's going to be hard to do anything about it. Maybe a debug log (30 seconds of playback) could help shine some light on this, but I have my doubts...

Quote:
Originally Posted by ryrynz View Post
*update* I've just upgraded to the .3190 drivers from the site ajp2k11 linked us and the bug I informed Madshi about above has been fixed. This update is available for both Ivy and Sandy Bridge processors and use the older non tile based UI.
Interesting!

Quote:
Originally Posted by sgraves66 View Post
On a different note, is there something special that needs to be done to display the seek bar in madVR?
In theory it should automatically appear if the mouse cursor moves to the bottom of the screen. Maybe the madVR rendering window doesn't get the mouse events if the window is disabled? If so, you could try forwarding the mouse move messages to the madVR rendering window...
madshi is offline   Reply With Quote
Old 2nd June 2013, 08:33   #18946  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by madshi View Post
Without being able to reproduce the issue, it's going to be hard to do anything about it. Maybe a debug log (30 seconds of playback) could help shine some light on this, but I have my doubts...
As requested, a 30 second log.

At 17 seconds I increased the exclusive mode frames to be rendered in advance from 4 to 8, hope you find something.

*EDIT* Solved.

Last edited by ryrynz; 3rd June 2013 at 00:42.
ryrynz is offline   Reply With Quote
Old 2nd June 2013, 10:59   #18947  |  Link
petran79
Registered User
 
Join Date: Aug 2007
Posts: 87
Quote:
Originally Posted by madshi View Post
This sounds like the decoder (= your CPU?) is not fast enough. Enable the madVR OSD (Ctrl+J) and check the state of the decoder queue when the frame drop occurs. Is it nearly empty in that situation? Or is it near full?
this is what happens.
I play an anime Opening (AVC, 720x480, 29.97 fps) though this happens also later in the episode.

for a few seconds or even for 1 minute, at that said scene "display" goes at 0000000 Hz instead of 59

decoder queue is normal at 11-12. frames drop. queue number doesnt change. But after video goes smooth again, que peaks gradually, reaches 45-52/12 max. then gradually drops to normal level.

I have an i3 560 at 3.3 Ghz. It should be fine for that kind of video or for any video. On Windows 7 there are no issues. It can play all videos, even 10-bit HD with Jinc3, just fine.

Problem lies in how the CPU and GPU handle threads in Windows XP. Probably Nvidia didnt bother with XP support that much. Because the much weaker GTS450 I replaced, played videos just fine with MadVR.

Quote:
Originally Posted by leeperry View Post

I've got a remuxed BD with high bitrate that would exhibit the problem you're describing but I can force software decoding with ffdshow(libavcodec) instead of LAV/CUVID and presto! all is well.....the GPU doesn't take care of the video decoding anymore so its bitrate doesn't matter, doesn't that fix the issue for you as well
Same issue, whether I use ffdshow or LAV. Even if I use all trade quality for performance options in Madshi, same problem occurs.

Plus there is also tearing if I dont use exclusive mode.
I guess I'll stick to VLC for Windows XP.
petran79 is offline   Reply With Quote
Old 2nd June 2013, 11:42   #18948  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by ryrynz View Post
As requested, a 30 second log.

At 17 seconds I increased the exclusive mode frames to be rendered in advance from 4 to 8, hope you find something.
Are you sure that's the correct download link? It says "Tribute Album.rar (458.4 MB)".

Quote:
Originally Posted by petran79 View Post
for a few seconds or even for 1 minute, at that said scene "display" goes at 0000000 Hz instead of 59
Oh, that. Yeah, sounds like a GPU driver issue. madVR highly depends on being able to get up-to-date vsync information all the time. If the display goes to 0000000 Hz that means that the GPU driver isn't reliably providing vsync information. There's probably not much I can do about it, sadly...

News about the Intel driver problems:

The Ivy Bridge / Sandy Bridge driver series (begins with version number 15.28) does not have any problems with madVR. The latest driver from this series is 15.28.17.64.3190. However, the new Ivy Bridge / Haswell driver series (begins with version number 15.31) *does* have a bug which results in visible artifacts when using the madVR option "use a separate device for presentation". The latest driver from this series is 15.31.11.64.3186 and it still has the bug.

So Ivy Bridge users: Either stay with the Ivy Bridge / Sandy Bridge driver series until Intel has fixed the problem, or alternatively turn off the madVR option "use a separate device for presentation". Haswell users: You have no other choice than to disable the mentioned madVR option for now...

You will know which driver is from which series by looking at the GUI. The new Haswell drivers have a different GUI.
madshi is offline   Reply With Quote
Old 2nd June 2013, 13:30   #18949  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
Then I don't know where the problem comes from. I don't think it's madVR's fault, but then who knows?
Oh lol, OK.....so basically we put my levels problem with PS scripts in the "known issues" drawer and that's it?

FWIW the aforementioned script has always worked fine with VMR9 & EVR in MPC/PotP/KMP(using stolen code from MPC I presume) and even through this Avisynth PS script wrapper in FFDshow.

Sadly the only application from this list that comes with a source code is MPC and even if I were to ask JohnAd(who wrote the gamut mapping PS script, using 3DLUT code from yesgrey) for help, he wouldn't be able to look at what mVR does either

I remember you saying that MPC wasn't applying PS scripts properly on BTB/WTW but quite frankly I've never seen anything wrong with test patterns so would that be possible that you'd apply PS scripts exactly as they are in MPC pretty please? Or at least provide a "MPC broken PS script implementation compatibility fix"?

I realize that you said it was broken by design, but it gets the job done you know.....and all the apps previously mentioned use the exact same approach as MPC, which is the original spec that needs to be abiden with.....broken or not.

I'm entirely willing to believe that it was partially broken in the first place but it now randomly processes a levels conversion, how broken is that really

I was under the impression that the whole plan was to get mVR to apply PS scripts exactly as they are in MPC.......why not creating a new PS script spec if the current one is REALLY broken but still allow the old scripts to work as they've always had in MPC(and other apps abiding by the exact same specs)

I could also look for other scripts that don't work in mVR as they do in MPC but tbh this gamut mapping script is prolly the most important one to many people so it's a major bummer to see it processing a levels conversion randomly.....and it's so darn convenient to be able to create automatic profiles in PotP that roll gamuts on the fly =(



Quote:
Originally Posted by petran79 View Post
there is also tearing if I dont use exclusive mode.
I guess I'll stick to VLC
Oh, tearing now? Never had any with mVR....either way, thanks for the report!

Last edited by leeperry; 2nd June 2013 at 14:05.
leeperry is offline   Reply With Quote
Old 2nd June 2013, 13:48   #18950  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by madshi View Post
Are you sure that's the correct download link?
*EDIT* Don't worry found the cause of the issue with the queue.

Last edited by ryrynz; 3rd June 2013 at 00:41.
ryrynz is offline   Reply With Quote
Old 2nd June 2013, 17:13   #18951  |  Link
corporalgator
Registered User
 
Join Date: Jul 2008
Posts: 60
Alright, going to check with the LAV guys about the green screen and report back.

Last edited by corporalgator; 2nd June 2013 at 17:15.
corporalgator is offline   Reply With Quote
Old 2nd June 2013, 20:46   #18952  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by leeperry View Post
Oh lol, OK.....so basically we put my levels problem with PS scripts in the "known issues" drawer and that's it?

FWIW the aforementioned script has always worked fine with VMR9 & EVR in MPC/PotP/KMP(using stolen code from MPC I presume) and even through this Avisynth PS script wrapper in FFDshow.

Sadly the only application from this list that comes with a source code is MPC and even if I were to ask JohnAd(who wrote the gamut mapping PS script, using 3DLUT code from yesgrey) for help, he wouldn't be able to look at what mVR does either

I remember you saying that MPC wasn't applying PS scripts properly on BTB/WTW but quite frankly I've never seen anything wrong with test patterns so would that be possible that you'd apply PS scripts exactly as they are in MPC pretty please? Or at least provide a "MPC broken PS script implementation compatibility fix"?
Couldn't that script be fixed quite simply by changing the original:

Code:
float4 main(float2 tex : TEXCOORD0) : COLOR
{
    float4 c0 = tex2D(s0, tex);
    c0 = pow(c0, 1/0.45);
    c0 = mul(r2r, c0);
    c0 = saturate(c0);
    c0 = pow(c0, 0.45);

    return c0;
}
to the following which adds a clamp for out-of-range values:

Code:
float4 main(float2 tex : TEXCOORD0) : COLOR
{
    float4 c0 = tex2D(s0, tex);
    c0 = clamp(c0, 0.0, 1.0);
    c0 = pow(c0, 1/0.45);
    c0 = mul(r2r, c0);
    c0 = saturate(c0);
    c0 = pow(c0, 0.45);

    return c0;
}
I know nothing about hlsl though, as this is more a common sense idea that if you don't want out-of-range BTB values processed, you should clamp it. Someone who knows better should probably verify the functionally of such a change, but does that fix your problem?
cyberbeing is offline   Reply With Quote
Old 3rd June 2013, 00:07   #18953  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by cyberbeing View Post
Couldn't that script be fixed [..] if you don't want out-of-range BTB values processed, you should clamp it. Someone who knows better should probably verify the functionally of such a change, but does that fix your problem?
Ouh, (always wanted to use this emoticon ^^)

That sure would explain why full range source files looked utterly washed out indeed...this quick comparison on a 16-235 rec709 test pattern looks identical(only the filesize is 1 kb smaller for some reason, dithering was disabled of course):

untouched:

clamped: unclamped:

Also my funky 0-255 sample looks fine now, looks like you nailed it!

I will run more thorough tests and maybe the original PS script didn't care because as madshi said BTB/WTW were clipped by design if I understood him correctly...if madshi could please confirm that you nailed down the root problem, maybe a "compatibility mode" checkbox would still be fruitful in order to provide 100% compatibility with scripts that expect BTB/WTW to be clamped/clipped by design

I did send a few PM's to JohnAd but he hasn't connected to AVS in a while(his PM box must be full by now) and same goes for his company's official forum.

Last edited by leeperry; 3rd June 2013 at 00:22.
leeperry is offline   Reply With Quote
Old 3rd June 2013, 00:41   #18954  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by madshi View Post
I can't reproduce this issue on my HD4000 (win8 x64). My present queue fills perfectly fine.
Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.
ryrynz is offline   Reply With Quote
Old 3rd June 2013, 01:16   #18955  |  Link
karamancho
black stain
 
karamancho's Avatar
 
Join Date: Apr 2013
Posts: 46
I have a terrible lag in windowed mode but only with some videos. The OSD says their composition rate is 30.000Hz (no lag in 60.000Hz videos). Is this madvr related or is it the videos 'fault'?


Quote:
Originally Posted by ryrynz View Post
Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.
conformed.
edit: it doesn't happen in the newest beta http://justgetflux.com/news/2013/05/29/beta.html

Last edited by karamancho; 3rd June 2013 at 01:36.
karamancho is offline   Reply With Quote
Old 3rd June 2013, 01:51   #18956  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by karamancho View Post
edit: it doesn't happen in the newest beta[/URL]
Installed the beta, and still has the issue. Disabling or selecting movie mode doesn't change anything either, the program has to be terminated. I've mentioned this problem to the team on their website.

Madshi is it possible to block programs making changes in this way while MadVR is active? Maybe there are other programs that can affect MadVR in the same way?
ryrynz is offline   Reply With Quote
Old 3rd June 2013, 08:09   #18957  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by cyberbeing View Post
Couldn't that script be fixed quite simply by changing the original [...] to the following which adds a clamp for out-of-range values:

Code:
    c0 = clamp(c0, 0.0, 1.0);
Good thinking!

Although, actually I had already suggested a very similar thing. However, my suggestion had a bug in it. I had suggested "saturate(c0)" which is the same as "clamp(c0, 0.0, 1.0)". But my mistake was that I suggested "saturate(c0)" instead of "c0 = saturate(c0)". Doh.

Quote:
Originally Posted by ryrynz View Post
Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.
Interesting. I remember somebody mentioning f.lux making problems before...

Quote:
Originally Posted by karamancho View Post
I have a terrible lag in windowed mode but only with some videos. The OSD says their composition rate is 30.000Hz (no lag in 60.000Hz videos). Is this madvr related or is it the videos 'fault'?
Composition rate is not really related to the video itself. It's the internal OS' Aero redraw rate. Normally it's expected to be identical to the GPU refresh rate. In your case it seems that sometimes the OS chooses a composition rate of only 30.000Hz instead of 60.000Hz, although the GPU refresh rate is probably 60.000Hz (it is, isn't it?). Don't ask my why the OS is doing that. Very stupid, IMHO.

Are you using the madVR display mode changer? Or some other display mode changer?

Quote:
Originally Posted by ryrynz View Post
Madshi is it possible to block programs making changes in this way while MadVR is active? Maybe there are other programs that can affect MadVR in the same way?
For that I'd have to know what those other programs are doing to affect madVR. I don't know that. And even if I knew, madVR would not be able to stop that, unless you wanted madVR to inject a hook dll into all running processes, which would be a rather dramatic thing to do...

Last edited by madshi; 3rd June 2013 at 08:15.
madshi is offline   Reply With Quote
Old 3rd June 2013, 09:03   #18958  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by madshi View Post
unless you wanted madVR to inject a hook dll into all running processes, which would be a rather dramatic thing to do...
Indeed. One of the mods on the F.lux website seems to think it's a GPU driver bug. I'll wait for confirmation of that first and if that's the case I'll ask that you pass that on to your Intel contact if that's alright.
ryrynz is offline   Reply With Quote
Old 3rd June 2013, 10:55   #18959  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.
madshi is offline   Reply With Quote
Old 3rd June 2013, 12:32   #18960  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 5,351
Quote:
Originally Posted by madshi View Post
Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.
Sweet!

Sent from my Xoom using Tapatalk HD
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED
SamuriHL is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:06.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.