MPC-HC tester builds for internal renderer fixes

[Casshern]

No, the settings are the same as normal MPC-HC.
Thats unfortunate - can one cicumvent this by using the file based settings, before this version overwrites any settings in the registry?

[kasper93]

Create blank mpc-kc.ini file in the same directory as .exe file and it will be used for the settings.

[JanWillem32]

It has been a while since I last posted, so I'll give a status update.
For the renderer section I removed the dependency on D3DX9_43.dll. Microsoft deprecated this library (it was announced long ago). I really wanted to remove this this dependency for a long time already. It unfortunately comes at the cost of the aesthetics and performance of the stats screen.
I had to cook up a GDI text drawing method and line drawing functions that - unlike the GDI function - does produce somewhat anti-aliased lines. Because of the screen-sized textures used by this method, there will be quite an impact on the memory usage (both system memory and video memory) and traffic to move it to video memory as well. (Oh well, at least it works...)
Other parts were much easier to fully replace, but I'll have to do some testing on all parts I edited. I changed a little over two thousand lines lately, mostly because I hardly kept any of the original code for the stats screen routines.

About the handling of the settings, these builds are mostly compatible. I did change the meaning of some settings, such as VSync/Alternative VSync, and I edited the list of resizers, but those are minor changes. I added several options, so those settings will be stored by these builds, default initialization by the program is allowed as usual. I removed a few option as well, these settings won't be edited or removed by these builds, nor will be used. Likewise, the trunk build doesn't do anything with the settings I added.
The only true incompatibility are the three lists of video renderers. I removed the battered, broken, unmaintained and unwanted VMR-7 r. renderer along with all DirectX 7 references back when I first started editing the render sections. I chose to rebuild the lists of video renderers in the options screen to deal with the loss of the three options. Maybe I should have just inserted a reference to the null renderer as a placeholder where VMR-7 r. was. That would have been more compatible.
I must note that I often make backups of my settings (Options screen, Miscellaneous tab, Export). I often have to test various stuff. I sometimes change a lot of options, especially if I'm testing one of the trunk or one of my older builds. Restoring the settings by clicking the backup .REG file is easier than even setting two renderer settings back to normal.

berga.d, I edited the color management section a few days ago. It might fix the issue you are experiencing. The perceptual intent is a problem when dealing with a renderer that renders in XYZ regardless of input, and can handle large gamut input and output. Perceptual intent just does not map from or to the full XYZ color space. Colorimetric intents just clip color spaces, so these don't have such a problem. I changed the handling of the white point-to-white point in the code, that might just do the trick in your case. (I'll keep my fingers crossed, but I don't mind editing this section of the code again if it doesn't work.)

nghiabeo20, sorry my bad... RegGetValueW is available since Windows XP. Windows XP x64 that is... I always take a look at the minimum client requirements when I implement calls to system functions that I rarely use, but failed to spot the detail this time. Because of this function call, all of my latest builds have been incompatible with the 32-bit version of Windows XP. This is the first time this issue was reported, though. Are there really that few people still using 32-bit Windows XP?
I edited the calls to RegGetValueW() in the renderer, thank you for reporting.

derpycat, I changed the subtitle organizing and sorting function. It generally works rather well, but it needed some more attention for exception cases (such as SRT it seems). It was easy to fix, thank you for reporting.

[nghiabeo20]

Hi Jan Willem, thanks for fixing my error!
And I have a new problem :o. I can't play any video in the lastest 32 bit avx (I have a Sandy bridge cpu), I use ffdshow + madvr + ac3filter + reclock + win 8 32. I have a dump file: https://skydrive.live.com/?cid=60C0F4BFC6D8F80B&id=60C0F4BFC6D8F80B%21752
Please fix it! Thanks!

[JanWillem32]

You used dfr7313? Check the first post. None of the 32-bit versions worked.

[Scyna]

Any new avx builds I can test out?

[berga.d]

berga.d, I edited the color management section a few days ago. It might fix the issue you are experiencing. The perceptual intent is a problem when dealing with a renderer that renders in XYZ regardless of input, and can handle large gamut input and output. Perceptual intent just does not map from or to the full XYZ color space. Colorimetric intents just clip color spaces, so these don't have such a problem. I changed the handling of the white point-to-white point in the code, that might just do the trick in your case. (I'll keep my fingers crossed, but I don't mind editing this section of the code again if it doesn't work.)

