MPC-HC tester builds for internal renderer fixes

[HoP]

@ Yoshi8765
1- export your settings to reg file
2- delete the old version completely
3- extract new version(zip file) and place that where you want
4- double click on reg file and apply it to registry
5- Have fun :D

[kasper93]

@HoP: He can just overwrite .exe file... Settings will remain in register unless you delete them ;p

[Yoshi8765]

@HoP and kasper93:
Thanks to both of you. I overwriting just like kasper93 said and it looks like it worked. :D Perfect!
I'm using lav filters+madVR to use DXVA and another question came up: under output, I have madVR selected for 'directshow video'. It shows only subtitles with a check, not screenshot, shaders, rotation or (most importantly) DXVA. Should I just ignore this? I guess it's not detecting LAVfilters?

[HoP]

@kasper93
yes.but i clean registry after removing software :D

@ Yoshi8765
It shows only subtitles with a check, not screenshot, shaders, rotation or (most importantly) DXVA
cause madVR doesn't support them.(if im not wrong)
look at madVR thread . for example ↓
hardware accelerated video decoding (DXVA) is currently not supported

[Yoshi8765]

@HoP
By DXVA, I mean DXVA2. Does this make a difference?
If madVR doesn't support DXVA2, then the guide I used to set up MPC-HC makes no sense....

[HoP]

@ Yoshi8765
ask in madVR thread

@JanWillem32
any news?? any new build??

[Warlock]

JanWillem32, can you create a version with installer? It's much more practical, as well as facilitates the maintenance of the same, especially in relation to the windows registry.

[JanWillem32]

Sorry for my absence, I'll try to update somewhat regularly again. I haven't been developing much, but I guess I can still report a few things.

@cez4r: Thanks for the links. These are OpenGL and OpenCL tools. The items I'm working with are DirectX based. It's still nice to see that there's improvement to the toolset and support of OpenGL and OpenCL.

@Hypers: It's been a while, and newer drivers are out. Can someone replicate issues with the latest Nvidia Driver (beta or stable)? If this continues to be an issue, I can make a debug build specific to trace problems of this type.

@Sylt: I can shove the entire block of code in a repository, but it will be pretty rough work. The developmental alpha version has a few rough edges. Of course I don't mind sharing the code, though.

