MPC-HC tester builds for internal renderer fixes

[GREG1292]

Ah ok, I'll try an older version and see if that helps. Thanks!

Try this works great for me and I also want to thank Jan for
a great build.

http://www.guru3d.com/files_details/amd_catalyst_13_2_download.html

[ajp2k11]

Try this works great for me and I also want to thank Jan for
a great build.

http://www.guru3d.com/files_details/amd_catalyst_13_2_download.html

Thanks, I tried the newer beta3 and it works perfectly! :)
http://forums.guru3d.com/showthread.php?t=376313

12.10 also seemed to work so there might be a bug in 13.1...

[JanWillem32]

fagoatse, the full screen windowed mode's toolbar is badly constructed. It resizes the video window, instead of overlapping the video window like a right-click menu. Without the ugly fix in the renderer code to detect this, the window just gets a regular resizing operation. That means a black screen will be seen during the transitions. Moving the video window upwards just allows both the toolbar and the video window to be seen at the same time, without resizing the video window. I tried to actually fix the toolbar before, but what I wrote just didn't work with the heavily templated window classes the main window, toolbars and menus used. My replacements for the D3D fullscreen window class and the window class I made for the video renderer's canvas seem to work decently enough.

I'm glad that the issue with the black screen output on some AMD cards with the 16- or 32-bit output modes is solved in the latest beta. Makes my work a lot easier. I'll just focus on optimizations for now, unless more bug reports or feature requests come in.

[fagoatse]

fagoatse, the full screen windowed mode's toolbar is badly constructed. It resizes the video window, instead of overlapping the video window like a right-click menu. Without the ugly fix in the renderer code to detect this, the window just gets a regular resizing operation. That means a black screen will be seen during the transitions. Moving the video window upwards just allows both the toolbar and the video window to be seen at the same time, without resizing the video window. I tried to actually fix the toolbar before, but what I wrote just didn't work with the heavily templated window classes the main window, toolbars and menus used. My replacements for the D3D fullscreen window class and the window class I made for the video renderer's canvas seem to work decently enough.

I'm glad that the issue with the black screen output on some AMD cards with the 16- or 32-bit output modes is solved in the latest beta. Makes my work a lot easier. I'll just focus on optimizations for now, unless more bug reports or feature requests come in.

I see, it's a decent solution for the time being so I don't mind.

On a side note, I assume you're talking about FP output in AMD GPUs. I've never changed the default value in EVR-CP but how does it affect Quality/Performance?

[HitomiKun]

Any version above tester dfr6995 crashes madVR. Any file that I open with tester x86 SSE2 7067 or tester x86 SSE2 7068 causes a crash inside madVR. I already talked about that problem with madshi and it seems your build is causing it.

[madshi]

FWIW, there's no *direct* indication that the MPC-HC test build is responsible for the madVR crash, but the crash occurs at a very weird code location in madVR and it doesn't occur with any other MPC-HC or MPC-BE build, or with any other media player.

[Hera]

I highly recommend using dithering for animated content.

[fagoatse]

I highly recommend using dithering for animated content.

