madVR - high quality video renderer (GPU assisted)

[Peuj]

Thanks, the renderer thread seems to be stuck somewhere. I'll try to find out what happened. Can you reproduce the problem, or was it a one-time problem?

No I didn't reproduce since.
I had an issue in the same situation before this one.
After the switch to another video madVR could not use "Exclusive mode".
I don't remember the error exactly and the log was not activated...

If I have more logs I'll post them.

[madshi]

Madshi, when I switch between exclusive mode and windowed mode and then back to exclusive mode again when MPC loads the next file in the folder automatically after reaching the end of the currently playing file, MPC drops back to windowed mode for a second shows a previous frame then goes back to fullscreen. MPC will sometimes crash as it transitions to the next file which I haven't reproduced with other renderers. While producing the log I did have MPC hang at the end of playback, hopefully it can help you find the problems.
Please look into the minimizing just before the new file beings playback. The crash could be unrelated, I haven't experienced enough crashes for me to think it's related to madVR.

I can easily reproduce by playing a file, and maximizing the screen and seeking to the end of the file. Once MPC transitions to the next file in the folder, MPC drops to a normal sized window displays a previously played frame then maximizes again, this only occurs when exclusive mode is enabled.
I've tried, but I can't seem to be able to reproduce this problem. Still using an older MPC HC version (1.3.2273.0) here, though. Maybe it behaves different to the version you're using? Please try toggling the 2 options "Playback -> Fullscreen -> Launch files in fullscreen" and "-> Exit fullscreen at the end of playback". Maybe that helps?

[madshi]

At first I thought you and I were talking about something different entirely, but I guess I just explained it poorly.

Right clicking on the video to bring up MPC-HC's menu causes madVR to go from exclusive -> windowed -> exclusive/fullscreen windowed in a very short period of time, but the menu still successfully appears and is functional. As I said before, more of an annoyance than anything. I'll try to get a video of it to clear up the confusion.
I'm not sure exactly what is happening, but the log doesn't confirm that exclusive -> windowed -> exclusive switch. The log looks clean. So my best guess is that you're using Vista or Windows 7 and have Aero activated. In that situation when switching from exclusive mode to windowed mode, sometimes an older video frames is shown by Aero. My guess here is that that old frame makes things looks other than they really are. Right now I think it's just a cosmetical problem caused by Aero caching an older video frame. But just to be safe: Would it be difficult to create a video of that problem situation?

[Mercury_22]

...
- hardware accelerated video decoding (DXVA) is currently not supported
- hardware accelerated deinterlacing (DXVA) is currently not supported
From this I understand that you will add DXVA so when will this be happening ? (it's a low priority, it's a very low priority...or...?)

P.S. I think you should add this ... Let me state again that madHcNet.dll does *NOT* contact the internet, or "dial home" or anything of that sort. .... to your first post (and maybe with more info about it :) )

[madshi]

From this I understand that you will add DXVA so when will this be happening ? (it's a low priority, it's a very low priority...or...?)
It's one of the many things I want to look into before reaching version v1.0. I can't really say if I can make DXVA work without any image quality loss. I hope so, but I'm not sure yet. I also can't say when DXVA support will be ready, I don't know that myself...

P.S. I think you should add this to your first post (and maybe with more info about it :) )
Done.

[madshi]

madVR v0.32 released

http://madshi.net/madVR.zip

* fixed: calculation of estimated frame drops/repeats was incorrect
* fixed: one madVR shutdown crash cause
* fixed: log file was held locked even after madVR finalization
* simplified tray icon menu structure (less submenus)
* left and right click on tray icon shows different context menus now
* added monitor/receiver device management functionality to settings logic
* monitor/receiver devices are now automatically detected and identified
* monitor related settings are now stored separately per monitor device
* ffdshow is not asked for audio/subtitle streams, anymore (stability issues)
Some comments:

(1) I've removed the older madVR versions from the download now, since they're all available here:

www.videohelp.com/tools/madVR

(2) Left clicking on the tray icon now produces a much more "direct access" context menu - but this new feature works only if there's only one media player instance running. If there are multiple madVR instances running, left clicking on the tray icon produces the same full context menu as right clicking.

(3) The new device functionality (see settings dialog) is just a first step. Currently the only real benefit is that you can define PC vs. video levels per display device. You can also switch 3dluts on/off per display device now, but the same 3dlut files are always used for all display devices in the current madVR version. Of course that will change in a future version, also some other per device settings will be introduced in future madVR versions.

I hope that the new device functionality is intuitive enough so that I don't have to explain how it's supposed to be working. Just give it a try and report your impressions.

[noee]

Very cool. madHCcontrol picked up both of my monitors, all I had to do was set device type.

The tray icon menu control is good with l/r. However, for movies with many, many chapters, the "Close" item is way down the scroll. YOu might consider moving it up after the Stop item or somewhere up there.

Clock deviation now shows 0.00262% with a frame repeat every 1.17-1.20hrs. (23.976fps @ 23.97691 refresh rate)

[Razoola]

