madVR - high quality video renderer (GPU assisted)

[djsolidsnake86]

madshi here a file for you and for other users that want test:
http://web.tiscali.it/djsolidsnake86/clip1.mpeg

[madshi]

having an AR problem, though...it's never occured w/ older versions
Can I have a sample, please? And please let me know which splitter + decoder you're using.

and when going exclusive>windowed, these are my windows taskbar and desktop(I use a Vista theme on XPSP3): http://thumbnails37.imagebam.com/12145/b212a2121447337.jpg (http://www.imagebam.com/image/b212a2121447337)
(1) Is that a new problem with v0.41 or does it occur with older builds (> v0.36), too?
(2) Is it reproducable?
(3) How about the corrupted menus and seekbar? Are these problems still there? Better than in v0.40? Or the same?

madvr freezes with several .flv files in mpc-hc. the playback is fine but the mouse controls become unresponsive. i have to kill mpc-hc to get it to stop. this is with version 0.41
Can't reproduce that here. Can I have a small sample, please? Which splitter and decoder are you using? Which OS?

Is it something like, the video is 1280x720, madVR requests 2048x720, decoder says it is sending 1280x720, but actually is sending 2048x720?
Yes, that's exactly it. I think the same is happening with VMR/EVR. However, VMR/EVR do not seem to care that the decoder is saying it sends 1280x720. VMR/EVR seem to rely on that the decoders do as commanded, namely sending 2048x720. So madVR is now doing that, too. FWIW, all other decoders I've tested properly report they're sending 2048x720. Only NVidia's decoder and the WMV DMO (with some clips) is misreporting the format.

madshi here a file for you and for other users that want test:
http://web.tiscali.it/djsolidsnake86/clip1.mpeg
Thx. I can't reproduce any problems, though. I've tried and "ffdshow decoder -> madVR" works fine. And "DScaler decoder -> madVR" works fine, too, on my PC. Here are screenshots with your clips with VMR9 and madVR on my PC:

http://madshi.net/VMR9.png
http://madshi.net/madVR.png

As you can see, image quality is comparable. I've turned the OSD on for both VMR9 and madVR to proof that the screenshots are really from VMR9 vs. madVR.

[djsolidsnake86]

i'm using libmpeg2 with ffdshow and now looks very good (first i was trying libavcodec)
however thank you man ;)

[leeperry]

Can I have a sample, please? And please let me know which splitter + decoder you're using.
I've disabled all post-processing in ffdshow, and
whatever CoreAVC CUDA or ffdshow-mt decoding...same story on all files in PotP(the latest beta I provided you w/):

http://thumbnails7.imagebam.com/12149/b7e998121489252.jpg (http://www.imagebam.com/image/b7e998121489252)http://thumbnails37.imagebam.com/12149/ab1cc6121489255.jpg (http://www.imagebam.com/image/ab1cc6121489255)http://thumbnails39.imagebam.com/12149/c19b9c121489256.jpg (http://www.imagebam.com/image/c19b9c121489256)http://thumbnails38.imagebam.com/12149/604972121489261.jpg (http://www.imagebam.com/image/604972121489261)

even on 4/3 DivX files: http://thumbnails37.imagebam.com/12149/bbb222121489267.jpg (http://www.imagebam.com/image/bbb222121489267)http://thumbnails36.imagebam.com/12149/8d9ec3121489265.jpg (http://www.imagebam.com/image/8d9ec3121489265)

I've got PotP set to enforce the DAR, and <0.41 this settings used to always work like a charm...this is a new problem w/ 0.41, it simply seems to enforce an anamorphic vertical downsize for some reason :o

If I set PotP to use the DAR in 0.41, I get this: http://thumbnails32.imagebam.com/12149/f42c29121489277.jpg (http://www.imagebam.com/image/f42c29121489277)

if I force 2.35 AR in 0.41 I get the right AR: http://thumbnails38.imagebam.com/12149/a8a244121489273.jpg (http://www.imagebam.com/image/a8a244121489273)

if I force the DAR in <0.41, it's fine as ever: http://thumbnails26.imagebam.com/12149/2481a8121489279.jpg (http://www.imagebam.com/image/2481a8121489279)