What do you mean precisely? I use Bicubic A=-0.6 as the resizer and tried various integer and float point settings but it seems they are kinda bugged in the latest AMD drivers(13.3 BETA3).
8bit is fine
10 bit is fine when watching 10bit stuff, and glitches in 8bit(darker parts of the image show some strange artificats)
16bit and 32 fp seem to render stuff fine but Play/Pause/Chapters indicator is light blue(Turquoise?) in 16bit, and black in 32(and in 10bit integer as well) while its dark blue in 8bit which i assume is correct. I forgot to take screenshots, sry :(

[Hera]

What do you mean precisely? I use Bicubic A=-0.6 as the resizer and tried various integer and float point settings but it seems they are kinda bugged in the latest AMD drivers(13.3 BETA3).
8bit is fine
10 bit is fine when watching 10bit stuff, and glitches in 8bit(darker parts of the image show some strange artificats)
16bit and 32 fp seem to render stuff fine but Play/Pause/Chapters indicator is light blue(Turquoise?) in 16bit, and black in 32(and in 10bit integer as well) while its dark blue in 8bit which i assume is correct. I forgot to take screenshots, sry :(

I mean right click -> Renderer Settings -> Dithering Levels
I think it helps lower quality content look better, smoother.

I also cranked the renderer up to 32-bit fp - as that is a prerequisite for it. No visual glitches of any kind, but then again no AMD either (NV 600 + 4.5Ghz i5).

I also like the fact that it is not hardware taxing.

[fagoatse]

Using anything higher than 10-bit integer just gives me a black screen with the sound playing in the background. It's been like this for some time now, not sure if it's something I changed or what has happened. Tried it on two different computers, one with Win8/Radeon drivers 13.1 and one with Win7/Radeon drivers 13.1, same thing. Both are using LAV as decoder.

Any ideas?

10-bit integer is still broken in 13.3 beta 3 drivers. Other modes are fine. What a shame : /

@Hera, indeed but it makes my HW melt xd Once 10bit integer is fixed i might be able to use random ordered or light random i guess. These tasks are done on the GPU so I guess there's nothing JW32 can do to optimize them.

[JanWillem32]

Color management had a full revision on internal systems. Older profiles are not compatible. Settings from earlier revisions are not exactly the same and will need to be reviewed in the renderer settings panel prior to usage. Profiles are stored in the shared user program folder. If you use .ini settings storage, then profiles are stored next to the .ini file. Note: profiles do not migrate automatically when the .ini/registry setting is switched.
Because building a profile has become slower, the renderer now allows up to 8 minutes to finish the task. Your system may be less responsive when building a profile, as it's a heavy, high-priority task and reasonably well multi-threaded.

The download links are on the first page.

fagoatse, I agree on the point that the OSD could use a bit of color correction. I added a shader to do some work on it.

About the tasks that are done on the GPU: both the GPU and the CPU just run code. Different models of each will have different capabilities, but in general, I'm actually quite good at applying extreme optimizations for both sets of code. Just compare to the trunk EVR CP/VMR-9 r.. My builds are slow at (re-)initialization, but a lot better at actual rendering.

About the dithering types: no dithering is the lightest, static ordered is next, random ordered next to that and all random dither options require equally heavy processing.

About the performance and quality modes: the 8-bit surfaces option (default) is only there for its compatibility and performance. It disables all advanced functions of the renderer.
The 10-bit surfaces and onward enable quality options, if supported. These include dithering, color management and frame interpolation. Frame interpolation also requires hardware support of PS 3.0 due to complexity in the pixel shaders.
For the surfaces options, the added quality of each step up should be visible in the gradation of the color tones. (Although I'm not so sure if it's useful to keep the 10-bit option with the transforms I programmed. The quantization isn't too great.)
The surface bit depth is the quality at which each pixel is stored after every filtering pass of renderer. The renderer has several filtering passes by default. End-users can add custom pixel shaders too (in two of the renderers' stages). Each pixel shader set adds a filtering pass in the renderer.
The internal working surfaces of the renderer do not relate to the output type of the decoder (most commonly 8-bit, 4:2:0 chroma-downsampled, 8-bit, 4:2:2 chroma-downsampled and 10-bit, 4:2:0 chroma-downsampled Y'CbCr).

About intermediate builds: as it takes a much more time than I would like, I don't bother testing intermediate builds with the full set of external filters and such.
The main intention of intermediate builds is to test how the untested new code handles for a few bug fixes and/or features. As I'm always editing a lot of parts in the code at the same time, some parts can be be completely untested (and broken).
For intermediate builds;
-I write code;
-I run some stuff in the debug mode to see if it seems to work for me;
-I compile;
-I upload.

[fagoatse]

@JanWillem32
Thank you for such a detailed explanation. Speaking of quality, I think the resizer has the biggest impact(Nowadays I usually have to upsample from 720p->1080p), the rest is kinda negligible(save for dithering maybe) as far as animated content is concerned. Perhaps it's because I watch stuff on a 50" plasma TV while sitting comfortably on a couch 3-3.5 meters away from it. I was kinda afraid of changing from bilinear due to performance constraints but it turned out that resizers are surprisingly well optimized.

As usual I'll provide feedback on the latest build(hopefully by the end of the week).

btw, I'll be switching to a x64 playback chain in a few months time, do 64bit builds you provide contain handwritten SSE2 codepaths as well?

[JanWillem32]

The resizers are just filter stages, too. My current playback chain includes five resizing stages: horizontal chroma up-sampling, vertical chroma up-sampling, horizontal image scaling, vertical image scaling and basic bilinear resizing on subtitles. Note that all of them are optional. For all of them except the the subtitle pass quality settings matter.
SSE2 is mandatory for x64. Technically, I have to write at an SSE level as a base. If I add SSE2 parts, those need to be used in a conditional branch next to that in SSE builds. For x64 and SSE2 builds I eliminate the legacy branch for such cases. I also wrote some parts at higher SSE levels (and AVX), those get a conditional branch in the code as usual.

A warning about dfr7100: The function that switches subtitles is not thread-safe. I fixed this issue, and I will optimize this part of the code for a next release.

[v0lt]

Poor interpolation (decrease) in the Intel HD4000.

EVR (good, no problem)
http://i.imgur.com/zGFWfYM.png

EVR-CP Catmull-Rom spline4 (PS2.0)
http://i.imgur.com/j2MW8Zk.png

EVR-CP B-spline6 (PS2.a)
http://i.imgur.com/v3u0nMC.png

When moving frame the contours of sparks and flashes.
Changing the type of interpolation does not solve the problem.
On the MPC-HC and MPC-BE the exact same problem.

PS:
madVR Catmull-Rom (good, no problem)
http://i.imgur.com/TM4q1fZ.png

[JanWillem32]

I fixed and optimized some parts of the subtitle renderer. If switching subtitle tracks is still broken, or general performance is worse compared to dfr7100, please report.

v0lt, the filters in the trunk build and mine are just the regular resizers. These have limitations to their filter kernels. Folding down several pixels into one isn't their strong point. That's what you are seeing in those images. It's not a bug. For the plain EVR and madVR the image is obviously pre-processed on resizing.
Such a pre-processing filter doesn't have to be complicated. I added a version of it to the renderer. It will automatically activate when needed, except for the nearest neighbor and bilinear resizers. I'll experiment with more advanced techniques for this grade of down-sizing later on.

[madshi]

madVR doesn't pre-process for downscaling. It's downscaling shader is similar to how image editor applications do downscaling. Which means: Same basic algorithm as upscaling, but downscaling takes many more source pixels into account with appropriate weights...

[gilic]

Since revision 7100 or maybe the version before the mpc-hc process stays very often active when I exit the player (audio tracks continue to play). Has anyone else noticed something similar?

[JanWillem32]

gilic, I had similar reports about the trunk version as well. I actually had such a session in debug mode, so I put the debugger on break. The internal filters were given the end-of-stream message properly, but were never closed. I could not trace the issue.

[gilic]

For the record I'm only using LAV Filters, so I think the error must be somewhere in the exit management code parts. Maybe there is something wonky happening with some buffers? I had rarely the issue when pauseing a video in windowed mode for a longer time span (~15 minutes or longer) that audio picks up again but video is frozen forever after resuming playback.

[Plutotype]

For the record I'm only using LAV Filters, so I think the error must be somewhere in the exit management code parts. Maybe there is something wonky happening with some buffers? I had rarely the issue when pauseing a video in windowed mode for a longer time span (~15 minutes or longer) that audio picks up again but video is frozen forever after resuming playback.

Confirmed here, using regular 1.6.7.7086 (4604700)

[euphemon]

FWIW, there's no *direct* indication that the MPC-HC test build is responsible for the madVR crash, but the crash occurs at a very weird code location in madVR and it doesn't occur with any other MPC-HC or MPC-BE build, or with any other media player.

Was this ever solved? I have the exact same problem. My bug report is linked here: http://pastebin.com/7RcVQ4Dv and another one here: http://pastebin.com/gxQ6n8BD

Other problems I have with 6995 (possibly symptomatic of the same issue) is that subtitles no longer show up after I seek through a video quickly, which isn't a big deal since it's easily avoidable. But when I use page up/down to change to next/previous videos, a lot of the time MadVR gives an error saying: "madVR reports: -creating sysmem 3dlut volume texture failed".

None of these are issues in official MPC-HC releases.

[JanWillem32]

I refined the resizer methods for when down-sizing, I tried to fix a few small problems with the subtitle queues and clean up some code. I don't expect much improvements regarding performance this time.

[Hera]

It opens up in a tiny-arse window now.

[gilic]

I can confirm this, also with "launch files in fullscreen" active the video is black. You need to re-enter fullscreen for the video to work.

[JanWillem32]

This is a bit odd. I can't replicate either problem. Maybe it's a settings thing again.
I just reset all settings to default and closed the player. When starting a video, the video window made to fit the video size (zoom to 100% setting) as per standard settings. After that, I disabled the zoom to 100% setting, and indeed, when closing and starting another video, the render window is restricted to the default, small window area. After resetting all settings again, enabling the "Launch files in fullscreen" option and closing the player, the next file I opened displayed correctly in full screen windowed mode.
Can anyone confirm that the issues are resolved when resetting all options? If not, do the problems occur with all sizes of videos played back? As usual, I can upload a few debug builds if useful.

Note: mpc-hc tester dfr7128i contains an updated version of LCMS, for those that use them, delete all previous LUT3D files to renew them.

[gilic]

My observation was with a fresh .ini with my usual settings set. After testing it seems only to happen with files with a resolution of 720p or higher. In addition subtitles are displayed over each other and stay forever.

[ajp2k11]

It opens up in a tiny-arse window now.

Happens to me as well. Window when playing file is same small size as when I start mpc-hc without loading a file. Selecting zoom 100% after loading a file corrects it though.

[JanWillem32]

Okay, I can't replicate any of the mentioned issues, so let's try to debug some of the problems of the latest version with verbose debug builds.
note: the PDB files are useful for those that can attach the debugger.

[Hera]

I think this is the stack,
assertion on open MKV

> mpc-hc64.exe!DSObjects::CDX9AllocatorPresenter::CDX9AllocatorPresenter(HWND__ * hWnd, ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * pstrError, bool bIsEVR) Line 97 C++
mpc-hc64.exe!DSObjects::CEVRAllocatorPresenter::CEVRAllocatorPresenter(HWND__ * hWnd, ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * pstrError) Line 393 C++
mpc-hc64.exe!CFGFilterVideoRenderer::Create(IBaseFilter * * ppBF, ATL::CInterfaceList<IUnknown,&IID_IUnknown> & pUnks) Line 446 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn, bool bContinueRender) Line 779 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn) Line 601 C++
mpc-hc64.exe!CFGManager::ConnectFilter(IBaseFilter * pBF, IPin * pPinIn) Line 1155 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn, bool bContinueRender) Line 815 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn) Line 601 C++
mpc-hc64.exe!CFGManager::ConnectFilter(IBaseFilter * pBF, IPin * pPinIn) Line 1155 C++
mpc-hc64.exe!CFGManager::RenderFile(const wchar_t * lpcwstrFileName, const wchar_t * lpcwstrPlayList) Line 941 C++
mpc-hc64.exe!CMainFrame::OpenFile(OpenFileData * pOFD) Line 10391 C++
mpc-hc64.exe!CMainFrame::OpenMediaPrivate(ATL::CAutoPtr<OpenMediaData> pOMD) Line 11717 C++
mpc-hc64.exe!CMainFrame::OpenMedia(ATL::CAutoPtr<OpenMediaData> pOMD) Line 14477 C++
mpc-hc64.exe!CMainFrame::OpenCurPlaylistItem(__int64 rtStart) Line 14417 C++
mpc-hc64.exe!CMainFrame::OnRecentFile(unsigned int nID) Line 9023 C++
mpc-hc64.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void) * pfn, void * pExtra, unsigned __int64 nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 96 C++
mpc-hc64.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 381 C++
mpc-hc64.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 973 C++
mpc-hc64.exe!CMainFrame::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 1210 C++
mpc-hc64.exe!CWnd::OnCommand(unsigned __int64 wParam, __int64 lParam) Line 2729 C++
mpc-hc64.exe!CFrameWnd::OnCommand(unsigned __int64 wParam, __int64 lParam) Line 371 C++
mpc-hc64.exe!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2101 C++
mpc-hc64.exe!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2087 C++
mpc-hc64.exe!CMainFrame::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 15807 C++
mpc-hc64.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 257 C++
mpc-hc64.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 420 C++
user32.dll!000000000329171e() Unknown
user32.dll!00000000032914d7() Unknown
mpc-hc64.exe!AfxInternalPumpMessage() Line 183 C++
mpc-hc64.exe!CWinThread::PumpMessage() Line 900 C++
mpc-hc64.exe!CWinThread::Run() Line 629 C++
mpc-hc64.exe!CWinApp::Run() Line 832 C++
mpc-hc64.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47 C++
mpc-hc64.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26 C++
mpc-hc64.exe!__tmainCRTStartup() Line 275 C
mpc-hc64.exe!wWinMainCRTStartup() Line 189 C
kernel32.dll!0000000002c5167e() Unknown
ntdll.dll!000007fa40c63501() Unknown