I will do the tests you mention before but I have just tried .32 and get a problem of dropped and delayed frame happening at the same time (both numbers increment at the same time). Please see log.

http://unibios.free.fr/mad032log.zip

[madshi]

The tray icon menu control is good with l/r. However, for movies with many, many chapters, the "Close" item is way down the scroll. YOu might consider moving it up after the Stop item or somewhere up there.
Do you have a (very short) sample for me with so many chapters?

Clock deviation now shows 0.00262% with a frame repeat every 1.17-1.20hrs. (23.976fps @ 23.97691 refresh rate)
Does the match your experience? No frame drops during movie playback, max 1 frame repeat per movie? The frame repeat may not be noticeable, and madVR doesn't show it in the stats...

I will do the tests you mention before but I have just tried .32 and get a problem of dropped and delayed frame happening at the same time (both numbers increment at the same time). Please see log.
According to the log you're borderline on rendering times. The rendering queue seems to be stuck at 2/8, which is dangerously low. Maybe your scaling settings are too high for your GPU? You could also try changing all flush & wait settings to only flush. That should help the queues to fill better, I think. That will probably only work well in exclusive mode, though, and maybe not even there...

[noee]

Do you have a (very short) sample for me with so many chapters?

Well, I'm dial-up right now, so.... But, I was using "Empire Strikes Back" as the test bed, it has 50 chapters in the MKV I created. The madHC menu is "taller" than my screen, so I get the scroll arrows top and bottom.


Does the match your experience? No frame drops during movie playback, max 1 frame repeat per movie? The frame repeat may not be noticeable, and madVR doesn't show it in the stats...


Yes. I was curious about the frame repeat and whether or not it would even happen. I certainly can't see it with my setup.

HD2600XT, CCC10.3, Win7 x64, Aero OFF, dual-mon (pri 60Hz, sec 23.976Hz (playback), both 1920x1080)
HMS/FFDshow/madVR (FSE)/MPC-HC b2612
3Dlut OFF|Spline64|Spline64|Bicubic75
flush|flush and wait(sleep)|don't|don't

[Razoola]

According to the log you're borderline on rendering times. The rendering queue seems to be stuck at 2/8, which is dangerously low. Maybe your scaling settings are too high for your GPU? You could also try changing all flush & wait settings to only flush. That should help the queues to fill better, I think. That will probably only work well in exclusive mode, though, and maybe not even there...

I dont understand, I did not have this problem before with the gpu not being fast enough and its the same gpu, it was handling everything fine with the default scaling settings.

Do the flush settings also effect exclusive mode then? I took it that because they are under the window mode tweaks they have no effect in exclusive mode.

As to the tearing I have now in window mode, I have gone all the way back to 023 and the problem still happens. This was certinally not happening before so I think this is a driver problem although this tearing does not happen with other renderers.

[madshi]

I dont understand, I did not have this problem before with the gpu not being fast enough and its the same gpu, it was handling everything fine with the default scaling settings.
Well, I haven't changed anything in v0.32 compared to v0.31. But it's possible that the new frame drop logic (introduced in v0.27) doesn't work so well for you. It drops frames rather quickly if the rendering queue is in trouble. I think the final exclusive mode rendering path (which I've not implemented yet) will take care of the problem for you.

Do the flush settings also effect exclusive mode then? I took it that because they are under the window mode tweaks they have no effect in exclusive mode.
You're right that the settings structure suggests that the flush settings don't affect exclusive mode - and that is the plan for the final exclusive mode rendering path. The current exclusive mode rendering path is a temporary solution. It's almost identical to the windowed mode rendering path and it is affected by the flush settings.

[Razoola]

You're right that the settings structure suggests that the flush settings don't affect exclusive mode - and that is the plan for the final exclusive mode rendering path. The current exclusive mode rendering path is a temporary solution. It's almost identical to the windowed mode rendering path and it is affected by the flush settings.

Ok, I think this is a pointer to the other problem you wanted me to test regarding my issue with exclusive mode not being as as smooth as windowed mode.

My flush settings are the default (flush, flushwait sleep, dont flush, dont flush), so are the scaling options.

In fullscreen windows mode I always see in the stats;

upload queue 7-8/8
render queue 7-8/8

In exclusive mode I see;

upload queue 3-4/8
render queue 2-3/8

and sometimes it drops to;

upload queue 2-3/8
render queue 1-2/8

So my first question has to be, what can be causing exclusive mode to be much slower than windows mode with identical settings?

Now if I change the flush after last render step to 'flush' only my exclusive mode queues jump to 7-8/8 for both upload and render and then only sometimes drop to 6-8/8.

This is when viewing on secondary gpu (GT240) to secondary monitor. On primary gpu (gtx295) to primary monitor I don't see this issue.

Whats happening?

[madshi]

In fullscreen windows mode I always see in the stats;

upload queue 7-8/8
render queue 7-8/8

In exclusive mode I see;

upload queue 3-4/8
render queue 2-3/8

and sometimes it drops to;

upload queue 2-3/8
render queue 1-2/8