problem doesn't occur in MPC HC(latest beta on xvidvideo) w/ 0.41: http://thumbnails26.imagebam.com/12149/1f9f72121489269.jpg (http://www.imagebam.com/image/1f9f72121489269)


(1) Is that a new problem with v0.41 or does it occur with older builds (> v0.36), too?
(2) Is it reproducable?
(3) How about the corrupted menus and seekbar? Are these problems still there? Better than in v0.40? Or the same?

1) 2) very much reproducible, and it's been here since 0.37
3) that's 0.41: http://thumbnails35.imagebam.com/12149/372959121489271.jpg (http://www.imagebam.com/image/372959121489271)

I think it's worse? 0.36 has been working like a charm for me, hell started breaking loose w/ 0.37 and it's only gone down hill from there :(

[madshi]

i'm using libmpeg2 with ffdshow and now looks very good (first i was trying libavcodec)
however thank you man ;)
I had tried both libavcodec and libmpeg2 and both worked fine for me here. Anyway, glad to hear that the problem is gone now.

[madshi]

I've disabled all post-processing in ffdshow, and
whatever CoreAVC CUDA or ffdshow-mt decoding...same story on all files in PotP(the latest beta I provided you w/)
Ok, I could reproduce the problem and I think it's a bug in PotPlayer. Anyway, I've converted some changes back to how madVR behaved before and the AR problem should be fixed with the next madVR build.

1) 2) very much reproducible, and it's been here since 0.37
3) that's 0.41: http://thumbnails35.imagebam.com/12149/372959121489271.jpg (http://www.imagebam.com/image/372959121489271)

