Print

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

[Jong]

I've noticed this problem for some time but only just been able to do some organised testing.

I launch MC18 (very latest version, but its been true for some time) straight into TheaterView and when I launch a video it plays using full screen windowed mode (RO HQ mode). However, if I switch to standard view and then back to TheaterView MadVR uses full screen exclusive as it should. It seems MadVR is not properly initialised until standard view is used  ?

[Jong]

Bump!

Can someone else verify this? Set MC18 to load straight into TheaterView then use it to play a video and bring up the MadVR OSD. Does it say "fullscreen windowed mode"? If it does go to standard view and then switch back to Theaterview. Now play the video. It should now show "exclusive" mode.

[mykillk]

I'd try the option in MadVR to delay the switch to fullscreen exclusive for a few seconds. Maybe that'll fix it? Otherwise I'm not really sure, I don't even use the theater view. But I have noticed that sometimes it goes straight into fullscreen exclusive while most of the time it goes into fullscreen windowed and after the 3 second delay it switches to exclusive. It does seem inconsistent. But that seems like a bit of a different issue.

It'd be interesting to know if the theater view itself is using fullscreen exclusive mode and not properly releasing the handle sometimes. If it is, I think that by enabling the option to wait before entering fullscreen exclusive mode in MadVR, it's forced into windowed mode (freeing the device handle) and then back into exclusive mode. Kind of like flushing the audio buffers at startup and seek to get rid of sound glitches.


EDIT: I checked and playing a video from theater view, set to be the default view at startup, went straight into fullscreen exclusive mode for me regardless of whether the delay option was checked or not.

[InflatableMouse]

Works fine for me Jong, sorry.

[Jong]

Thanks for the testing guys. Well obviously this needs a bit more investigation. The thing is it behaves just as I say here - once I have switched MC to standard view exclusive mode works perfectly, even after switching back to Theaterview. I can even 'solve' the problem by using a batch file to load MC in standard view and then switch to Theaterview. I will try playing with MCs settings and MadVR and maybe even ask Madshi what could be stopping the switch to exclusive. It does sound like MC may be hanging on to exclusive mode for itself, but why that would be happening here and not for you I really do not know.

[Jong]

Still the same problem with .108. Not sure what else I can do or what other info would be useful to diagnose.

All works fine once MC has been in standard view, but if MC is launched direct into Theaterview full screen exclusive mode does not engage.

[InflatableMouse]

Some guesswork you probably already tried ...

What refresh rate do you have your desktop settings set to?

In Tools/Options/Theater View, under Advanced, what do you have for Framerate? Do you have 'Use fullscreen exclusive mode for drawing' enabled?

Then in Tools/Options/Video, under display settings, is the Default (bottom) set to 'Desktop Settings' or a specific mode?

If I were you, I'd play with these and reset as much as possible to the default settings and set Windows display mode to 60Hz. Under Display Settings set default to Desktop Settings.

If that doesn't help, the issue may be related to MadVR settings, preventing it from switching on its first attempt? Tried resetting Madvr back to its defaults?

[Jong]

Actually I am running @50hz. MC is set to use desktop settings - no auto refresh rate switching. The same problem occurs with PAL DVDs and with US 720p material, sped up by Videoclock to 25fps.

The framerate, under Theaterview settings is set to 50 fps.

"Use fullscreen exclusive mode for drawing" is unticked (I think this is the default)

I will admit I did try to reset MadVR to defaults but it didn't seem to work (my scaling settings were still as I set them). Maybe someone can say definitively what I need to do to reset these settings.

The odd thing though is the behaviour is entirely predictable. Provided standard view has been displayed all works perfectly, but until then MadVR will only use fullscreen windowed mode. There must be something that MC does when entering standard mode, or when switching from standard to Theaterview, that it does not do if loaded straight into Theaterview  ?

[InflatableMouse]

You don't have both modes ticked in Madvr do you?

That is last thing I can think of .

[Jong]

If you mean widowed OVERLAY mode, then no that isn't enabled, but then my understanding is that doesn't work with AMD cards anyway. But thanks a lot for trying.

[Jong]

Matt, further info on this.

Even using the OSD to switch the entire MC interface into windowed mode, then minimising, reselecting the window and maximising it does not cause MadVR to switch to exclusive mode. It is clear whatever "window" MadVR thinks is stopping exclusive mode is a hidden window within MC, like the display mode OSD itself, not an external window or a secondary MC window selectable from the Windows UI.

[Jong]

Matt, found the source of the problem!!

It happens when using Chromium as the web engine. Looks like the JRweb.exe process window is the cause.

[Matt]

It happens when using Chromium as the web engine. Looks like the JRweb.exe process window is the cause.

I wonder if madVR is picking the JRWeb.exe window as its parent?