So my first question has to be, what can be causing exclusive mode to be much slower than windows mode with identical settings?
I'm not sure, but I think this is caused by the "flush & wait" not working 100% correctly in exclusive mode. I think the "wait" often waits too long, which results in the queues not filling up properly. As I said, I believe the final exclusive mode rendering path will take care of this problem.

Now if I change the flush after last render step to 'flush' only my exclusive mode queues jump to 7-8/8 for both upload and render and then only sometimes drop to 6-8/8.
Is playback smooth for you this way? If so, then great! Problem solved. I think for the current temporary exclusive mode rendering path avoiding "flush & wait" is probably a good idea, as long as it doesn't introduce any new problems. I've sometimes seen stuttering problems when not using "flush & wait", but I think that was only in windowed mode. Not 100% sure right now, though...

[Thunderbolt8]

how does that work with the monitor identification? my syncmaster 226 has been identified as unknown at first and then I can choose between some options. so what am I going to choose, digital monitor / TV?
what happens when I choose the wrong setting or leave it unkown?

and in how far is the clock for dropped frames useful? Ive watched a movie for about 4 mins and during that time the display went up from 1 dropped frame every 3X seconds to 1 dropped frame every 4X seconds, but actually not a single frame was dropped during that 5 minutes duration. by that speed, the precise value of how long it actually takes for a single frame to be dropped would be reached by the end of the movie (well, maybe not exactly, but you get the idea). in how far is this then still useful?

edit: hm strange, on my PC screen its dropped frames and on my TV & laptop repeated frames. ? :S

[XPC]

I've checked out the logs and from what I can see, madVR accepts the switching just fine, but the decoder doesn't start sending frames, for whatever reason. I don't know why...

Is there an easy way for me to reproduce these problems on my own PC?

The easiest way would be plugging a DVB-t tunner to your PC and start switching channels. You don't need an expensive device, even a simple USB dongle would do.

Otherwise I can keep debugging, but it will take longer to find out what is happening on each side.

[Razoola]

Is playback smooth for you this way? If so, then great! Problem solved. I think for the current temporary exclusive mode rendering path avoiding "flush & wait" is probably a good idea, as long as it doesn't introduce any new problems. I've sometimes seen stuttering problems when not using "flush & wait", but I think that was only in windowed mode. Not 100% sure right now, though...

Its was smoother but not totally smooth.

I have done some more experimenting however and have discovered something really intresting but it goes against everything I thought. Basically the slowdown I have in the exclusive mode queues was being caused by the fact that I had desktop composition disabled! If I keep composition enabled then exclusive mode queues are no longer limited, I can keep flush&wait setting after render step and have full queues still. Now I get smooth playback in exclusive mode :)

This means for me at least the following in my dual monitor duel gpu setup on win7 x64.....

Desktop composition must be _disabled_ in fullscreen window mode on secondary monitor for smooth playback.

Desktop composition must be _enabled_ in fullscreen exclusive mode on secondary monitor for smooth playback.

I just don't get why desktop composition should be effecting exclusive mode in any way. Maybe its because your exclusive mode path is almost identical to windows mode?

The good news however is I have exclusive mode working as well as windows mode now. I just need to work out how I can remove this windows mode tear that has introduced itsself, I'm sure its a nvidia driver issue or something else and not madVR though.

[Vovanchik]

If ffdshow/avisynth don't do that, I consider that a bug in ffdshow/avisynth.
The fact that this situation is activated evr or wmr9 renderers (the others do not know how to look osd) they display the correct fps, changes inside ffdshow
(support avisynth uses the built inside the ffdshow)