I think it's worse? 0.36 has been working like a charm for me, hell started breaking loose w/ 0.37 and it's only gone down hill from there :(
Let me explain where this problem is (probably) coming from:

madVR v0.36 and older versions allowed Direct3D to do whatever it wanted. And Direct3D does want to reset the GPU output mode whenever it switches from exclusive -> windowed mode. This GPU output mode switch does not really make sense, though, since nothing has changed, really. So since v0.37 madVR hooks into Direct3D to prevent the GPU output mode switch from being executed. The positive aspect of this change is that the mouse cursor shouldn't move to the middle of the screen, anymore (happened to some people, depending on GPU, OS and driver version), and that the overall exclusive -> windowed mode switch should be slightly faster. The negative aspect seems to be that a few (very few) people now experience this cosmetical problem of half-drawn windows.

I think I've found a solution to force all windows to be drawn correctly. This will be implemented in the next build and will likely fix the problem. If all else fails, I can add an option to allow the GPU output mode switch to execute. That should restore the madVR v0.36 behaviour. But I would really like to avoid that, if I can help it.

[madshi]

madvr freezes with several .flv files in mpc-hc. the playback is fine but the mouse controls become unresponsive. i have to kill mpc-hc to get it to stop. this is with version 0.41
I've tested a "Flash Video 4" FLV file with MPC Decoder and with ffdshow, no problems. I've also tested a h264 FLV file with MPC Decoder, ffdshow, CoreAVC and DivX decoders, also no problems.

I need a sample with which I can reproduce the mouse control unresponsiveness. Also I need to know which splitter and decoder you're using.

Maybe anyone else can reproduce the problem?

[fps]

I already posted this in the LAV Filters thread, but unfortunately nevcairiel doesn't know what's going wrong on my end so here is my story again:

I'm having some trouble with the LAVAudio decoder + madVR. Whenever I use LAVAudio decoder + LAVSplitter to play a H.264/AC3 file I get stuttery playback with madVR.
It doesn't change wheter it's FSE mode or windowed mode, there are a lot of dropped and delayed frames all the time.
I have the same problem on 2 different machines, one is a notebook with a Nvidia GPU, the other a standalone pc with an AMD GPU.
If I switch to another audio decoder like ffdshow's one and still use LAVSplitter the problem is gone.
Changing to EVR-CP renderer and keeping the LAVAudio decoder + LAVSplitter solves the problem, too.

I also noticed another problem. Whenever I try to switch between audio tracks via the system tray icon of madVR, the player crashes.
This doesn't depend on the audio decoder however, it seems to be just a problem of the combination LAVSplitter + madVR.

I created two logs (http://www.mediafire.com/?l27jde4f9d9z3ft). The first one shows the frame dropping problem. After about 10s I switched to FSE mode.
The second log shows the switching audio tracks problem.

Setup:
MPCHC 1.5.1.2946
CoreAVC 2.0 (tried ffdshow too)
madVR 0.41 (all settings to bilinear and disabled 16bit processing)
Win7/32
NVidia Geforce Go 7400

Hopefully you can find what's the problem's cause :).

[nevcairiel]

Yeah no idea about the stuttering. I have been using madVR for ages, and never seen anything like this.

About the crash, though.
Does the stream switching work properly when you use the options in MPC-HC instead of the madVR interface?
I never actually tried to use it, i dislike that everyone adds their own context menu with stuff like this. :p

[fps]

Switching via the context menu is working (via the LAV context menu entry).

[madshi]

I'm having some trouble with the LAVAudio decoder + madVR. Whenever I use LAVAudio decoder + LAVSplitter to play a H.264/AC3 file I get stuttery playback with madVR.
It doesn't change wheter it's FSE mode or windowed mode, there are a lot of dropped and delayed frames all the time.
Hmmmmm... I can see what madVR is not doing, although it should. But I'm not sure why. I'll add some more logging output to the next build. I'll need a new log from you then.

I never actually tried to use it, i dislike that everyone adds their own context menu with stuff like this. :p
madVR's context menu is the prettiest, though... :p

[nevcairiel]

Switching via the context menu is working (via the LAV context menu entry).

I just fixed a locking problem that could cause the splitter to deadlock when stuff was being called in a certain order. I didn't see any crash though, unless that was in your case being caused by a deadlocked splitter .. somehow.

[madshi]

I can reproduce MPC-HC deadlocking here, when switching streams via madVR's tray icon menu (IAMStreamSelect), when LAV Splitter is used. No crash here.

[fps]

Sorry, I guess I was not very clear. The player doesn't crash when switching audio tracks, it just freezes and i have to terminate it via the task manager.
Will report back when the new build is available.

[nevcairiel]

Sorry, I guess I was not very clear. The player doesn't crash when switching audio tracks, it just freezes and i have to terminate it via the task manager.
Will report back when the new build is available.

Yes that should be fixed for the next version.

[ikarad]

I've already answered that a couple of pages before.


Thanks.
Your last answer was
I think a "dropped" and "repeated" frames counter is much more useful than these graphs. madVR does not count "repeated" frames yet, though.


.
But I don't know if you expect to add these counters in a next version (at this time of your answer, the current version was 0.36)

[Mangix]

I've tested a "Flash Video 4" FLV file with MPC Decoder and with ffdshow, no problems. I've also tested a h264 FLV file with MPC Decoder, ffdshow, CoreAVC and DivX decoders, also no problems.

I need a sample with which I can reproduce the mouse control unresponsiveness. Also I need to know which splitter and decoder you're using.

Maybe anyone else can reproduce the problem?

i just did a reinstall of windows 7 sp1 and i'll see if i can reproduce it. if i can, i'll edit this post with a link to a sample or something.

[madshi]

Your last answer was [...]

But I don't know if you expect to add these counters in a next version (at this time of your answer, the current version was 0.36)
That was not my last answer. Anyway, I do plan to add a "repeated frame" counter, but I cannot technically do that with the current presentation logic. It will come in a future madVR version. Might take a couple of weeks.

i just did a reinstall of windows 7 sp1 and i'll see if i can reproduce it. if i can, i'll edit this post with a link to a sample or something.
Please make a new post then. Edited posts are too easy to miss. Thx.

[noee]

Just installed .41. Does not seem to work anymore with jRiver (still running the same MC version before installing .41). I get a very strange presentation, half of the video window is solid green and the other half contains the movie, albeit, scrunched up to fit. Back to .39 and all is well.

[ikarad]

That was not my last answer. Anyway, I do plan to add a "repeated frame" counter, but I cannot technically do that with the current presentation logic. It will come in a future madVR version. Might take a couple of weeks.
.

Thanks a lot.

[Vovanchik]

http://forum.doom9.org/showthread.php?p=1445843#post1445843
in this case is now 0.41 does not jump on the primary monitor, but simply revealed by extended in windowed mode, ignoring the exclusive
old wrong method from the end of the post continues to operate correctly
win7x64sp1 ati5770_11.2

[madshi]

still have menu disappearing at times, in addition to old frame etc.
Please try with v0.42, should be fixed now.

I think it's worse? 0.36 has been working like a charm for me, hell started breaking loose w/ 0.37 and it's only gone down hill from there :(
Please try v0.42, hopefully all problems should be fixed now.

Whenever I use LAVAudio decoder + LAVSplitter to play a H.264/AC3 file I get stuttery playback with madVR.
Can you please make a new log with v0.42? I've added some new output information that might help figuring out what's going on.

Just installed .41. Does not seem to work anymore with jRiver (still running the same MC version before installing .41). I get a very strange presentation, half of the video window is solid green and the other half contains the movie, albeit, scrunched up to fit. Back to .39 and all is well.
Fixed in v0.42.

http://forum.doom9.org/showthread.php?p=1445843#post1445843
in this case is now 0.41 does not jump on the primary monitor, but simply revealed by extended in windowed mode, ignoring the exclusive
old wrong method from the end of the post continues to operate correctly
win7x64sp1 ati5770_11.2
I don't really understand what you're saying. You're saying madVR goes into exclusive mode on the wrong monitor? Please make sure that you move the media player to the right monitor *before* you load the video file. If you load the video file first, and move the media player to the other monitor afterwards, you'll run into problems. That problem will be fixed in a future madVR version.

[madshi]

madVR v0.42 released

http://madshi.net/madVR.zip

* changed aspect ratio reporting back (PotPlayer and JR MC didn't like v0.41)
* improved forced redrawing of all GUI stuff after exclusive -> windowed switch
* removed some of the "disable desktop composition" modes

[ajp_anton]

When the Windows 7 magnifier is active (with or without magnification), the mouse arrow/hand isn't visible in exclusive mode.
(I sometimes use the magnification since I sit much farther away from the screen when watching movies, but need to navigate some menus.)

This also happens with other renderers that have an exclusive mode or similar, so not sure if there's anything you can do about it...

[Vovanchik]

move media player to the right monitor *before* you load the video file
Yes, it works. Thanks.
http://s1.directupload.net/images/110228/3hatfmgb.jpg (http://s10.directupload.net/images/110228/8udc8b7b.jpg)
With this setting, move player *before* does not need

why in the exclusive GUI does not show the current time / remaining?

sorry for bad english

[fps]

Can you please make a new log with v0.42? I've added some new output information that might help figuring out what's going on.
Wow that was quick :thanks:.
Here's the new log (http://www.mediafire.com/?nbrdwuc0awqktrf).
I switched to FSE at about 10s again and back to windowed mode at roughly 20s.


why in the exclusive GUI does not show the current time / remaining?
If I recall correctly this is on madshi's todo list and will be implemented later on.

[leeperry]

:thanks: for the new build!

the AR problem in PotP is solved, indeed :)

the zombie frames problem and the partially refreshed menus are solved as well, but the movie "jumps" back and forth when going FSE>FSW...it used to be a lot smoother, only dropping a few frames...now it really stutters and "blinks" back and forth. Also, sometimes the bottom transport bar doesn't appear completely and only the PotP seekbar itself shows up.

After making the bottom transport bar appear and disappear like 30 times in a row, I even got a windows (GDI?) error message stating that there was a memory leak in progress?! It was written in a windows 95/NT4 style msg box and disappeared instantly, huh? I couldn't capture it. I would really appreciate an option to get the <.37 behavior back please, as it was working like a charm and no stutter nor legacy system error msg's when going FSE>FSW :o

[underzone]

leeperry, where can I get this leeperry skinned potplayer I hear about? I assume I still use ffdshow from the xvid.ru source with it yeah?

[adam777]

still have menu disappearing at times, in addition to old frame etc.

Please try with v0.42, should be fixed now.


Unfortunately, not.
But as I've said before it happens only with "disable desktop composition" and it really is not a big issue (another right click, that's all :) )
Moreover, unless someone else is having a similar behavior, might be some weird behavior of my machine...
:thanks:

[HoP]

madVR support intel graphic accelerator??
if no...when it will support it??

[DigitalLF]

HoP: Never, to slow.

[cyberbeing]

What cca describes sounds almost identical to my symptoms with Fullscreen Exclusive (3 buffers, weird stuttering, out-of-order frames), except I'm using a single NVIDIA card on WinXP.

I was fiddling around with this a bit, and it seems that if I set VSync to Force Off for MPC-HC, the weird stuttering goes away. In exchange I get screen tearing.

While not particularly helpful, it does confirm that madVR is enabling the NVIDIA hardware VSync when in fullscreen exclusive on my system. Tearing with VSync set to Force Off also confirms that madVR Fullscreen Exclusive VSync is also effectively disabled.

What you've been saying about working on a Final Render Path for Fullscreen Exclusive now makes a bit more sense. The problem is the current render path breaking hardware Vsync when enabled, rather than Vsync not enabling at all.

[Mangix]

no clue how to make a sample so i uploaded a whole file. it's only around 3 megs though.

http://www.sendspace.com/file/ww7vvr

running mpc-hc with stock decoders, madVR 0.42, nvidia geforce 450 gts 1gb, 265.68 drivers, windows 7 sp1, 1680x1050 60Hz. no clue what else is useful.

edit: just realized i wasn't using stock decoders at all. it's microsoft's decoder's fault.