JRWeb.exe is run in its own process, so it would be bad for madVR to hook it.

Ideally madVR would only use the parent window we provide, but I think there's a technical reason madshi needs to walk up the window tree (I believe to get a top-level exclusive mode parent).  However, that "walk up the window" tree function needs to be careful to not use a window from another process.

You can check a window's process like this:

Code: [Select]

DWORD dwProcessId = 0;
GetWindowThreadProcessId(m_hWnd, &dwProcessId);
return dwProcessId;

I'll send this thread on to madshi.

[madshi]

Jong sent a log to the doom9 thread. The real problem is not which parent window madVR selects. madVR does not even *try* to enter FSE mode, because:

Code: [Select]

00002218 Render   fullscreen windowed mode, covered by some windows
00002218 Render   madVR window [madVR] {0,0,1920,1080}
00002222 Render   covered by JRWeb.exe window [CefBrowserWindow] {0,0,200,200}
00002226 Render   covered by JRWeb.exe window [Chrome_WidgetWin_0] {0,0,200,200}
00002229 Render   covered by JRWeb.exe window [Chrome_RenderWidgetHostHWND] {0,0,200,200}
It seems that madVR thinks there are other windows on top of the madVR rendering window. Does that make any sense to you?

[Matt]

It seems that madVR thinks there are other windows on top of the madVR rendering window. Does that make any sense to you?

That's interesting.  Normally JRWeb is a child window of the main program.  There is one exception: when using a glass-based skin like 'Black on Black', we must float JRWeb and a few other windows that don't support alpha in a popup.

@Jong
What skin are you using? Could you try Noire?

@madshi
How are you checking for the window?  Is it possible the window "covering" madVR is hidden (WS_VISIBLE)?

[madshi]

I'm using EnumChildWindows(), and yes, I'm excluding all invisible windows.

[Jong]

That's interesting.  Normally JRWeb is a child window of the main program.  There is one exception: when using a glass-based skin like 'Black on Black', we must float JRWeb and a few other windows that don't support alpha in a popup.

@Jong
What skin are you using? Could you try Noire?

@madshi
How are you checking for the window?  Is it possible the window "covering" madVR is hidden (WS_VISIBLE)?

I'm using obsidian but tried noire in testing and it behaved the same. As I said, it is not a universal problem with JRweb. It only happens when using Chromium. And let's not forget the oddity that switching to standard view and back (or starting in standard view) avoids the problem too. 

[madshi]

I'm wondering if maybe Windows itself is sometimes confused and reports the windows in the wrong Z order. Maybe switching to standard view and back simply updates the internal Z order somehow.

BTW, is that size of 0,0,200,200 realistic? Are those JRWeb windows supposed or expected to have such dimensions? Just wondering...

[Matt]

BTW, is that size of 0,0,200,200 realistic? Are those JRWeb windows supposed or expected to have such dimensions? Just wondering...

Yes.  We create the Chromium window at 200x200, then resize it later.

I'm wondering if the issue is that the Chromium engine gets created but never gets resized since we're in Theater View.

I'll have to step it in the debugger.  I have some other things cooking, so it might be Monday before I get a chance to provide more information.

[Jong]

It doesn't happen "sometimes" or randomly it consistently happens if MC is launched straight into Theaterview with Chromium selected as the web engine. Seems it is something in the way that is initialised is messed up. JRweb has no visible user window, even using Chromium, so not sure how this window gets to be invisible yet, in some way, strangely visible  (As far as MadVR is concerned) ?

[thezone]

Sorry for the dumb question, what does "Use fullscreen exclusive mode" for drawing do as opposed to "full screen windowed mode"  I dont have this (exclusive ) enabled and im not having any issues in theater mode using madvr. Sorry this isnt really contributing to this thread just interested to know.

[InflatableMouse]

In exclusive mode, Madvr has exclusive access to draw on the screen, nothing else can display anything. This makes Madvr a little bit more stable if you like, less prone to framedrops etc.

[madshi]

There are basically 3 different modes you can use. Each one has advantages and disadvantages:

(1) normal windowed mode

+ works for both windowed and fullscreen rendering
+ no extra delay when switching to/from fullscreen
- can sometimes show tearing (when Aero is off)
- can sometimes result in jerky playback
- can be slower, especially on old hardware

(2) overlay mode

+ works for both windowed and fullscreen rendering
+ no tearing
+ usually smooth playback
+ fast
- resizing playback window/size sometimes looks "odd" for a moment
- only available on NVidia and Intel GPUs, not available on AMD

(3) fullscreen exclusive (FSE) mode

+ no tearing
+ usually smooth playback
+ fast
+ reliable protection against framedrops if CPU gets very busy for a short period
- only works for fullscreen rendering
- switching from/to fullscreen takes a moment in which playback is stuck
- media player GUI/OSD might not work (depends on media player, though)
- when media player windows (file open, settings dialog etc) are shown, FSE mode must be left