Thanks, I will test next build, in the meantime I switched to madVR, since Graeme Gill (argyllcms dev) started working with madshi. However your CMM is much more simple and automatic than manual creating the LUT, I hope it will work ok in the end.
I think you can use madVR+argyll as a reference test for your mpc-hc CMM code: ArgyllCMS-BETA (http://www.argyllcms.com/Win32_collink_3dlut.zip)
Just paste this over latest official argyll, and use the tutorial in the end of Scenario.html.
You should try loading the profile created at the colprof step in mpc-hc, then your CMM should create a LUT similar to the one created using collink.

[derpycat]

derpycat, I changed the subtitle organizing and sorting function. It generally works rather well, but it needed some more attention for exception cases (such as SRT it seems). It was easy to fix, thank you for reporting.

:thanks:

[Skibicki]

Drag and drop crash - Drag file to player, then drag another during playback and it will crash. I tested with multiple file types in different orders. Does not crash in EVR.
Plays - MKV>AVI, MKV>WMV, AVI>AVI, AVI>MOV,
Crashes - AVI>MKV, WMV>MKV, MKV>MKV

Working
SSE2 tester dfr7190

Broken in and after SSE2 tester dfr7287i
dmp file
http://www.mediafire.com/download/s6qujpr0bqaixyi/mpc-hc_SSE2_tester_dfr7287i_(drag_and_drop_crash_dmp).zip

[JanWillem32]

I updated the first post. These builds were on request. I added the CIECAM02 (post resize) shaders to allow a similar extension as the original color management for the new monitor EDID-based simple color correction option. Use a program like MonInfo to find out the correct user white point for a monitor. The studio settings should be fine as they are, the user settings can be switched for 'average', 'dim' and 'dark' settings, along with an L_A setting that can be shifted a bit to suit a more specific surrounding.

Skibicki, that error should be fixed as well now. I do have to edit the window frame code again, as the window still has some visual artifacts in some resizing cases when no video renderer is loaded. I also still have to fix the code that handles the cursor on that window.

[XRyche]

How come you haven't based it on the latest stable release of the main MPC-HC?

The EDID-based colour correction is excellent for those of us that don't have calibration equipment. Thanks for doing this. Biased opinion , but meh :) .

[Hera]

Oh the optimized builds are back, yay

[fagoatse]

How come you haven't based it on the latest stable release of the main MPC-HC?

The EDID-based colour correction is excellent for those of us that don't have calibration equipment. Thanks for doing this. Biased opinion , but meh :) .

Since JW32 hasn't updated his patches for a long time and mpc-hc has seen a great amount of progress in 2013 so I assume it's a lot of work.

[Hera]

Intel Graphics which come with Haswell tablets cannot do floating point anything, right?

[JanWillem32]

Hera, the Intel video adapters have a specialized unit to perform scaling and mixing. It only accepts 8-bit or less inputs and no more than 8-bit R'G'B' output types. It is only fully used in combination with the EVR-based mixer, in which case it outputs a black screen if you give it an incompatible output type. When using VMR-9 it only fails to do scaling and chroma up-sampling on the floating-point and 16-bit integer surface types for output, which the renderer can easily correct.

The 'latest' version is old because I didn't update the past few months. It's mostly because I've been busy and away from home for extended periods. There's also the factor that updating is actually quite a hassle. It's not so much a problem with the code for the video and subtitle renderers section, as these are updated very rarely. It's mostely a problem with the code that does settings management and the huge class that handles the menus and such. These parts of the code are often updated, and because I've changed a lot of code in there to handle the updated/semi-new renderers merging code in same sections can take minutes to several days to handle conflicts when updating. Even then I have to test compatibility, as errors can sneak in unnoticed when updating.
I know I have to update at some point. I'll see when I can reserve a few days in a row.

I'm on a holiday at my parents' house right now. I do have a computer available to handle small code projects. By all means, ask for some things by PM, in this thread or in some other thread I track. I'll see what I can do to help.

Edit: the main reason I made that last set of builds is because of the updated color management. I added the new options to use monitor's EDID colorimetry and made the option to use the default profile even the renderer's default option. I also edited the color management option that uses .ICM/.ICC profiles. It might still need some editing to use the relative colorimetric option, but the other aspects of the system should be fine now.

[fagoatse]

Hera, the Intel video adapters have a specialized unit to perform scaling and mixing. It only accepts 8-bit or less inputs and no more than 8-bit R'G'B' output types. It is only fully used in combination with the EVR-based mixer, in which case it outputs a black screen if you give it an incompatible output type. When using VMR-9 it only fails to do scaling and chroma up-sampling on the floating-point and 16-bit integer surface types for output, which the renderer can easily correct.

The 'latest' version is old because I didn't update the past few months. It's mostly because I've been busy and away from home for extended periods. There's also the factor that updating is actually quite a hassle. It's not so much a problem with the code for the video and subtitle renderers section, as these are updated very rarely. It's mostely a problem with the code that does settings management and the huge class that handles the menus and such. These parts of the code are often updated, and because I've changed a lot of code in there to handle the updated/semi-new renderers merging code in same sections can take minutes to several days to handle conflicts when updating. Even then I have to test compatibility, as errors can sneak in unnoticed when updating.
I know I have to update at some point. I'll see when I can reserve a few days in a row.

I'm on a holiday at my parents' house right now. I do have a computer available to handle small code projects. By all means, ask for some things by PM, in this thread or in some other thread I track. I'll see what I can do to help.

Edit: the main reason I made that last set of builds is because of the updated color management. I added the new options to use monitor's EDID colorimetry and made the option to use the default profile even the renderer's default option. I also edited the color management option that uses .ICM/.ICC profiles. It might still need some editing to use the relative colorimetric option, but the other aspects of the system should be fine now.

Hm, I thought EVR changes regarding shaders and xysubfilter were quite large though oh and there's also this https://github.com/mpc-hc/mpc-hc/pull/126 which seems to be more or less the same work you already did on ISR.
Anywya, it's good to see you back and enjoy your holidays :)

[XRyche]

I wasn't criticizing actually, I was just generally curious as to why you haven't updated. I can be a bit annoying like that, always wanting to know the "how's" and "why's". Kind of like a 3 yr. old, I suppose. The fact that you're still actively involved in ongoing development of this render is a wonder and much appreciated.

Enjoy the time off with your parents.

[JanWillem32]

fagoatse, I'll see what code changes are required to implement xysubfilter compatibility. It's indeed one of the few large changes of the video renderer classes of the last few months. The video renderer I wrote handles the processing queue very differently than the version in the trunk. I might have to write some custom code to deal with xysubfilter. I had to do the same with the ISR queue in the past as well. It's not that much of a problem as long as there's a method implemented that allows queue synchronization or passing timeout values with rendering requests.

The shader changes were just superficial. I'll check out the code for the GUI again, but I think it will be fine. The shader interface to the renderer is simple. If extra logic is required, I can easily take care of it. I actually like the changes to these menus.

Pull 126 consists mostely out of changes to the internal subtitle renderers. I actually didn't modify these much (mostely because I absolutely hate the fact that this part of the code is shared by the ISR and VSFilter; both the design and code is horrible). I mostely redesigned the subtitle filter host that deals with queueing and serving communication between the video and subtitle renderers. That was mostely out of necessity, as the new set of video renderers/video renderer hosts are very incompatble with the old set.

XRyche, don't worry too much. I'm just glad that there are people available to test and report. You've been quite helpful with developing the CIECAM02 transforms and the EDID-based basic color management.

[Hera]

So, number one question on my mind, what is the future of this fork?

[ryrynz]

People have been asking this in one way or another for quite some time XD I think it's a case of Jan finishing off certain chunks or even the entirety of what he has planned so that it can be reviewed and committed but I would expect the entire process to take quite some time.

[dmiranda]

I know, I know, w7 is a better OS, but I am sticking to my old tweaked XP. However, the builds from the last 6 months or so (at least since 5050) do not work in my xp anymore. I get a

"The procedure entry point InterlockedCompareExchange64 could not be located in the dynamic link library KERNEL32.dll."

Maybe something like this in building the binaries?
"If not building in Windows XP but want the binary to be XP-compatible, enable WINXP_SUPPORT Cmake option."

[JanWillem32]

Well, that's a nasty bug indeed. It's something else from what you're thinking, though. The interlocked operands are native to all modern instruction sets (including x86). InterlockedCompareExchange64() is oddly enough implemented as a system call (supported since Vista) instead of a single instruction for x86-32. The intrinsic version is named _InterlockedCompareExchange64(). It maps to "CMPXCHG8B m64" in assembly and has been available in all x86 processor models since 1996. It's used in time-critical multi-threading routines to share data in memory. I used to assume that InterlockedCompareExchange64() and similar functions simply always mapped to the intrinsic versions. At least I know better now. Thank you for reporting this bug.
I replaced all interlocked calls by the equivalent intrinsic routines for the parts of the code I edited.
I also edited the color management section again to solve some minor problems and internally add some new features. The naming scheme of the .LUT3D files has changed. Older versions of the .LUT3D files are incompatible, and may be deleted.

x64: http://www.mediafire.com/download/m5s0ahsxrqs6dds/mpc-hc64_tester_dfr7370ri.7z
x86 SSE2: http://www.mediafire.com/download/5j2sz5skm96y55k/mpc-hc_SSE2_tester_dfr7370ri.7z
x86 SSE: http://www.mediafire.com/download/797b1q361sddb41/mpc-hc_SSE_tester_dfr7370ri.7z

[XRyche]

I just did an initial run and it seems to be good.

Did you do anything to the motion interpolation code? I'm generally not a big fan of motion interpolation. Most of the time the artifacts it produces are way too distracting for me to tolerate. It seems in this build I'm not getting a lot of artifacts. I suppose it might be driver related. I just recently update my drivers. Now only if you could have to scripts properly reinitialize while making changes in Full-screen on the fly. It tends to lock up or totally freeze the player. It has always had this issue when using using little cms and/or frame interpolation.

I assume that little cms still uses the system's icc profile and not the monitors EDID, since you left both options available. Did you make any changes to to the ambient light scripts (I believe you said that your CIECAM02 shaders are basically the same.)? Are they maybe 2.2=average user, 2.3= dim user, 2.4=dark user? Is it close? I assume there are some differences since little cms probably uses it's own conventions.

I really haven't had a lot of time this weekend to play with this build so these are just initial observations. I'll try to set aside some movie watching time next weekend :) .