[ajp_anton]

Just realized how insanely fast the exclusive mode switch is with the new versions. It's almost scary, I barely see any difference between it and "windowed" fullscreen anymore.
Using Win 7 x64, "disable desktop composition" is unchecked.

[ryrynz]

The negative aspect seems to be that a few (very few) people now experience this cosmetical problem of half-drawn windows.


I used 0.40 for about a minute, skipping through a video I had managed to create serious window garbage all over the screen. Once I closed MPC I started playback again everything was good, I've only used 0.40 once for a hour or so. I will try out 0.42 tonight, Like Leeperry I find 0.36 to be my preference thus far.

I would love to see a feature in MadVR where the name of the file playing back is displayed for a defined time in the same way that the exclusive mode message displays. Would anyone else find that useful?

After using 0.42 for a minute I see when the MPC window resizes as I double click, the image becomes pixelated for a second and the image does a second stretch to fit.
0.36 performs better most of the time in this area but still had the ocassional pixelated image, it also displayed the last viewed frame now and then which I haven't seen happen in 0.40 & 0.42

One issue which has happened twice so far is, as MPC plays the next file in the folder automatically I have my task bar appear. Aero then switches modes and my task bar stays visible and non transparent as the movie plays, however I can't reproduce it.
Great to see that when this doesn't happen the next file plays back without the previous frame popping up and the screen remains black until the next file plays, nice!

[dansrfe]

Just realized how insanely fast the exclusive mode switch is with the new versions. It's almost scary, I barely see any difference between it and "windowed" fullscreen anymore.
Using Win 7 x64, "disable desktop composition" is unchecked.

I know, right? The funny thing is that each version just gets smoother and smoother for me on the windowed -> exclusive transition. Basically no difference between the two now lol. Desktop Composition off here as well.

[madshi]

When the Windows 7 magnifier is active (with or without magnification), the mouse arrow/hand isn't visible in exclusive mode.
(I sometimes use the magnification since I sit much farther away from the screen when watching movies, but need to navigate some menus.)

This also happens with other renderers that have an exclusive mode or similar, so not sure if there's anything you can do about it...
I don't think there's anything I can do about it. In exclusive mode nobody else it allowed to draw on the screen except madVR. That's the very definition of "exclusive". madVR has exclusive access to the drawing.