Usually FSE mode is the most reliable mode for smooth playback without any frame drops. However, many people have a similar experience with Overlay mode, without the FSE drawbacks. Some people also have the same experience with Windowed mode. If Windowed mode works perfectly fine for you, then there's no need to use Overlay or FSE mode.

[thezone]

Awesome stuff guys thanks! This might be the solution ive been looking for as I do get framedrops (only used normal windowed mode). Will play around more.

Cheers!

[madshi]

FWIW, frame drops can have many reasons (e.g. CPU or GPU being too slow, refresh rate being lower than movie framerate, ...). But it would be absolutely worth a try turning on Overlay and/or FSE mode for a while to see if it improves things for you.

[thezone]

FWIW, frame drops can have many reasons (e.g. CPU or GPU being too slow, refresh rate being lower than movie framerate, ...). But it would be absolutely worth a try turning on Overlay and/or FSE mode for a while to see if it improves things for you.

Thanks for that. My CPU and GPU are def not too slow, just built the HTPC with MSI GTX 660Ti, Gigabyte Z77X-UD5H and i5-3570 with 16g ram. Have turned on FSE mode in options>theatre view>advanced but its still drops a subtle frame every 30-40 seconds or so. Not sure how to enable overlay mode?

[madshi]

Then my best guess would be that your refresh rate is too low. E.g. 23.972 instead of 23.976. Check the refresh rate measurement in the madVR OSD (Ctrl+J). If it's too low, try creating a custom resolution to get a better refresh rate. But this is really OT here...  (You can enable Overlay in "general\rendering settings", but I don't think it will be better than FSE).

[thezone]

Thank you madshi I think I've almost completely solved my frame drop issue. I worked out how to enable FSE in madVr settings and I am also using these settings:

Under processing, decoding, unchecked all decoders
Under scaling algorithms, I chose:

chroma: jinc 3 with anti-ringing
image upscaling: jinc 3 with anti-ringing
image downscaling: lanczos 4 with anti-ringing and scaled in linear light

MadVR osD now shows framerate of 23.97178 and shows a frame drop will result every 3.86 secs which is certainly livable. If you know any other tweaks to get the framerate to 23.976 please tell! Otherwise its working a treat thankyou!

[Jong]

Sounds like you have not enabled Videoclock. That will reduce frame drops to days, rather than seconds! Just tick the box under options/video. But you must decode all audio on the PC to use Videoclock, not bitstream. Support for all common codecs is included except DTS-HD, which by default reverts to decoding the DTS core. Unfortunately DTS-HD is the most common bluray audio format! To fix this you need to get hold of a copy of the Arcsoft DTS decoder: http://wiki.jriver.com/index.php/Blu-ray#Decoding_for_DTS-HD

And personally I would beware of using jinc for both chroma and luma if you play any interlaced material @60Hz. If your PC cant render quickly enough you will drop frames whatever you do about matching frame rates!Check the rendering time for upscaled content (not 1080p) in the MadVR OSD, I suspect it may be >16.66ms, which is the 60Hz frame time. Upscaling is not as quality critical for chroma as luma, in fact at one point Madshi was recommending/ saying he would most likely stick with bucubic upscaling for chroma, although I haven't heard his most recent stance on this  . But that is what I use - jinc 3-tap for luma, bucubic for chroma.

[madshi]

Reclock is one solution, personally I'd much rather recommend optimizing the refresh rate first. Anyway, both of this is OT here, so this will be my last post on this topic.

[Jong]

Yes, I'm in danger of helping derail my own thread! But, thezone, feel free to try my suggestions and open your own thread to discuss more if you wish. Please leave this thread for the original topic though.  

[thezone]

Thanks for your help guys. I have started a thread but it seemed to fizzle away prematurely for some reason!

http://yabb.jriver.com/interact/index.php?topic=77238.0;topicseen

[Jong]

Matt, one slightly OT question. When diagnosing this problem I was trying to reset MadVR to default settings and I realise I have no idea how to do it in MC. I tried using the MadVR reset batch file in the MadVR apppdata plugins folder, I tried deleting the settings file in that folder, I tried deleting the whole folder and reinstalling MC! Still, my custom MadVR settings (specifically the scaling options I had set) were there! No idea how to make sure MC's version of MadVR is back to an "out of the box" configuration.

In this thread I'd like to recommend resetting MadVR, but I don't know how!

[Matt]

I'm wondering if the issue is that the Chromium engine gets created but never gets resized since we're in Theater View.

That's what it was.

Next build:
Fixed: When using the Chromium browser engine and starting directly into Theater View, it could cause problems with madVR entering exclusive mode.

Testing appreciated.