[ajp2k11]

Happens to me as well. Window when playing file is same small size as when I start mpc-hc without loading a file. Selecting zoom 100% after loading a file corrects it though.

Tried 7128i on another PC and didn't get the small window. This PC has Win7 and not Win8 though.

[JanWillem32]

Sorry, I forgot to link to the debug manual: http://forum.doom9.org/showthread.php?p=1553934#post1553934
Debug builds are verbose, but only with a debugger or DebugView attached.

edit: the previous debug builds require the debug runtime for DirectX to be installed, for those that find the DirectX SDK too bulky:

[ajp2k11]

Sorry, I forgot to link to the debug manual: http://forum.doom9.org/showthread.php?p=1553934#post1553934
Debug builds are verbose, but only with a debugger or DebugView attached.

Running the debug version I get 'Debug assertion failed" and if I click retry to debug it crashes and if I click ignore I get a message that d3d9.dll is missing? Am I doing somthing wrong?

[JanWillem32]

See my previous post. I normally link to the the debug runtime DLL for debug builds. The debug runtimes are only installed by the SDK. As the SDK is rather large for just a debug test, I added builds that can do without. Note that not using the DirectX debug runtime will mean that there are no DirectX debug messages issued. (I'm not sure if it matters in this case.)

[gilic]

The black screen bug doesn't happen with the debug build ... :/

[Hera]

This version seem to not small screen.

[ajp2k11]

This version seem to not small screen.

No small window here either on the debug build...

[derpycat]

Hi I'd like to report that build 7100 AVX x86 crashes in conjunction with madvr and lav filters on my 3570k, though the previous build works fine. I open a file and the player crashes immediately (although the file keeps playing, and I get a black screen).

[JanWillem32]

As the previous debug builds didn't help at all, I just tried to make some window parts a bit more robust and fix some little things.
Note: I removed some resizers, so users will have to re-select a type for both the main and chroma parts.

As for AVX builds, I have no idea why it would crash on systems that support AVX. For those that would like to try to debug (doesn't use the D3d debug libraries):

[Hera]

Small screens :(

[JanWillem32]

I can try an alternative method for the renderer's internal windows. I'm starting to wonder if some of the recent code changes in the trunk introduced this bug, though. I didn't edit much of the window handling code recently.

[Tyestor]

Starting any file (specifically .mkv) with LAV Filters (0.56.2) + madVR (0.86.1) crashes MPC-HC x86 AVX r7100.

This is what the MPC-HC bug report gave me: http://pastebin.com/F7LC6AMV - Previous build works fine.

Here's a screenshot of the crash: http://i.imgur.com/tR8Fuke.png

Audio still plays and you can skip to any part of the video without additional issues, just a black screen. Filters list shows that everything that is supposed to be loaded is loaded.

edit: happens with sse2 as well lol.

[ajp2k11]

As the previous debug builds didn't help at all, I just tried to make some window parts a bit more robust and fix some little things.
Note: I removed some resizers, so users will have to re-select a type for both the main and chroma parts.
x64: http://www.mediafire.com/download.php?sl0n7fp824r8jo3
x86 SSE2: http://www.mediafire.com/download.php?q6ooam48tdonnla

As for AVX builds, I have no idea why it would crash on systems that support AVX. For those that would like to try to debug (doesn't use the D3d debug libraries):
x86 AVX debug: http://www.mediafire.com/download.php?o91bbnp4c479u02
PDB: http://www.mediafire.com/download.php?hj1pe0pxix241pi

No small screen for me with this one...

[ajp2k11]

I can try an alternative method for the renderer's internal windows. I'm starting to wonder if some of the recent code changes in the trunk introduced this bug, though. I didn't edit much of the window handling code recently.
x64: http://www.mediafire.com/download.php?7yrcknpxxr8bqkc
x86 SSE2: http://www.mediafire.com/download.php?070vvhvv9g31900

No small screen for me with this one either. Seems a bit snappier when going to and from fullscreen but I'm not sure...

[JanWillem32]

I just upgraded the temp builds to temp2. (I'm not merging any revisions from the trunk until I squashed the latest few bugs.)
The window handling methods are the same as in the previous version, but I refined the code a bit and I added some better thread-safety for the subtitle sections. The standard things I would like to know are:
-Are the window and video sizes and positions appropriate in all cases with these builds?
-D3D fullscreen mode was not a problem in these cases, but how well does the player switch between the D3D fullscreen mode, the bordered windowed mode and the fullscreen borderless windowed mode? (Note that proper Alt-+Tab switching functionality requires additional code, it isn't supported for now.)
-Is the problem with black video in fullscreen borderless windowed mode solved?
-Are the problems with the stack overflows solved?

[Hera]

Small Screen might be due to 32f and/or dirther 3
on initial file open

[JanWillem32]

Note: a known weakness of these builds is that they will not start a video if minimized. The alternative window method I added for the first temp builds can't deal with the minimized condition at all. I don't have a solution for this issue right now.

Hera, the ditherer is initialized as part of the final pass and constant frame interpolator, which are in one of the last initialization stages. The surface type is bound to some early initialization passes, but all surfaces are initialized the same way. Only the 8-bit option that sets the renderer to performance mode is different: when set to nearest neighbor it uses the EVR mixer for resizing (experimental feature), and when performance mode is active the initial (chroma up-sampling, color conversion), intermediate (color conversion on subtitles and OSD) and final (frame interpolation, color management, dithering) passes are disabled.
The code that handles the window resizing and video size is mostly in the the parts that handle the window without a renderer on it. Another part bit is in the shared code for all internal video renderers+renderer sockets. In the renderer itself is only the standard routine to query for the window size, compare to the old size and then do a reset. The next part of the renderer code compares the video window rectangle and can renew transforms for resizing and positioning.

[euphemon]

I just upgraded the temp builds to temp2. (I'm not merging any revisions from the trunk until I squashed the latest few bugs.)
The window handling methods are the same as in the previous version, but I refined the code a bit and I added some better thread-safety for the subtitle sections. The standard things I would like to know are:
-Are the window and video sizes and positions appropriate in all cases with these builds?
-D3D fullscreen mode was not a problem in these cases, but how well does the player switch between the D3D fullscreen mode, the bordered windowed mode and the fullscreen borderless windowed mode? (Note that proper Alt-+Tab switching functionality requires additional code, it isn't supported for now.)
-Is the problem with black video in fullscreen borderless windowed mode solved?
-Are the problems with the stack overflows solved?

Both 7128i and the most recent temp tester builds no longer have that error with MadVR.

[gilic]

I have still the start in fullscreen bug. What I gathered so far is:
- only with EVR-CP
- it's either dependent from resolution and/or aspect ratio (it is not happening with low res + odd aspect ratio files, but with 720p 16:9 and upwards files)

Maybe this change Skip low resolution for autochange fullscreen monitor mode (https://github.com/mpc-hc/mpc-hc/commit/7c772bbaaf88d494d5bd8df9a432dd498ac622b7) has some unwanted effects with your recent versions?

[generalmx]

I was in the process of updating my multimedia setup, which normally uses your AVX builds, as well as madVR, and ran into the Stack Overflow (code c00000fd) problems myself. So I threw mpc-hc.exe into WinDbg and here's some extra info for you...

Version 1.6.7.7132 x86 AVX (from main thread)
- With ffdshow installed, it always crashes in ffdshow.ax, even if none of the filters are used, or they're blocked. Call stack:

00 57d37350 0a6510e0 00000009 ffdshow!DllGetClassObject+0x9147
01 000007f8 00000000 0e06a2bc ffdshow!DllUnregisterServer+0x4446a
02 00000000 0e06a2bc 00000000 ffdshow+0x17a00

Also note that dxva2.dll is the last module successfully loaded before stack overflow, and that, with ffdshow installed, madVR's debugger is NOT called.

Uninstalling ffdshow has the stack overflow (same code) happen instead in madvr.ax. Call stack:

0cdc0c00 00000000 0cdc0c00 madVR!DllMain+0x482d7
0e9afb5c 745c8543 0cdc0cc0 madVR+0x2ec98
0cdc0cc0 0e9afba0 76f9ac69 madVR+0x1005b
0cdc0cc0 c4a61cd8 00000000 KERNEL32!BaseThreadInitThunk+0xe
4a410050 0cdc0cc0 ffffffff ntdll!__RtlUserThreadStart+0x72
4a410050 0cdc0cc0 00000000 ntdll!_RtlUserThreadStart+0x1b

Also note that dcomp.dll is the last module successfully loaded before stack overflow.

None of these problems occur with AVX debug temp3 without DirectX debug runtime. Note this version seems to mess up subtitles (Anime, tried a few different ones), so I had to install xy-vsfilter and let that take over, and all is well.

Attached is the bugreport.txt that madVR's debugger generated.

[JanWillem32]

I solved the issue. It was nasty, as it didn't happen in debug builds.
I added another resizer. Those using one of the Lanczos resizers will have to re-select the option. I'll look for a few mere resizers soon. I'm open to suggestions, as long as the filter kernel is described somewhere.
The links are on the first page.

gilic, the problem was buried in the EVR mixer controls. I simplified the code a bit to make it more manageable.

generalmx, debug builds are too slow to decently render anything. The subtitle renderer is the one of the slowest parts, so I'm not suprised.