[JanWillem32]

I pretty much always edit the frame interpolation code. It's a hassle to get it right with the varying amounts of noise and such. The basic version has been the same for a long time now. It's not the best way to handle frame interpolation, but it doesn't take much processing. The adaptive type does a simple area search for pixels of (nearly) the same color, records the 2D vectors of matching colors between each two frames and in the end, the final shader interpolates over these vectors with some special care for the cases where no matching colors were detected (it reverts to a simple linear interpolation in these cases). The adaptive type can resolve simple motion and interpolate using that data, but it mostly looks better because of the filtering to prevent artifacts.
This part of the code isn't really sensitive to driver changes. It's mostly the filtering passes of the mixer that are affected by those.

The code used to handle full-screen non-exclusive mode is terrible. If there's a feature of the player that I would like to completely drop support of, it's most certainly this one.
The routines that handle the window resizing, the toolbars and switching the full-screen non-exclusive are not part of the renderer. However, the full-screen exclusive mode is partially handled in the renderer code. (Except for the rainbow-colors problem of the AMD driver when 10-bit output is enabled that pops up sometimes, there are no real issues with the full-screen exclusive mode. It sadly just doesn't have much of a GUI.)
The main problem with the window handler is how it orders the toolbars. For the toolbars that don't get hidden there isn't much of a problem, except for the fact that the renderers don't get informed when toolbars are activated/deactivated. Another problem is the handling of the window layer. The player window in the full-screen non-exclusive mode often pops under the window used by the renderer.
For the main player bar in the full-screen non-exclusive mode with auto-hide functionality, the same problem applies. If the renderer wouldn't have a special section in the code to handle this problem, the main player bar would never be visible at all. The renderer code that handles this action is rather bad, and it breaks very often. (I can't help it, it shouldn't be there in the first place.) I'll try to fix it yet again... Thanks for reporting.

The code that uses Little cms does indeed use the installed .icm/.icc file installed for the active monitor. The CIECAM02 transforms happen before the Little cms transforms. The two don't have any overlapping settings. Only the "Ambient Light" setting is used by the CIECAM02 transforms. This setting is the same in both the renderer code as in the shaders.
The CIECAM02 default settings don't transform anything. That applies to both the transforms in the renderer code that wind up in the lookup table, as in the shaders. Only when setting different parameters from these defaults, colors will change. The "Ambient Light" setting is one part of that. Other parameters can be read from .icm/.icc files. (In the shaders you will have to enter them manually.)

[XRyche]

This build doesn't let me play DVD's at all. It also has issues with regular playback. It will stop at seemingly random intervals for no discernible reason at all and not continue playback . It doesn't matter whether I have any of the players extra features or not (IE. frame interpolation, little CMS, or even shaders). I'm using just LAV filters and nothing else (I don't use ffdshow's raw filter unless everything is working). It also seems to have issues with 10 bit encoded video, not all, just some. This is seemingly random as well, regardless of resolution or profile it was encoded with. A file encoded at 720p and 10@L5.0 will work fine while a file with the same attributes will not.
On another note, I still prefer the EDID colour correction method over little CMS. It's probably not the fault of little CMS but my pathetic .icc profile for my monitor.

[Aleksoid1978]

Hi JanWillem32.
I have a question - when receive message MFVP_MESSAGE_INVALIDATEMEDIATYPE call RenegotiateMediaType(). But what's interesting - in you build image is ok, in MPC-HC/MPC-BE - image is flashing.
How to reproduce - open flashing_video.mkv (http://www.mediafire.com/download/zswc6q9rt16azbe/flashing_video.mkv) with EVR Custom + Microsoft DTV-DVD Video Decoder. In you build playback is ok, in MPC-HC/MPC-BE image flashing.

Maybe you can help to fix this.

P.S. EVR don't have this bug.

[JanWillem32]

XRyche, I fixed the interfaces used by the DVD navigator. The next build should be a lot better when handling DVDs. However, I could not replicate the sudden freezing problem. You are sure that it's only in this last build? You did reset all program settings? Does this issue happen when the file does not contain subtitles? I know that the subtitle interfaces can deadlock in some cases. (A design issue, not caused by me.) Do you have a sample that always triggers this issue at some point?

Hi Aleksoid1978, I did some diagnostic tests on the problem you described.

The combination of flashing_video.mkv with the Microsoft DTV-DVD Video Decoder behaves oddly, to say the least. I tested several types of standard builds. The x64 debug type builds do not have an image corruption problem. On the other hand, the 32-bit debug type builds show heavy corruption all the time and will often produce almost completely black screens. Plain EVR behaves the same.
The release type builds behave as you described; sometimes a few fully black images return from the mixer with EVR CP. Plain EVR does not show image corruption. There are no reports of any rendering failures in all builds.
I also tested my builds. The 32-bit debug type build shows the same image corruption all the time for both EVR renderers. None of the three other build types show the corruption or flashing, as expected.

During debugging I did get a report of a serious error with the Microsoft DTV-DVD Video Decoder. At closing, a reference to the renderer's D3D main interface pointer is retained, causing it to never successfully terminate. When swapping the decoder with any other this event does not occur.
Note that I edited the closing sequences for the filter graph. The video renderers get closed after releasing all filters (to provide the guarantee that the main thread will destroy the renderer class, mainly to solve the issues with shared window handles and such). The D3D main interface pointer used by the renderer should should have absolutely no references with external items left at that point, as all filters should have been unloaded already.

I tested for two known bugs of the standard build EVR/VMR-9 renderer that are known to cause image corruption, but neither seem to be the cause in this particular case. So, I'm sorry to report that I probably fixed the flashing video problem by replacing most of the original renderer code and that there are still shutdown issues when using the Microsoft DTV-DVD Video Decoder. My best guess is that the Microsoft DTV-DVD Video Decoder reacts oddly to its host program, and fails at resource management.

[XRyche]

Ah thank you for correcting the DVD issue. As far as the sudden freezing problems, you guessed correctly. They were media files with subtitles (anime.....I guess the 10 bit gave it away lol) and it was while trying to use the internal subtitle renderer and not xy-VSFilter.

[JanWillem32]

For the subtitles, does it matter if you either set 0 or the usual ±10 as subpicture buffer queue size? The queued type is usually not given enough time to properly render and the other could deadlock more easily because of how it handles the rendering threads of the video renderers.

[XRyche]

Actually, I just now checked it again and it refuses to play some 10 bit files regardless of whether I'm using the ISR or xy-VSFilter. I also tried switching the ISR between 0 and 10+ subpicture buffer size and it did'nt make a difference. I am still using Vista 32 bit if that ends up being any help.

[JanWillem32]

Do you have a short sample? (You can split a small sample from a larger file with mkvtoolnix if needed.) I can test in the (somewhat working) compatibility mode for Vista to see if any issues pop up.
It could be a problem of the interlacing and frame time initialization routines that I edited recently. I can't really see why it would specifically affect 10-bit Y'CbCr encodes, though. (None of the four external mixers support anything but 8-bit R'G'B', 8-bit 4:2:2 Y'CbCr and 8-bit 4:2:0 Y'CbCr types.)

[Casshern]

That's also a question that comes to my mind. For me the new renderer works better than MadVR, so it would be fantastic to have it as a option in the main MPC-HC branch. It could peacefully coexist with the other renderer options (along with the current custom-evr) so not to break things for people using those. Is that a viable future option?

So, number one question on my mind, what is the future of this fork?

[JanWillem32]

Sorry, I don't work that way. I want to replace the complete sections for the video renderers and the attached subtitle renderers handler (I haven't edited the internal subtitle renderers much). Other parts such as the OSD modifications can go in as smaller patches.
There is a reason for that; in the beginning I assumed that the original renderer was somewhat decent, so I tried to patch some things and it turned out that whatever I tried to change, nothing I edited ever worked as planned. The code is bad in pretty much all possible facets. When I finally had enough, I evicted all code for the video renderers and imported a decent renderer to start off with. The code wouldn't compile for weeks. After patching, redesigning all interfaces and applying original code back into the project, I succeeded at compiling the project and rendering a video. I left no compatibility with the old set of renderers at all. I even had to redesign the two external renderer sockets for the project. (Which is actually only a few kilobytes of code, and is pretty much the same code used twice.) I removed the ancient DirectX 7 renderers. I broke the EVR sync renderer. As my two predecessors already botched some of the original EVR Sync code, it's not a great loss anyway. If we want to re-install the EVR Sync methods, I'd rather just import the methods from the original EVR Sync renderer that seemed to work into the current renderer as another scheduler option.
The code as I implemented it is maintainable (some specialist skills required for working with various parts), documented, and above all, decently optimized (there is always room for improvement, of course).
This is pretty much how I code (in this explicit order):
-when you have good base code; 1. expand its functionality, 2. optimize
-when you have a code that contains imperfections; patch it to get it up to par
-when you have bad base code; 1. get rid of the base code, 2. consider implementing good base code
I don't patch bad code and I change a lot of lines when I do choose to patch something.

[Casshern]

Does this mean that your new renderer (and the other supporting changes) will at some point in the future be integrated into the main branch, replacing the old renderer?

Or does this mean that your renderer (and the other supporting changes) will only be availabe in your fork for the foreseeable future?



Sorry, I don't work that way. I want to replace the complete sections for the video renderers and the attached subtitle renderers handler (I haven't edited the internal subtitle renderers much). Other parts such as the OSD modifications can go in as smaller patches.
There is a reason for that; in the beginning I assumed that the original renderer was somewhat decent, so I tried to patch some things and it turned out that whatever I tried to change, nothing I edited ever worked as planned. The code is bad in pretty much all possible facets. When I finally had enough, I evicted all code for the video renderers and imported a decent renderer to start off with. The code wouldn't compile for weeks. After patching, redesigning all interfaces and applying original code back into the project, I succeeded at compiling the project and rendering a video. I left no compatibility with the old set of renderers at all. I even had to redesign the two external renderer sockets for the project. (Which is actually only a few kilobytes of code, and is pretty much the same code used twice.) I removed the ancient DirectX 7 renderers. I broke the EVR sync renderer. As my two predecessors already botched some of the original EVR Sync code, it's not a great loss anyway. If we want to re-install the EVR Sync methods, I'd rather just import the methods from the original EVR Sync renderer that seemed to work into the current renderer as another scheduler option.
The code as I implemented it is maintainable (some specialist skills required for working with various parts), documented, and above all, decently optimized (there is always room for improvement, of course).
This is pretty much how I code (in this explicit order):
-when you have good base code; 1. expand its functionality, 2. optimize
-when you have a code that contains imperfections; patch it to get it up to par
-when you have bad base code; 1. get rid of the base code, 2. consider implementing good base code
I don't patch bad code and I change a lot of lines when I do choose to patch something.

[ryrynz]

If you've followed this thread at all you'll notice this branch isn't going to be merged for a long long time, if ever.

[Hera]

If you've followed this thread at all you'll notice this branch isn't going to be merged for a long long time, if ever.
And this is *very* bad.

A suggestion would be to rebrand and market as optimized and enhanced version. This version is ludicrously faster than the trunk version and more people should know about it.

[vBm]

It's unfortunate that source wasn't properly 'versioned' because in current state it's impossible to merge it. Changes are all over the place. If they were broken down into small patches then they'd be merged long time ago.

[Widdershins]

Hey JanWillem32, just posting to thank you for your work here. You are a golden god and I wish you the best.

[ryrynz]

It's unfortunate that source wasn't properly 'versioned' because in current state it's impossible to merge it. Changes are all over the place. If they were broken down into small patches then they'd be merged long time ago.
One would hope Jan could simply forgo further improvements in his branch to spend time doing just this.. Better sometime than never.

[JanWillem32]

I've been discussing some things with XRyche and I edited some code (partially on request). As other people might be interested in the changes as well, I made these new builds.
-I added the newer versions of the CAM shaders, partially to add some color controls.
-I made resizing stages more complicated, and more efficient.
-I optimized color management a lot, and I added quality improvements as well. Be sure to delete all old profiles from the program data (or the installation folder when using the .ini file to store settings) before using this version.
-I improved the quality of the stats screen graph drawing functions.
-Last but not least, I implemented some general optimizations for the quality mode code parts.

Note: D3DCompiler_46.dll is included only for Windows XP compatibility. For newer Windows versions only D3DCompiler_47.dll will be used. You can safely leave out the unused DLL to save some space.
x64: http://www.mediafire.com/download/3voegvawzog3189/mpc-hc64_tester_dfr7370rrri.7z
x86 SSE2: http://www.mediafire.com/download/wu03nps7jnicc9w/mpc-hc_SSE2_tester_dfr7370rrri.7z
x86 SSE: http://www.mediafire.com/download/dwuasmuhsoiacdr/mpc-hc_SSE_tester_dfr7370rrri.7z

[Tacio]

Does anybody know how to properly enable 16 or 32 presentation on the latest build? I have only a black screen on these modes enabled, 8 bits works fine though. Win 8.1 x64, GPU Intel HD3000, x64 build.

[Hera]

Does anybody know how to properly enable 16 or 32 presentation on the latest build? I have only a black screen on these modes enabled, 8 bits works fine though. Win 8.1 x64, GPU Intel HD3000, x64 build.
Did it work in the previous build? I vaguely recall being told Intel doesn't support it.

Will try latest build on my Surface 2 pro today ...

EDIT: No AVX / AVX2 builds?

[Tacio]

Did it work in the previous build?
No, it didn't. 10 and 16 bit output work just fine in MPDN player.

[Hera]

FYI,

Nvidia 344.11 + LAV + test build + 10 bit content + P010 output = Nothing Playing
I am not sure what is going on. I first thought it was a LAV issue, but it is worth posting here as well.

[v0lt]

@JanWillem32
Incorrect bicubic and Lanczos interpolation. Only one coordinate is calculated correctly.

[JanWillem32]

Sorry I have been away for so long. I haven't been actively developing any software-related stuff for a while until now.

About the EVR-CP renderer on Intel GPUs; it's a known issue of the EVR rendering path that it will output black screens without any warnings if anything other than 8-bit integer output surfaces is selected. It's totally because of the driver. I cannot fix that. This issue does not happen on VMR-9 r., by the way.

About the AVX builds; the AVX builds were mostly there for me to see how the compiler handled my code in that form. Apart from the AVX-specific part for the dither map code (available in all builds), the AVX builds don't have added functionality. I only compiled them when doing a complete batch as it takes more work.

Nvidia 344.11 + LAV + test build + 10 bit content + P010 output = Nothing Playing
I am not sure what is going on. I first thought it was a LAV issue, but it is worth posting here as well.You can try this version again. I added some better compatibility with several types. Note that results with EVR and VMR-9 may differ. If this one still outputs black screens, we can try to debug this issue with DXVAchecker and such.

Incorrect bicubic and Lanczos interpolation. Only one coordinate is calculated correctly.I revised several parts of the code for the resizers in this build. It should be less prone to bugs now. If there's still something amiss, please tell me.

-I re-optimized the methods for all resizers. The performance during (re-)initialization should be better now, and I possibly fixed some resizer section bugs along the way.
-I optimized all color management parts and fixed some minor things in the basic color correction code. I also made basic color correction mode 1 the default for when using the quality mode of the renderer. (When disabled, the renderer falls back to a generic, full-range bt.709 display mode for all video)
-I implemented full support for chroma up-sampling for even less common types of 4:2:2 and 4:2:0 inputs.
-I'm planning resizer pixel shaders for subtitles. I've been wanting to implement this functionality for years now, but it takes about as much code as the regular resizers, which is around 2000 lines of code. To indicate the scale of things: the current renderer is right now over 31000 lines of code. It would take at least several days of writing work on 100% efficiency and around a week of testing to get this functionality implemented. Some subtitle-related items have been changed already. If anything subtitle-related seems off in this build, please tell me.

Note: D3DCompiler_46.dll is included only for Windows XP compatibility. For newer Windows versions only D3DCompiler_47.dll will be used. You can safely leave out the unused DLL to save some space.
x64: http://www.mediafire.com/download/rz8d44oss8tnlyt/mpc-hc64_tester_dfr7370rrrri.7z
x86 SSE2: http://www.mediafire.com/download/i0b4l4fcmbvh00q/mpc-hc_SSE2_tester_dfr7370rrrri.7z
x86 SSE: http://www.mediafire.com/download/iz1iddtiako3tmr/mpc-hc_SSE_tester_dfr7370rrrri.7z
source code: http://www.mediafire.com/download/t469jfkmezp81uj/mpc-hc_tester_dfr7370rrrri_source_code.7z

[v0lt]

@JanWillem32
Mitchell-Netravali spline4 (PS 2.0) shader does not compile.

About the incorrect interpolation. Maybe I'm wrong. But I noticed that the one-pass interpolation gives a more symmetrical image on synthetic samples than two-pass. Similar results I have seen on some modes in madVR.
test synthetic sample: bw.avi (http://www.mediafire.com/watch/nhcokq9ebfrf492/bw.avi)

[JanWillem32]

Thank you for reporting the broken resizer. For some reason it was missing one character. I've just updated the four items linked in my previous post. Those that use this particular resizer or want the source code can re-download the files.

The bw.avi sample is excellent, really. It shows the benefit of doing linear light processing in the quality mode versus gamma-incorrect image resizing in the performance mode. About symmetry, I don't see any real differences in geometry when just scrolling through the list of resizers while playing the sample. Of course, each resizer does have different contrast, sharpness, interpolation shapes, ringing, et cetera.

[Dark Eiri]

Thank you for reporting the broken resizer. For some reason it was missing one character. I've just updated the four items linked in my previous post. Those that use this particular resizer or want the source code can re-download the files.

The bw.avi sample is excellent, really. It shows the benefit of doing linear light processing in the quality mode versus gamma-incorrect image resizing in the performance mode. About symmetry, I don't see any real differences in geometry when just scrolling through the list of resizers while playing the sample. Of course, each resizer does have different contrast, sharpness, interpolation shapes, ringing, et cetera.

Just downloaded your latest build on x64 and I'm getting "compiling resizer vertical pre-processing pixel shader failed" on every resizer :/

[JanWillem32]

Thank you for reporting. That pixel shader is part of the down-sizing resizers. I edited the files and I've just updated the four items linked in my earlier post.