future madVR version will take care of that problem
it`s good

Ideally, the media type information should be correct.
the fact is that the world is not perfect
))

What purpose does "ConvertFps" have?
Well here are some other algorithm. avisynth mvtools2.dll calculates new frames. You can pick up the multiplier and divider so that the final frame rate was equal to any value. for example, the initial frequency of 23.976 video multiplier 403, divider 161 - the final frequency of 60.14 - the frequency of your monitor while 60.15
but a great divider - more discarded the original frame and is new, artificially calculated. this reduces image quality and increases the load on the processor.
so there is better to proceed as follows multiplier 5, the divisor 2 - Final 59.94. but it is not the same as the frequency of your monitor and there are jerks images every second. ConvertFps in turn allows you to hang on to the fps rate monitor by dissolving frames.
Why not make initially 23.976 -> 60.15 through ConvertFps? effect is not the same - it works by dissolving the original thread, and calculates the new mvtools based on available. analogue of this technology include Philips DNM
By the way you can try - there are English interface, not count them for advertising
http://rimsky.net/MAG79/Smooth_video_pack_1.4.exe

[leeperry]

:thanks: for the new version, the display identification looks promising...w/ discrete LUT's, this would be a straight banger :eek:
You're not really supposed to switch refresh rates behind madVR's back. But anyway, "For a few seconds" is not what I would expect.
Well, sometimes I'm in a 25Hz multiple and realize that a file is 29.97fps so I click on one of the shortcuts in my start menu..quick and effective! I used to not dare doing it, but then I realized that the ppl using the .vbs script in Reclock are doing it all the time, and it used to work wonders :)

There's been many undocumented fixes in PotPlayer lately, and it's working as fast as it used to again w/ 0.32...I'll come back w/ a log if it glitches up, but this seemed to be very rare, I only saw it once or twice w/ 0.31 tbh.
Hmmmmm... How many loops are in each log? I've a bit confused by the logs. In the FSE log there's a "flush" every 2.5 seconds. In the windowed log there's a flush every 2.0 seconds. So the loop was about 2-2.5 seconds? Did you use different loop intervals for FSE and windowed testing (2.5 seconds vs. 2.0 seconds)? One thing that irritates me is that in the windowed mode log it takes about 400ms after every flush, before the decoder starts sending new frames again. But for FSE mode there's no such delay. Another thing irritating me is that in the FSE log you seem to switch between windowed and exclusive mode at least twice, but not for every loop.

Can you describe the "hiccup"? How does it look like? Does madVR list dropped frames when the hiccup occurs?
Yes I was using different intervals, and basically the first frames of the loop were dropped in FSE but not in FSW(I didn't enable mVR's OSD, though)...I've tried again w/ the latest version of PotP/ffdshow and 0.32, I can't seem to be able to recreate the problem.

[madshi]

how does that work with the monitor identification? my syncmaster 226 has been identified as unknown at first and then I can choose between some options. so what am I going to choose, digital monitor / TV?
Well, what kind of device is that syncmaster? Is it a projector? Is it a receiver? Is it a CRT? Or is it a digital monitor/TV? I think that should be pretty easy for you to answer. There's no way for madVR to know what kind of device the syncmaster is. That's why madVR classifies the device type as "unknown" first.

what happens when I choose the wrong setting or leave it unkown?
Why would you want to choose a wrong setting? :confused:

Anyway, currently there's no difference between all those device types - except for the "receiver" device type which behaves differently. However, in future there may be differences between the other device types, too. E.g. for a projector maybe madVR will some day offer some kind of convergence correction control. Such a feature would not make sense for a digital monitor/TV, though. So different device types might have different features available in a future madVR version.

You can leave the detected device at "unknown", for now there's no difference. But I don't really understand why you would not want to set it to the correct type.

in how far is the clock for dropped frames useful? Ive watched a movie for about 4 mins and during that time the display went up from 1 dropped frame every 3X seconds to 1 dropped frame every 4X seconds, but actually not a single frame was dropped during that 5 minutes duration. by that speed, the precise value of how long it actually takes for a single frame to be dropped would be reached by the end of the movie (well, maybe not exactly, but you get the idea). in how far is this then still useful?

edit: hm strange, on my PC screen its dropped frames and on my TV & laptop repeated frames. ? :S
The problem is that the audio clock is very "jumpy" (at least if you don't use Reclock). That makes proper measurements very difficult. That's why the drop/repeat estimates change a lot during the first seconds/minutes of playback. Play back a whole movie and then check the stats again at the end of the movie, that should give you a more precise drop/repeat estimate.

There's another reason why you might have no drops, although madVR says you should have drops: E.g. if you have a 47Hz refresh rate and you play back a 24fps movie, madVR pretends that exactly 1 video frame must be shown every 2Hz. Since 47Hz is smaller than 2 * 24fps, the OSD tells you that you will have a lot of frame drops. But because actually 47Hz is bigger than 1 * 24fps, you don't really have any frame drops. But motion will still not be perfectly smooth. So don't take the estimated frame drops/repeats literally. You can understand them as estimated situations of motion judder.

The easiest way would be plugging a DVB-t tunner to your PC and start switching channels. You don't need an expensive device, even a simple USB dongle would do.

Otherwise I can keep debugging, but it will take longer to find out what is happening on each side.
I don't have a DVB-T tuner. Maybe you can record two different channels and when playing the recorded media files via a playlist, the problem can be reproduced without me having to buy hardware that I don't need?

Basically the slowdown I have in the exclusive mode queues was being caused by the fact that I had desktop composition disabled! If I keep composition enabled then exclusive mode queues are no longer limited, I can keep flush&wait setting after render step and have full queues still. Now I get smooth playback in exclusive mode :)

This means for me at least the following in my dual monitor duel gpu setup on win7 x64.....

Desktop composition must be _disabled_ in fullscreen window mode on secondary monitor for smooth playback.

Desktop composition must be _enabled_ in fullscreen exclusive mode on secondary monitor for smooth playback.

I just don't get why desktop composition should be effecting exclusive mode in any way. Maybe its because your exclusive mode path is almost identical to windows mode?

The good news however is I have exclusive mode working as well as windows mode now. I just need to work out how I can remove this windows mode tear that has introduced itsself, I'm sure its a nvidia driver issue or something else and not madVR though.
I don't really understand why desktop composition should affect things. In theory it should not, because as far as I understand, desktop composition should always be disabled when exclusive mode is active, anyway.

Why do you need to find out about that windowed mode tearing, if exclusive mode works fine for you now?

The fact that this situation is activated evr or wmr9 renderers (the others do not know how to look osd) they display the correct fps
Can you post the media type pin information from EVR and madVR? The "AvgTimePerFrame" field is the key field saying which framerate the source has.

Well here are some other algorithm. avisynth mvtools2.dll calculates new frames. You can pick up the multiplier and divider so that the final frame rate was equal to any value. for example, the initial frequency of 23.976 video multiplier 403, divider 161 - the final frequency of 60.14 - the frequency of your monitor while 60.15
but a great divider - more discarded the original frame and is new, artificially calculated. this reduces image quality and increases the load on the processor.
so there is better to proceed as follows multiplier 5, the divisor 2 - Final 59.94. but it is not the same as the frequency of your monitor and there are jerks images every second. ConvertFps in turn allows you to hang on to the fps rate monitor by dissolving frames.
Ok, I see. I don't think it's a good idea to use ConvertFps. IMHO you should try to optimize your display refresh rate instead, trying to get it nearer to 59.94Hz, by using custom timings.

[leeperry]

I had PMed James via SlySoft PM, asking him for doing some Reclock <-> madVR communication, but he didn't seem to be very interested.
I've left a message on the Reclock board about this: http://forum.slysoft.com/showpost.php?p=280220&postcount=145

I guess this would be the best of both worlds :devil:

BTW, I also understand why you added the 3" delay between FSE/FSW, I've seen the PotP menus make mVR go bersek a few times..but it's very rare, and I hardly ever use its menus anyway.

[Peuj]

Hi,

I have some crashes since the new version.
Switching from a video to another makes PotPlayer crashes:
http://www.megaupload.com/?d=U47UZ6I4

I've the default settings and set my HDTV and monitor to "Digital Monitor/TV"

Thanks

[madshi]

There's been many undocumented fixes in PotPlayer lately, and it's working as fast as it used to again w/ 0.32...I'll come back w/ a log if it glitches up, but this seemed to be very rare, I only saw it once or twice w/ 0.31 tbh.

Yes I was using different intervals, and basically the first frames of the loop were dropped in FSE but not in FSW(I didn't enable mVR's OSD, though)...I've tried again w/ the latest version of PotP/ffdshow and 0.32, I can't seem to be able to recreate the problem.
Good to hear.

BTW, I also understand why you added the 3" delay between FSE/FSW, I've seen the PotP menus make mVR go bersek a few times..but it's very rare, and I hardly ever use its menus anyway.
;)

I have some crashes since the new version.
Switching from a video to another makes PotPlayer crashes:
http://www.megaupload.com/?d=U47UZ6I4
The log shows 22 seconds of playback, followed by proper madVR close down. I don't see any indication of a problem in that log. Can you describe in more detail what happens? Does the crash happen *everytime* you start one video and then switch to another? @leeperry, can you confirm that?

FWIW, it doesn't seem to happen for me, but I'm not using the latest PotPlayer version.

[leeperry]

;)
It might come in handy to allow choosing the interval...something like 250/500ms should make the switches smoother and yet not too tardy. Just saying!

[Vovanchik]

Can you post the media type pin information from EVR and madVR?
http://s7.directupload.net/images/100924/b2po94vr.jpg (http://s10.directupload.net/images/100924/5kc9o6dy.jpg)
http://s1.directupload.net/images/100924/ftgguccs.jpg (http://s7.directupload.net/images/100924/wdd367jm.jpg)
http://s13.directupload.net/images/100924/jcz3x84m.jpg (http://s13.directupload.net/images/100924/wawacay7.jpg)
it seems they too are on the wrong fps from ffdshow, but they are counted as correct ...
my bad))
you should try to optimize your display refresh rate instead, trying to get it nearer to 59.94Hz
video can be 25fps... as a result of 25 * 12 / 5 = 60 picture will twitch

[robpdotcom]

.....currently there's no difference between all those device types - except for the "receiver" device type which behaves differently.

Just curious, would you elaborate on how "receiver" is different?

[ryrynz]

I can easily reproduce by playing a file, and maximizing the screen and seeking to the end of the file. Once MPC transitions to the next file in the folder, MPC drops to a normal sized window displays a previously played frame then maximizes again, this only occurs when exclusive mode is enabled.

Would just like to mention that 0.32 still does this for me, I know it's unlikely to be a priority, thank you for the updates Madshi.

[madshi]

it seems they too are on the wrong fps from ffdshow
Well, as I said, you may want to report this as a bug to the ffdshow devs.

video can be 25fps... as a result of 25 * 12 / 5 = 60 picture will twitch
Ideally your display should be switched to 25Hz or 50Hz for PAL content, and to 23.976Hz or 59.940Hz for NTSC/Blu-Ray content. Can your display not handle such refresh rates?

Just curious, would you elaborate on how "receiver" is different?
Well, for a start, the HDMI cabling is different:

(1) GPU -> display
(2) GPU -> receiver -> display

Now madVR wants to make all settings available per *display*. The receiver is just a middleman. If you switch displays, but keep using the same receiver, madVR still wants you to be able to use different settings for the different displays. So having a receiver connected to your GPU makes things more complicated, because madVR will get identification information from the receiver, but not from the display.

Practically, because the receiver is just a middleman, madVR doesn't let you configure things like PC vs video levels for the receiver device. However, for a receiver device madVR lets you specify which display is connected to the receiver, and you can then configure settings for the display (and not for the receiver).

Would just like to mention that 0.32 still does this for me, I know it's unlikely to be a priority, thank you for the updates Madshi.
I did reply to you (as always) and you seem to have missed that reply (once again).

[ryrynz]

I've tried, but I can't seem to be able to reproduce this problem. Still using an older MPC HC version (1.3.2273.0) here, though. Maybe it behaves different to the version you're using? Please try toggling the 2 options "Playback -> Fullscreen -> Launch files in fullscreen" and "-> Exit fullscreen at the end of playback". Maybe that helps?

Toggled those options with no effect, I'll try and narrow it down.

[madshi]

Toggled those options with no effect, I'll try and narrow it down.
Well, if you could find a way for me to reproduce the problem on my PC, that would be great.

[mark0077]

Hi madshi, very happy with 0.32. Just a query though on the results I get versus what the GUI says is expected in terms of frame delays / drops.

Playing 23.976 content on my display (23.96~), 0.32 is reporting I should get 1 frame repeat every 40 or so seconds. Thats fine, but after resetting the stats, and letting video play for half an hour yesterday I came back to see 4 frame "drops". I am just wondering can I / we use this sort of mismatch to help diagnose problems or improvements to the renderer.

I'll test again this evening, just basically asking should I use this mismatch between expected and actual results as a warning that somethings wrong, ie I'm not getting as good results as I should..

[nevcairiel]

When your refresh rate is lower then the video content, you'll of course see drops, not repeats. Not sure why madVR would claim the repeat, tbh.

I have the same situation pretty much, except that my actual refresh rate is closer to being perfect (23.974)

Using the values provided, without knowing your clock deviation, it would come down to one drop roughly every 63 seconds.
This value will vary of course with your clock deviation, and might be much better.

An inaccurate measure of the clock deviation could cause madVR to claim repeats, though.

[Vovanchik]

Ideally your display should be switched
Well I have a little different situation. I am directly interested in the best possible display fps - larger gives greater fluidity and smoothness of movement. is in fact is the essence of mvtools
smoothness of between 25 and 60 very different
as an example of the plugin conversion 23.976 -> 59.94
http://rapidshare.com/files/420937651/sample01.mkv

[Vovanchik]

I do not know a topic was raised or not, but like in the last pages are not seen.
Well. we have 2 identical situation
win7x64 + ati 1950 (10.2 drivers) + monitor (1920х1200) + plasma (1386х768)
win7x86 + ati 4350 (10.8 drivers) + monitor (1680х1024)+ plasma (1280х720)
monitor main display, plasma extended
if mpc-pc (any version older than 1.3 at least) to choose madvr, in its options to include an exclusive mode and try to open the player to full screen on a plasma - the plasma becomes a black background on the main display at this time displayed the picture size with a resolution plasma on a black background.
solved the problem a little awry - in settings mpc exhibited fullscreen d3d
and choose a plasma as a device full-screen playback. after this exclusive mode starts to work correctly and at the right place.

[madshi]

Hi madshi, very happy with 0.32. Just a query though on the results I get versus what the GUI says is expected in terms of frame delays / drops.

Playing 23.976 content on my display (23.96~), 0.32 is reporting I should get 1 frame repeat every 40 or so seconds. Thats fine, but after resetting the stats, and letting video play for half an hour yesterday I came back to see 4 frame "drops". I am just wondering can I / we use this sort of mismatch to help diagnose problems or improvements to the renderer.

I'll test again this evening, just basically asking should I use this mismatch between expected and actual results as a warning that somethings wrong, ie I'm not getting as good results as I should..
When your refresh rate is lower then the video content, you'll of course see drops, not repeats. Not sure why madVR would claim the repeat, tbh.

I have the same situation pretty much, except that my actual refresh rate is closer to being perfect (23.974)

Using the values provided, without knowing your clock deviation, it would come down to one drop roughly every 63 seconds.
This value will vary of course with your clock deviation, and might be much better.

An inaccurate measure of the clock deviation could cause madVR to claim repeats, though.
The clock deviation measurement is a tough one because the clock jitters a lot. You literally need an hour of straight playback (without pausing/seeking in between) to get halfway reliable measurement results. The clock deviation can turn drops into repeats and the other way round. So really, madVR's estimates of frame drops/repeats can only be taken at face value after at least an hour of uninterrupted playback. Once you get a reliable measurement, it should give you a good hint of how to improve your custom timings. But if you have a bit of patience, I'm planning to invest some more work into this area in the next couple of weeks.

Well I have a little different situation. I am directly interested in the best possible display fps - larger gives greater fluidity and smoothness of movement. is in fact is the essence of mvtools
smoothness of between 25 and 60 very different
as an example of the plugin conversion 23.976 -> 59.94
http://rapidshare.com/files/420937651/sample01.mkv
Ok, so you like to use mvtools2.dll, I can understand that. But the only purpose of ConvertFps is to avoid motion judder caused by a mismatch between source framerate and display refresh rate. You can get rid of ConvertFps by optimizing your display refresh rate. ConvertFps damages video quality. You should try to match the display refresh rate to the frame rate produced by mvtools2.dll. If mvtools2.dll outputs 59.94fps, then set your display to 59.94Hz. If mvtools2.dll outputs 60fps, then set your display to 60.00Hz. This way ConvertFps is not needed, anymore.

I do not know a topic was raised or not, but like in the last pages are not seen.
Well. we have 2 identical situation
win7x64 + ati 1950 (10.2 drivers) + monitor (1920х1200) + plasma (1386х768)
win7x86 + ati 4350 (10.8 drivers) + monitor (1680х1024)+ plasma (1280х720)
monitor main display, plasma extended
if mpc-pc (any version older than 1.3 at least) to choose madvr, in its options to include an exclusive mode and try to open the player to full screen on a plasma - the plasma becomes a black background on the main display at this time displayed the picture size with a resolution plasma on a black background.
solved the problem a little awry - in settings mpc exhibited fullscreen d3d
and choose a plasma as a device full-screen playback. after this exclusive mode starts to work correctly and at the right place.
The MPC HC option "D3D fullscreen" must be turned OFF. I know it's confusing. I'll try to get this fixed in MPC HC.

[Peuj]

The log shows 22 seconds of playback, followed by proper madVR close down. I don't see any indication of a problem in that log. Can you describe in more detail what happens? Does the crash happen *everytime* you start one video and then switch to another? @leeperry, can you confirm that?

FWIW, it doesn't seem to happen for me, but I'm not using the latest PotPlayer version.

To reproduce the problem I play a video, move forward then load a another video, move forward and then there is an Alert message box thrown by PotPlayer with "Unexpected exception..."

I can reproduce the problem really easily. This only happens with madVR and the latest version.

I can give you more logs with the exact steps if you need.

[leeperry]

To reproduce the problem I play a video, move forward then load a another video, move forward and then there is an Alert message box thrown by PotPlayer with "Unexpected exception..."

I can reproduce the problem really easily. This only happens with madVR and the latest version.
It seems to be working fine here, and in my experience this error msg in PotPlayer is like the dready "floating point error" in ZP, it's usually a filter connection problem or a bug in its own code. I used to have it from time to time when seeking a lot in seamless playback mode, but it wouldn't really crash the player...and it hasn't happened in a while.

what's your filter list? I've just tried to:
-open a movie
-get into FSE mode, and seek
-get back to FSW, open another movie(w/o closing PotP) and do the same several times = no crash

my filter list was:
(1) Haali Media Splitter
(2) CoreAVC Video Decoder
(3) ffdshow Video Decoder
(4) Madshi Video Renderer
(5) ffdshow Audio Decoder
(6) ReClock Audio Renderer

if you didn't already, you may wanna delete all the files in the PotP folder except for PotPlayerMini.exe and PotPlayer.dll ...I have limited trust in the built-in decoders/splitters.

[Peuj]

I don't need to go to fullscreen to make it crash (nothing related with FSE/FSW).
I use the default PotPlayer splitters/decoders.

I'll make more test tonigh and try the previous madVR version just to be sure.

Thanks

[fastplayer]

* ffdshow is not asked for audio/subtitle streams, anymore (stability issues)
Wasn't this fixed by albain a few weeks ago? If not, please PM him about that.

[madshi]

Wasn't this fixed by albain a few weeks ago? If not, please PM him about that.
Maybe it was, I don't know for sure. But madVR really wants to talk to the splitter and ffdshow is *never* the splitter, AFAIK. So it doesn't make sense for madVR to ask ffdshow about video/audio streams, anyway...

[Razoola]

I don't really understand why desktop composition should affect things. In theory it should not, because as far as I understand, desktop composition should always be disabled when exclusive mode is active, anyway.

Why do you need to find out about that windowed mode tearing, if exclusive mode works fine for you now?


Yes I don't understand it either but its certinally happening here at least.

Your right, there is need for me to use windows mode any longer. I just like to find out the cause though as it may help someone else someday. I will be using exclusive mode from now on.

[XPC]

I don't have a DVB-T tuner. Maybe you can record two different channels and when playing the recorded media files via a playlist, the problem can be reproduced without me having to buy hardware that I don't need?


I couldn't reproduce the problem by recording and playing the files, but I did more debugging and I found that the problem happens when the window size changes. If I have a maximized window, there is no problem at all, regardless of the AR. So I debug both situations and here is the output I get from mpc-hc:

First test: Switching from 1440x1080 to 720x576 (SW_SHOWMAXIMIZED)
ResetMpeg2Decoder()
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000e (EC_PAUSED)
ResetMpeg2Decoder()
The thread 'Win32 Thread' (0xfe8) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x10d0) has exited with code 1 (0x1).

CBaseVideoFilter::ReconnectOutput; wout = 720, hout = 576, current = 5x4, set = 16x9
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)


Second test: Switching from 1440x1080 to 720x576 (fails here!)

ResetMpeg2Decoder()
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000e (EC_PAUSED)
ResetMpeg2Decoder()
The thread 'Win32 Thread' (0x1694) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x8fc) has exited with code 1 (0x1).

CBaseVideoFilter::ReconnectOutput; wout = 720, hout = 576, current = 5x4, set = 16x9
--> CMainFrame::OnGraphNotify on thread: 2732; event: 0x0000000a (EC_VIDEO_SIZE_CHANGED)
720x576


I found the exact point where the application hangs in the second test: madVRAllocatorPresenter (Ln 233): pBV->GetVideoSize(&size.cx, &size.cy);

TDMETHODIMP_(SIZE) CmadVRAllocatorPresenter::GetVideoSize(bool fCorrectAR)
{
SIZE size = {0, 0};

if(!fCorrectAR)
{
if(CComQIPtr<IBasicVideo> pBV = m_pDXR)
pBV->GetVideoSize(&size.cx, &size.cy);
}
else
{
if(CComQIPtr<IBasicVideo2> pBV2 = m_pDXR)
pBV2->GetPreferredAspectRatio(&size.cx, &size.cy);
}

return size;
}

At some point I'll have to investigate why the application is sending so many times the EC_VIDEO_SIZE_CHANGED, but this is how it is currently working with the EVR CP Renderer. Do you have any idea on what could be happening in fuction GetVideoSize?

Please let me know if you need more details/testing.

[madshi]

I couldn't reproduce the problem by recording and playing the files, but I did more debugging and I found that the problem happens when the window size changes. If I have a maximized window, there is no problem at all, regardless of the AR. So I debug both situations and here is the output I get from mpc-hc: [...]
Hmmmm... My video renderer sends a EC_VIDEO_SIZE_CHANGED notification when the media type changes and indicates either a video size or aspect ratio change.

One idea: Maybe you could concat the 2 recordings you've made ("copy source1.ts /b + source2.ts /b result.ts /b")? Maybe that will work to reproduce the problem?

[leeperry]

I don't need to go to fullscreen to make it crash (nothing related with FSE/FSW).
I use the default PotPlayer splitters/decoders.
ffdshow/HMS ftw :)
madVR really wants to talk to the splitter and ffdshow is *never* the splitter, AFAIK. So it doesn't make sense for madVR to ask ffdshow about video/audio streams
beating a dead horse here...what could possibly be the practical point to have ffdshow taking care of Imedia..except adding useless bloat to its menus that is. It's the splitter's job, end of story :rolleyes:

[dansrfe]

I sometimes get a lingering "madVR reports..." message that doesn't go away when I restart playback from paused mode in mpc-hc.

[Shark321]

I've a problem using MadVR 0.32 and Zoom Player 7 on Win7 x64 with ATI Radeon 4670. I get a progress bar on the bottom of the screen, which updates as the movie playes. The progress bar disppears if I go to windowed mode. The progress bar is not present with any other renderer (e.g. Haali).

[Vovanchik]

The MPC HC option "D3D fullscreen" must be turned OFF
In this mode, the picture goes very smoothly, even though the difference between video and display fps (in this case do not even need ConvertFps)
When disconnecting the exclusive mode and fullscreen d3d picture in the same conditions twitches, only helps the forced modification of video fps ConvertFps through to the actual frequency display
possible way and a wrong, but it works

[mark0077]

Madshi I have had a few complete mpc freezes with 0.32 over the course of today. I'll provide any logs if necessary. I have to kill mpc using task manager. I'll do more testing but have a feeling it's because I start mpc from a script from xbmc which kills xbmc out of it's own exclusive fullscreen mode just before it loads mpc. Maybe madvr gets a bit confused with this xbmc shutdown just at the time of mpc startup? I'll try to get some more info.

[namaiki]

I've a problem using MadVR 0.32 and Zoom Player 7 on Win7 x64 with ATI Radeon 4670. I get a progress bar on the bottom of the screen, which updates as the movie playes. The progress bar disppears if I go to windowed mode. The progress bar is not present with any other renderer (e.g. Haali).

When in fullscreen exclusive mode, madVR has it's own progress bar so that you don't have to exit exclusive mode to seek the video. It should go away if you move the cursor from the bottom of the screen.

[leeperry]

the only purpose of ConvertFps is to avoid motion judder caused by a mismatch between source framerate and display refresh rate. You can get rid of ConvertFps by optimizing your display refresh rate. ConvertFps damages video quality.
There's 2 movies that really blow me away smoothness-wise in mVR, they're "Space Chimps" and the PAL DVD of TESB...both look awfully smooth, 48fps-like all the way! My brain isn't an accurate enough tool to make a diff. between FSE/FSW, but in 96.000Hz FSE w/ Reclock...they're both http://forum-images.hardware.fr/images/perso/radiohead2113.gif

I dunno what your plan is, but I sure hope that you'll be getting your money worth for this masterpiece of code soon or later http://forum.slysoft.com/images/smilies/agreed.gif