Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[6233638]

Just updated to the latest build of madVR, and have noticed an issue that seems to be caused by Media Center:

When Media Center's display mode switcher is disabled, allowing madVR to handle the switching, pressing the stop button inside Media Center does not appear to "release" the video correctly and the original refresh rate is not restored until both Media Center and Media Server are closed.


0.86.2 also implements a fix for madVR's display mode switcher on Windows 8, which allows it to switch to 24/60Hz correctly now.
I'm not sure how Madshi fixed this, but it would be nice if Media Center's display mode switcher could also be updated to correct this. (it switches to 23/59Hz rather than 24/60Hz)

[Matt]

When Media Center's display mode switcher is disabled, allowing madVR to handle the switching, pressing the stop button inside Media Center does not appear to "release" the video correctly and the original refresh rate is not restored until both Media Center and Media Server are closed.

madVR gets stopped and fully released when playback stops.  So if it makes a change that persists after that, it seems like it might be a madVR issue.

[Hendrik]

I have some distant memory of that being intentional in madVR..

madVR changelog says this:
* added option "restore original display mode when media player closes"

[Matt]

madVR is special in that it never really unloads once it's loaded.

We release it, but if you look at a process spy, you'll see several threads, the madVR exe, etc.

I'm not a huge fan of this, since MC should be able to run (basically) forever and acts as a server.  However, I'm sure madshi has some good technical reasons for this.

[6233638]

I was wondering: with the introduction of much larger decoder queue sizes, I also ended up increasing the number of backbuffers used in Windowed Mode from the default of 3 to 8.

With 24p content, I had to increase audio latency by ~208ms for sound to be in sync last night. (now 315ms total)

Was it just a coincidence that I had to do this (badly synced source? though it seems unlikely as it was a Blu-ray disc) or should Media Center perhaps be doing automatic correction for this?

[Matt]

I'm not certain about the latency.

It seems like it would be best if madVR could account for its own latency, but maybe that's not possible for some reason?  I've never noticed a difference between EVR and madVR with regards to timing, so I assumed it already did this.

Our audio renderer could talk to madVR to get its latency and account for it if necessary.  The audio engine already works with madVR to make VideoClock work well.

[6233638]

I'm just not sure if the sync error I saw last night was caused by me not having my latency set right for my new DAC yet (though it seemed to be OK before then) if it was the film I was watching, or if something else in my setup had changed which caused this. (though I'm not sure what else that could be)

I understand that it should be a relatively painless fix if that's the cause, but I was wondering if anyone else had noticed something similar?

Note: I seem to recall that years ago when I also ran into lip-sync issues, they were solved by putting madVR into Fullscreen Exclusive Mode, rather than running it in Windowed Mode - but that was on a completely different system, and I don't want to be using FSE with MC18.

I need to do some more testing on this, but I don't know that I will have the opportunity to for a couple of days.


Edit: Oh, and to make it clear, 208ms is approximately 5 frames at 24Hz, which is why I suspect that this was the cause. (1 frame is 41.67ms)

[Hendrik]

madVR syncs to the audio reference clock. Longer queues would not cause any desync, unless something can't keep up.

[6233638]

madVR syncs to the audio reference clock. Longer queues would not cause any desync, unless something can't keep up.

Must have been a coincidence then, or something else causing the delay. Thanks.

[mdav]

Strange, I'm also having A/V sync problems with the update to .195 (running RO HQ, madVR in windowed overlay mode).

[madshi]

When Media Center's display mode switcher is disabled, allowing madVR to handle the switching, pressing the stop button inside Media Center does not appear to "release" the video correctly and the original refresh rate is not restored until both Media Center and Media Server are closed.

The failure to restore the original refresh rate is not a consequence of MC18 doing something wrong. It was a not-fully-implemented feature in madVR. Basically I restored the refresh rate when switching from fullscreen to windowed mode and when the media player process closes, but I "forgot" to also restore the display mode when the madVR instance is released without leaving fullscreen. This will be fixed in the next build.

madVR is special in that it never really unloads once it's loaded.

We release it, but if you look at a process spy, you'll see several threads, the madVR exe, etc.

I'm not a huge fan of this, since MC should be able to run (basically) forever and acts as a server.  However, I'm sure madshi has some good technical reasons for this.

I might still improve this in a future version. But to my best knowledge the current behaviour doesn't harm in any way, so it's not high in my priority list. FWIW, some of the behaviour has good reasons. E.g. when madVR switches to another display mode, it starts a new madHcCtrl.exe helper process which sits idle and waits for the media player process to end. When the media player process does end, the helper process makes sure that the original display mode gets restored, just in case the madVR instance inside of the media player failed to restore it. This could happen e.g. if there's a bug in madVR (like the one found by 6233638), or if the media player crashes and terminates without giving madVR a chance to restore the original display mode. By using the external madHcCtrl.exe process it is guaranteed that the original display mode is restored at some point.

madVR syncs to the audio reference clock. Longer queues would not cause any desync, unless something can't keep up.

Correct.

[6233638]

This will be fixed in the next build.

Excellent, thank you. I wasn't meaning to point "blame" at anyone.