Wow that was quick :thanks:.
Here's the new log (http://www.mediafire.com/?nbrdwuc0awqktrf).
I switched to FSE at about 10s again and back to windowed mode at roughly 20s.
Ok, I think I know what's going wrong, I'll post the follow up to the LAV thread, cause it seems to be a bug caused by the LAV audio decoder.

the zombie frames problem and the partially refreshed menus are solved as well, but the movie "jumps" back and forth when going FSE>FSW...it used to be a lot smoother, only dropping a few frames...now it really stutters and "blinks" back and forth. Also, sometimes the bottom transport bar doesn't appear completely and only the PotP seekbar itself shows up.
Oh well. Ok, I've changed some things back to the way v0.36 behaved - but only for Windows XP. I think the behaviour in XP was always fine. Most of the changes for improved exclusive -> windowed switching are now Vista (and newer) exclusive. Hope that you'll be back to v0.36 standards with the next build.

madVR support intel graphic accelerator??
Generally Intel DX9 is supported, but it's rather slow, so if you want to get smooth playback, you'll have to compromise on scaling algorithms.

I was fiddling around with this a bit, and it seems that if I set VSync to Force Off for MPC-HC, the weird stuttering goes away. In exchange I get screen tearing.

While not particularly helpful, it does confirm that madVR is enabling the NVIDIA hardware VSync when in fullscreen exclusive on my system. Tearing with VSync set to Force Off also confirms that madVR Fullscreen Exclusive VSync is also effectively disabled.
Interesting. Probably the exclusive mode is simply disabled when you force VSync off.

no clue how to make a sample so i uploaded a whole file. it's only around 3 megs though.

http://www.sendspace.com/file/ww7vvr

running mpc-hc with stock decoders, madVR 0.42, nvidia geforce 450 gts 1gb, 265.68 drivers, windows 7 sp1, 1680x1050 60Hz. no clue what else is useful.

edit: just realized i wasn't using stock decoders at all. it's microsoft's decoder's fault.
Thanks for the sample. I've tried in Windows 7 x64 SP1 with an MS decoder, but I couldn't reproduce any problems. Which MS decoder were you using exactly? What did MPC-HC say about the decoder? And please upload a debug log for me, if possible. Thanks.

Just realized how insanely fast the exclusive mode switch is with the new versions. It's almost scary, I barely see any difference between it and "windowed" fullscreen anymore.
I know, right? The funny thing is that each version just gets smoother and smoother for me on the windowed -> exclusive transition. Basically no difference between the two now lol. Desktop Composition off here as well.
Happy to hear some positive feedback about the exclusive -> windowed switch improvements!

I used 0.40 for about a minute, skipping through a video I had managed to create serious window garbage all over the screen. Once I closed MPC I started playback again everything was good, I've only used 0.40 once for a hour or so. I will try out 0.42 tonight, Like Leeperry I find 0.36 to be my preference thus far.
Which OS are you using? Which GPU? Which madVR desktop composition settings are you using? Do you have Aero generally enabled/disabled?

[cyberbeing]

Interesting. Probably the exclusive mode is simply disabled when you force VSync off.

What makes you think that? Exclusive Mode (Vsync forced off) is not identical to Windowed mode where I get perfectly smooth playback with no tearing. The madVR GUI and stats believes it is in Exclusive mode as well. Would a Debug build log pick that up?

I was assuming Force Off Vsync would just be like running any Direct3D app in Fullscreen Exclusive without Vsync, since Vsync is just an optional feature which can be turned on and off.

I wish there was some way I could help you debug the problem, since I can't exactly send you my GPU.

[madshi]

What makes you think that? Exclusive Mode (Vsync forced off) is not identical to Windowed mode where I get perfectly smooth playback with no tearing. The madVR GUI and stats believes it is in Exclusive mode as well. Would a Debug build log pick that up?

I was assuming Force Off Vsync would just be like running any Direct3D app in Fullscreen Exclusive without Vsync, since Vsync is just an optional feature which can be turned on and off.