@JbstormburstADV: I don't mind integrating new code, as long as I don't have to deal with the current situation of a shared code path of VSFilter and the ISR. I had enough trouble updating the internal section of video renderers and video renderer handlers for Haali renderer and MadVR. (I still haven't even updated EVR Sync.)
A code transplant is not to be taken lightly: the video renderer I imported for fitting on the DirectX 9 parts was not very compatible with the player to say the least. It took weeks before it properly rendered any video. (The previous renderer was such a mess I couldn't work with it at all.)
If integration of new code is worth it and long-term planning can be made to integrate and test the improved code, along with the massive amount of adjustments required to make it work with the ISR, I'd be happy to help. For now, I'll stick with what I have. Most of the changes I made were to get the ISR stable and capable of handling a video renderer's asynchronous queue system. That at least worked out well, but only scratches the surface. The subtitle renderers mostly have issues with image rendering and not so much in terms of allocation parts for the video renderers.

@kasper93: I expect I can patch the subtitle improvements separately from the rest of the items, as these parts are limited in interface changes. The changes to the video renderer section are small and should be compatible with the old set of video renderers and external video renderer sockets.

@HoP: If wanted, I can issue slightly updated builds, but still based on r5855. I haven't been able to integrate anything from the trunk lately.

@Warlock: These are alpha-state tester builds. Although generally working fine, these builds are not intended to replace the standard line of beta and stable versions. I provide them for testing purposes. Users should certainly compare these builds against the trunk versions. As such, be able to switch between and run both (and probably some older versions as well). Building the installer would not help me test the parts of the code I changed. It would only suit the "easy install once and done" case. I'm not targeting that.

Some updates;
- I gave the windowed fullscreen mode another dirty fix. It's not perfect. (It doesn't always detect it when the window behind it changes in size. The organization of the sub-windows hosted by the player is just badly suited for a video renderer.)
- I was notified that my quintic spline algorithms were wrong. After analysis, I found out that I made an iteration for them that is only commonly used for fractal mathematics. Spline forms work somewhat differently. I found the standard weights for the quintic B-spline and I calculated the weights for a Catmull-Rom spline through its Cardinal spline origins with the common quintic Hermite polynomial basis functions. These two resizers are fully functional now. However, the quintic Mitchell-Netravali spline isn't defined through basis functions like Bèzier curves, the B-spline or the class of cardinal splines, but rather something in between. I haven't been able to find much literature on this part unfortunately. I'd like to integrate it though, so in case anyone knows something about polynomial basis functions for the class of BC-splines, or just the given quintic Mitchell-Netravali spline weights, please tell me. Maybe I should also post this question in the main thread, maybe it will reach more people.

[kasper93]

@kasper93: I expect I can patch the subtitle improvements separately from the rest of the items, as these parts are limited in interface changes. The changes to the video renderer section are small and should be compatible with the old set of video renderers and external video renderer sockets.

Good to hear. I'm mostly interested in bug fix for resizing video frame and subtitles. It's explained here http://afternoonnapsempire.org/subtitle-renderer-matters/ This file http://www.mediafire.com/?301dtzr51lflvj2 show the problem nicely.

BTW. This sample doesn't work with VMR9 in yours build.

[madshi]

Just for your information, the next xy-vsfilter version (due out in maybe 3 or 4 weeks or so) is supposed to get support for the new subtitle interface discussed here (http://code.google.com/p/xy-vsfilter/issues/detail?id=91). This should allow xy-vsfilter to fully replace the internal MPC-HC subtitle renderer, but for that the MPC-HC internal video renderers would have to get support for the new subtitle interface.

[gilic]

Welcome back JanWillem32 you have been missed :)
Regarding your resizing algorithms there was some discussion in madshis thread starting here: http://forum.doom9.org/showthread.php?t=146228&page=725 (could be helpful or maybe not ;))

regards

[HoP]

@JanWillem32
yes,i want a new build,please :D
thanks in advance

[fagoatse]

any chance for a build compatible with the latest madvr and upcoming xy-vsfilter?

[nevcairiel]

If you use neither the internal renderer, nor the internal subtitle renderer, what exactly does still build still improve upon? :D

[fagoatse]

If you use neither the internal renderer, nor the internal subtitle renderer, what exactly does still build still improve upon? :D

Performance comparison between evr-cp and madvr = P.

[fagoatse]

So, im trying the latest release (5855 li or sth) and there seems to be a problem with the seekbar, it simply disappears when going into fullscreen and detaches itself from the main window when back into windowed mode.

[v0lt]

@JanWillem32
I think you may be interested.

MPC-HC test build - MPC-HC 6946 shaders
1. Shaders are now stored in "Shaders" folder, which is located in user profile (if settings in registry) or in player folder (if settings in ini).
2. Shader version is now stored in the shader code. If the shader version is not specified, then used "ps_2_0".

commit da59b57a76 (https://github.com/mpc-hc/mpc-hc/commit/da59b57a76da243275345bc5e6045382e13102e8)

[clsid]

I would prefer if the Shaders folder would always be stored inside the MPC-HC folder and never in registry or user profile. That makes it easy to include shaders with MPC-HC and share them between all users. It also avoids more mess. Very few people (frequently) modify shaders from within MPC-HC. I propose showing an error message like "Please run MPC-HC as administrator if you wish to edit shaders." when saving a shader fails when using the internal editor. Shaders are also not really a setting in my opinion. It is more a resource.

[nevcairiel]

Running MPC-HC as an admin is not always possible, and very inconvenient.

[clsid]

For deployment with the installer the shaders need to be in a shared location. If using the registry is desirable, then the installer could write shaders to HKLM. MPC-HC can read those and add any new ones to the ones stored in HKCU (where they are stored now).

[v0lt]

As done in the MPC-BE 2309:

1. If the settings in the ini, then shaders are taken from the %player_folder%\Shaders.

2. If the settings in the registry, the shaders are taken from the %APPDATA%\MPC-BE\Shaders.
If this folder does not exist (user does not use installers for religious reasons), the player tries to open the shaders from %player_folder%\Shaders. If he succeeds, then after closing the shaders will be saved to %APPDATA%\MPC-BE\Shaders.

[clsid]

That would be fine.

Perhaps reading/copying shaders could be delayed until one of the following conditions is true:
- shaders are enabled
- user clicks on "select shaders" or "edit shaders" or "shader editor" in the menu

That should make loading of MPC-HC a little bit faster for people who don't use shaders (the majority).

[v0lt]

MPC-HC test build - MPC-HC 6979 shaders (http://www.mediafire.com/?6ksn493kc26fp).
second attempt
Shaders: shaders moved from ini and registry to separate folder.
(MPC-BE 2296, 2297, 2309, 2342)

PS: I canceled this changes to the 6980 version, because other developers insist on a separate branch. But I can not create it.

[JanWillem32]

Not much new this time. I've mostly been struggling with integrating the various changes from the trunk. If anything got broken in the integration process, please tell me. I had a lot to fix up.
The links are on the first page.
I changed the resizers, and added a few more. For those that set a resizer beyond "Bicubic A=-1.0" will need to re-select the resizer in the options menu.
All resizers can now be selected in the chroma up-sampling renderer options menu.
Color management was updated. Old profiles can be deleted from the user folder. New entries will be saved to the shared program settings folder. It should never trigger an UAC prompt in doing so.
I updated the frame interpolation parts. The "precise" option is a debug mode for now. It will still need some more work I guess...

v0lt, I think that handling the shaders that way is a good idea. I briefly tried it out, and the only remark I have is about the embedding of the compiling level in the string.
The video renderer can just auto-detect the available level of the current video adapter. As compiling with the highest available level is best, I think we should implement that. The pixel shader compiler menu can just default to level 3.0 every time it's opened.
If a shader can't be set on the current device, the set of pixel shaders are cleared anyway. That applies to both faulty shaders and shaders that can't be compiled at the current device's maximum level. The intermediate levels make it even more complicated: ps 2.0a is Nvidia-only, ps 2.0b is ATi-only, other brands skipped the intermediate compiling levels of D3D 9.0 annex b.

I'll try answering e-mail and PMs later today. There's a lot that requires my attention.

[gilic]

Glad to hear from you JanWillem32. I am still using one of your latest releases and will test the newest version.

regards gilic

edit: I get a "compiling initial pass pixel shader 2 failed" error with EVR-CP

[Stephen R. Savage]

JanWillem32:

First of all, it's good to see an update to this branch. I have since upgraded from my i965/Core2 setup, but I still like your EVR-CP branch over madVR. This file (http://www.sendspace.com/file/f21ske)doesn't play well with the new build. There seems to be some interaction with the Haali splitter, as the built-in MKV splitter doesn't have issues.

[v0lt]

The video renderer can just auto-detect the available level of the current video adapter. As compiling with the highest available level is best, I think we should implement that.
It is a good idea. But how to do it?

[Skibicki]

I noticed video jumps twice after pausing.
multiple formats tested
1.6.7.7014 (b50c26f)x64
EVR-CP
Internal Filters & Lav Filters

[JanWillem32]

I fixed the initial pass pixel shaders. Thanks for reporting, gilic.
I fully multi-threaded the custom pixel shader compiling passes. That should reduce the initialization time for when multiple shaders are set.
The links are on the first page, replacing the previous version.

Stephen R. Savage, a brief look at that file doesn't reveal much other than that it contains a complex subtitle. I will take some time to analyze it. Does the problem manifest itself in the same manner in the trunk build? What happens when you disable the subtitles or change the buffer size for the subtitle queue? Does the video memory and system memory stay at moderate usage while playing this sample? (You can try Sysinternals' Process Explorer to log both.)

v0lt, DX9RenderingEngine.cpp, line 654 shows a basic way to detect it by the standard caps. Detecting 2.0a and 2.0b require some more conditions of the same kind.
D3DXGetPixelShaderProfile() also works: http://msdn.microsoft.com/en-us/library/windows/desktop/bb172870%28v=vs.85%29.aspx .

Skibicki, the renderer re-initializes some parts when continuing after a pause. When playing normally, data goes into queues at various points (splitter, decoder, mixer, renderer, presentation back buffers). The renderer alone does this for up to 20 frames or .1875 s (whichever is smaller). Not much of the queue can be aborted instantly when pausing. The audio parts are usually far more responsive than the video parts. It is pretty normal for the video renderer to be a bit too much ahead when pausing. After pausing, a reset to some earlier frames can be expected. If there are problems with artifacts, losing synchronization or dropped frames when unpausing, I can look into it. Otherwise it's fine as it is now.

[Stephen R. Savage]

Stephen R. Savage, a brief look at that file doesn't reveal much other than that it contains a complex subtitle. I will take some time to analyze it. Does the problem manifest itself in the same manner in the trunk build? What happens when you disable the subtitles or change the buffer size for the subtitle queue? Does the video memory and system memory stay at moderate usage while playing this sample? (You can try Sysinternals' Process Explorer to log both.)

The subtitles don't appear to be relevant (subtitle rendering disabled). CPU usage and memory are not different than when playing any other file. However, the renderer updates the image very slowly, dropping many frames. In Ctrl+J, it reports the frame rate as "0.000". The file plays normally after remuxing it with mkvmerge or when using Gabest MKV instead of Haali. Regular EVR and VMR renderless are unaffected.

[JEEB]

The subtitles don't appear to be relevant (subtitle rendering disabled). CPU usage and memory are not different than when playing any other file. However, the renderer updates the image very slowly, dropping many frames. In Ctrl+J, it reports the frame rate as "0.000". The file plays normally after remuxing it with mkvmerge or when using Gabest MKV instead of Haali. Regular EVR and VMR renderless are unaffected.
That all sounds like Haali's gratuitous use of the DefaultDuration tag. Among other things, it seems to use it for the 'duration' field of the frame it passes through the DirectShow system (instead of, say, calculating the delta between two frames' timestamps). Which then the VSync functionality uses for timely rendering (I haven't checked JW32's sources, but this sounds just that much too close to how it goes with "normal MPC-HC").