I wish there was some way I could help you debug the problem, since I can't exactly send you my GPU.
Well, it doesn't matter, anyway, the final exclusive mode rendering path is coming soon and should fix the problem you're having.

[ryrynz]

Which OS are you using? Which GPU? Which madVR desktop composition settings are you using? Do you have Aero generally enabled/disabled?

On the HTPC that I saw the window garbage appear I'm running a HD5670 with Win7 x64 with Aero enabled.

[madshi]

On the HTPC that I saw the window garbage appear I'm running a HD5670 with Win7 x64 with Aero enabled.
Which madVR desktop composition settings are you using? Can you reproduce the problem with v0.42?

[ryrynz]

Disabled while in fullscreen mode.

I've found an issue I can duplicate on this machine using 0.42.

Using MPC, if I expand to fullscreen and bring it back to normal window mode by double clicking on the window while watching a video I get Aero eventually changing modes in an endless loop.
I've can replicate this problem usually within twenty seconds by constantly double clicking.
This is with exclusive mode is disabled and desktop composition disabled in fullscreen.

I've noticed the resizing pixelation and stretching I mentioned earlier during fullscreen resize does not occur when exclusive mode is disabled.

When exclusive mode is disabled and when I have both options disable desktop composition and only in fullscreen mode ticked Aero still goes through a changing of modes (enabling and disabling) for a couple of seconds and the video playback lags for a bit as this happens, using Windows 7 x64 with HD4890 & Cat 11.2.

[mark0077]

madshi, very impressed with the latest improvements. Just a query regarding the processing madvr does. I've been using / tweaking some avisynth scripts to change frame rate of my 1080p clips on the fly from 24 -> 50 fps lately. When I push these scripts higher and higher quality wise I obviously get to a point where I begin to see frame drops. The frame drops come at an earlier stage with madVR than evr-cp for example but thats expected due to the higher level of processing its doing.

My question is, does madVR do much processing on the cpu at all? And if so can any of it be improved as in spreading the load accross more cores? The biggest improvement in terms of reducing frame drops with these scripts was to choose decoders that are multithreaded so thought it would be worth while to ask yourself if your cpu dependent code is already multithreaded or not or if it would even be of benefit. Thanks.

[cyberbeing]

madVR is almost entirely GPU, so CPU use should be minimal (avg < 3%). If you are getting dropped frames in this situation, either your script isn't fast enough (can't keep decoding queue full), or your GPU isn't fast enough (can't keep render queue full). madVR is very aggressive at dropping/delaying frames to keep sync when things slow down, if using a frame rate multiple refresh rate.

[mark0077]

Yeah, if I pass a native 50 / 60 fps clip to madVR, theres no issues, 0 frame drops so the GTX295 has no issues. madVR must use more cpu than evr-cp then as madVR will drop more frames than evr-cp with the same avisynth scripts... as I assume madVR is tipping my cpu usage over the limit when evr-cp isn't with the same scripts..

[fastplayer]

madVR is almost entirely GPU, so CPU use should be minimal (avg < 3%).
On my 2.4GHz dual-core it uses at least twice as much CPU as EVR-CP: ~3200kbps H.264 hovers around 15-20% with EVR-CP, with madVR it's 35-40%.

[mark0077]

Some users on avsforums are adament that to maximize quality (avisynth script wise), I shouldn't use madVR but I'm hooked on using madVR so am just hoping there might be room for some improvement somewhere that will bring its cpu usage down a tad if possible?

[fps]

On my 2.4GHz dual-core it uses at least twice as much CPU as EVR-CP: ~3200kbps H.264 hovers around 15-20% with EVR-CP, with madVR it's 35-40%.

Are you sure you're not running a DXVA decoder with EVR-CP?
On my notebook there's hardly any difference in CPU usage.

[fastplayer]

Are you sure you're not running a DXVA decoder with EVR-CP?
On my notebook there's hardly any difference in CPU usage.
DXVA is off, always and forever.

[Luv]

On my 2.4GHz dual-core it uses at least twice as much CPU as EVR-CP: ~3200kbps H.264 hovers around 15-20% with EVR-CP, with madVR it's 35-40%.

What is you .264 decoder ?