Over at the main project the VSync functionality was disabled by default, among other reasons, because too many filters (including MS's WMV DMO stuff) pushed through invalid 'duration' fields and thus making the whole system work in a rather derpy way. If the option is available in this build, you can try it by right-clicking the video surface, and then going Renderer Settings→VSync and unchecking VSync there. That should make the file play better without fixing the DefaultDuration field or switching splitters.

[JanWillem32]

I fixed the issue. The video information requested by the renderer contained an indicated average frame time of 0. On top of that, some frames were marked with an extremely low frame duration. The first frame for example is set to 110 * 100 ns. That's only appropriate for 90909 Hz video.

[Hera]

Bugs,
- 32f is only possible in D3D:FS
- Going normal full screen frequently glitches out the seek bar - it stays on the screen looking funny
- When in non exclusive full screen, doing anything on a second monitor cause loss of full screen mode.

W864, i5 3570k 4.5Ghz, NV 660 GTX, 32 GB RAM, 2 x 1080p monitors

PS Welcome Back!

[Stephen R. Savage]

Perhaps I'm doing something wrong, but LCMS seems to be broken. Whenever I enable color management, I get the error message "unable to create new empty 3dlut" followed by a crash. As of now, I'm stuck on madVR since, in my foolishness, I bought a "wide gamut" display.

[JanWillem32]

Hera, the issue with the 32-bit floating point mixer + 16-bit normalized unsigned integer renderer surfaces option is new to me. I already saw this issue earlier: http://forum.doom9.org/showthread.php?p=1588557 (http://forum.doom9.org/showthread.php?p=1588557#post1588557) (includes images). Is it a similar case? For both the fullscreen modes the window handle isn't owned by the renderer, but by the main thread that is only bound to the main player window (with controls and all). It's a fundamental flaw. Other rendererers I ever worked on never had such an issue. Those renderers were always bound to one window for the entire runtine, and rarely had to do anything special with the window (such as allowing resizing and maintaining layered windows). I'll experiment some more with the code, perhaps I can solve the worst issues soon.

Stephen R. Savage, last week I edited the code that handles the saving of the lookup table files. I tested it, but it could very well have bugs. Does it matter if you choose "run as administrator" in the main executable's context menu? Does it matter if you switch between the settings in registry mode and the settings in .ini mode? Does a reset to default/optimal renderer settings help? What OS do you use? (It could be a Windows 8 issue with the shared program folder access.)
Don't worry about "wide gamut" stuff. What we have as "wide gamut" right now used to be commonplace among mid- to pro-level CRTs and projectors. Those always featured an sRGB or text mode to cope with then already legacy palettes. It's mostly because affordable LCD and plasma sceens that became popular had (and many still have) terrible display capabilities, the term "wide gamut" was introduced for commercial reasons with some of the relatively better LCD panels. (Even though it's often still just the same 10-bit-or-less junk panels as usual with different software contols.)

Does anyone else have issues with the color management, by the way? I may have to try a few intermediate test builds to eliminate this bug.

[MCDamo]

JanWillem32, firstly thank you for all the work on these builds, its certainly much appreciated by me and im sure everyone else using them.

I also have the LCMS issues, same error message as above. I tried running as Admin, but the same error occurred, on Win7 btw.

I also observed a bug using Sharpen Complex2 shaders with this build. On letterboxed movies, with black bars top and bottom, a thin yellow line borders the film itself running along the black bars.

Thanks again and looking forward to hopefully providing more input!

[MCDamo]

An update.
Selecting the 'store setting to ini file" setting in the player menu solved the LCMS error, its working as it should now!

[JanWillem32]

I just investigated the issue. The error is in the folder creation step. If the folder "Media Player Classic" is manually created in "C:\Documents and Settings\All Users\Application Data\" on XP and server 2003 or "C:\ProgramData\" on newer operating systems (folders may be hidden), the program stores the lookup files normally. I'll fix this issue when I'm back at my PC again.

MCDamo, I'll try to analyze the bug when using that shader. It's probably just not suitable for this renderer mode.

[Hera]

Issue with seek bar staying on, (http://magneticpudding.com/wp-content/uploads/2013/04/Untitled.png)

So the seek bar stays there - not updating itself.
It starts updating itself when the mouse is on it, but otherwise it doesn't update and just stays there.

And colors are a bit washed out with debug information on full

[gilic]

It seems the old bug with fullscreen auto hide controls is back. The video is moved upwards by the controls when you move the mouse to the bottom to show them.

@Hera: I think the washed out colors you noticed are because the debug screen has a light grey background.

[JanWillem32]

-Timing detection is now more robust in case of invalid inputs. (Although that generally means a fallback to 25 fps like the default for VSFilter and the ISR. With some luck, the frame rate lock system can switch to a different frame rate after a few seconds, so it's not that bad.)
-The folder creation routine for the color management section has been fixed. As LCMS has been updated externally as well, I advise to delete all older LUT3D files.
-I applied another fix to the code that takes care of the nasty windowed full screen toolbar. It's bound to break again at some point, but it will do for now. Note that some transitions between full-width maximized windowed and windowed full screen mode may still fail to update. The renderer can't detect this status change correctly while the toolbar of the windowed full screen mode exists. So, just try again if that happens.
-I updated some memory management parts of the ISR and video renderer sections. This is mostly to handle exceptions and for better efficiency to a lesser extent. If any of the error messages I added pop up, please report as usual.

x64: http://www.mediafire.com/download.php?64ab5ef3rox119a
x86 SSE2: http://www.mediafire.com/download.php?we57bk6dl6ylekb

Hera, what "debug information on full" are you looking at? Is it the D3D debug runtime?

[MCDamo]

JanWillem32,

Thank you for the new build. I tested dfr7067i, and the full-screen windowed mode appears broken. I have a black rectangle in the top left of the screen, and no picture before resizing

[Hera]

@Jan - I meant stuff like renderer, GPU, frames, offset, etc. CTRL-J stuff when on full

@MCDamo -
Seems to work for me. The biggest gripe is the video squishing that happens when in fullscreen the seek bar appears.

It also seems slower than it should be. There is an intermediate step where the video resizes and there is black area where the seek bar is, but the seek bar appears only moments later.

EDIT: Oi never mind major bug: video stops rendering after when going from one file to another.
That is
1. Open Video File in Directory with other Video Files
2. Using PG DOWN, go to next file
3. Video does not render just audio
4. Can be fixed by resizing
:(

EDIT 2: Yep switching to next file stops video from rendering - it starts rendering again when a resize happens.

[JanWillem32]

I tried to fix the window issues and make the resizing+fullscreen windowed mode's toolbar more responsive.
x64: http://www.mediafire.com/download.php?yy464jo4y9mhvd4
x86 SSE2: http://www.mediafire.com/download.php?pade0dojccuycak

About the stats screen; it has 4 modes. The three modes with the jitter graphs are on top of a darkened rectangle in the bottom right. When the mode with the most text on screen is active, the whole window area is darkened a bit under the stats screen. It's there to improve contrast a bit. I can also use some of the more traditional color schemes, such as lovely bright pink and magenta used by the legacy overlay-based renderers if people prefer that.

[Hera]

Seems to work.

[MCDamo]

Good work Jan!

Havent tested much yet but also seems to work well for me. Not sure why i got the errors on the last build and Hera didnt. I'm assuming system and program configs play a part.

I still have the black bar letterbox issue with pixel shaders. It seems that any "sharpen' type shader is affected. Ill try a few different configs and see if anything changes on my end.

[ajp2k11]

I tried to fix the window issues and make the resizing+fullscreen windowed mode's toolbar more responsive.
x64: http://www.mediafire.com/download.php?yy464jo4y9mhvd4
x86 SSE2: http://www.mediafire.com/download.php?pade0dojccuycak

About the stats screen; it has 4 modes. The three modes with the jitter graphs are on top of a darkened rectangle in the bottom right. When the mode with the most text on screen is active, the whole window area is darkened a bit under the stats screen. It's there to improve contrast a bit. I can also use some of the more traditional color schemes, such as lovely bright pink and magenta used by the legacy overlay-based renderers if people prefer that.

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?

[gilic]

There was a bug in recent AMD drivers. I'm not sure if it was 13.1

[fagoatse]

I tried to fix the window issues and make the resizing+fullscreen windowed mode's toolbar more responsive.
x64: http://www.mediafire.com/download.php?yy464jo4y9mhvd4
x86 SSE2: http://www.mediafire.com/download.php?pade0dojccuycak

About the stats screen; it has 4 modes. The three modes with the jitter graphs are on top of a darkened rectangle in the bottom right. When the mode with the most text on screen is active, the whole window area is darkened a bit under the stats screen. It's there to improve contrast a bit. I can also use some of the more traditional color schemes, such as lovely bright pink and magenta used by the legacy overlay-based renderers if people prefer that.

Did some extensive testing and it works rather well. The video still goes upwards when the seek bar appears but other than that it's fine. Thanks.

[ajp2k11]

There was a bug in recent AMD drivers. I'm not sure if it was 13.1

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