MPC-HC tester builds for internal renderer fixes

[derpycat]

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.

thanks, works perfectly now :)

[gilic]

Fix confirmed, thank you!

Was this an old issue what just surfaced or was it introduced in some recent changes? In addition I'd like to ask if you have some sort of roadmap what you want to do in the future? Lastly are there actually speed gains when using the avx builds(is there avx optimized code)?

[Skibicki]

Playlist display is blank or incomplete during videos. Works in SSE2 tester dfr7100, broken in SSE2 tester dfr7190.
video closed in first image, open in second
http://imgur.com/dI6xbXk,IIJAlyT#0

[JanWillem32]

Skibicki, I was already afraid things like that might happen with the changes in the window handling code. Thanks for reporting, I'll just debug some more.

gilic, the issue was in handling user settings when initializing the mixer (a soup of code I wrote and original code).
I'll start with merging code to the trunk build before exposing/setting other future plans for now. Of course I can still do minor stuff such as adding resizers and such, but I'll avoid major changes.
AVX builds are mostly interesting for me to read assembly. As for actual optimizations, you're better off with me writing true SSE and AVX optimzed code, rather than expect the compiler will do so. I did write code that uses full AVX vector registers for some parts, but those can all be detected at runtime.

[generalmx]

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.

Excellent! Thank you very much. Now if only I could get ffdshow tryouts SVN builds either ignore 10-bit source or just not converting it down to 8-bit...Edit: Developed a hack that gets 10-bit working when 720p or better, but not 8-bit 720p. Oh well.

Also, I am using your latest 32-bit AVX tester build (non-debug) and the subtitles are still late. I can get them a bit faster by increasing the subpicture buffer up to 16+, but still they're not perfectly on time like xy-VSFilter. Average rendering time with your subtitle engine is ~30ms with a 5s peak of ~60ms (when xy-VSFilter is disabled of course), while xy-VSFilter has the rendering time reported as ~13ms for both. Some stuff that may be important: 2560x1440 screen, LAV Filters, madVR, ReClock, Core i3570k Windows 8 64-bit.

[gilic]

I did write code that uses full AVX vector registers for some parts, but those can all be detected at runtime.
So those code parts should already be used on my ivy bridge i7?

[Hera]

Finished entire series w/ 1.6.8.7197 (99c96dd)
Very stable after I reset the settings.

[khagaroth]

Resizer suggestion: ICBI (http://www.andreagiachetti.it/icbi/). Though it might not be suitable for downscalling.

[JEEB]

Decided to take the 7190-based build for a test drive to see the current situation with your custom EVR-based renderer... and didn't get too far. And yes, I did reset the settings before trying your binary.

No matter what I seemed to do, I would only get a black video surface. Tried to switch around the resizer in case that was the problem (bilinear, lanczos4, etc.), but in the end there was no difference. The ISR's output, and the statistics/OSD did get rendered on top of the all-black video surface, but that was pretty much it. This is on an nvidia 9600M GS with relatively up-to-date drivers so I would say that my setup should be in the range of supported things...

If you have any preferred way of going around debugging this, feel free to note.

[gilic]

Resizer suggestion: ICBI (http://www.andreagiachetti.it/icbi/). Though it might not be suitable for downscalling.

This looks promising when looking at the sample images, but I wonder if it will be fast enough. The reference implementation in CUDA discussed in the paper already needs 16.2ms to upscale a 128x128 image by factor 4.

@JEEB What's your surface setting under right click->Render Settings->Presentation? There have been issues with different AMD drivers, maybe your nVdia driver has something similar?

[JEEB]

@JEEB What's your surface setting under right click->Render Settings->Presentation? There have been issues with different AMD drivers, maybe your nVdia driver has something similar?
That's one of the settings I played around as well. As I said, I did reset to defaults, so it was 8bit integer at first, after which I then proceeded to test 10bit int and 16bit float. All of them give very similar results (10bit int is a bit different with dark grey instead of black, but I will bet that is actually a problem with my drivers or hardware taking in that kind of surface type in general than anything else).

Just to note, the nvidia driver version I am using is 314.22.

[gilic]

Hm too bad, you could try build 7100. I think this was the last one before the black screen bug has occurred the first time.

[JanWillem32]

generalmx, I didn't change much in the rendering engine of the various subtitle renderers, I mostly edited the part that connects them to the video renderers/blending section. I know that the subtitle rasterizers are still really slow. There are various problems with sharing the blob of code that it is now between the ISR and VSFilter. Because of these, I don't want to edit the subtitle renderers in their current shared form. I broke various parts of the subtitle renderer code over and over again because VSFilter and the ISR react differently. The absolute worst is that the sharing of the subtitle renderer code decreases efficiency of both VSFilter and the ISR.
By the way, when rendering at 2560×1440 the comparison with xy-VSFilter isn't really fair. Unless you use a 2560×1440 video to render on, the render size will be different. The ISR has to move textures before usage to video memory. On top of that, the subtitle renderer's ouput textures are pretty bad, shading is required for its blending functionality. Both of these actions require extra rendering time, but may be done asynchronously as usual. (Note: doing these actions asynchronously would mostly obscure the actual rendering time. The APIs that are in use don't allow measuring performance in a time fraction of a specific rendering pass if it's done asynchronously.)

gilic, for the parts I actually wrote with full-register AVX in mind, AVX is detected at runtime, and used instead of other routines. For the parts in SSE intrinsics and C/C++ scalar notation, the compiler can up-convert those to the half-register and scalar AVX instructions. I don't know how much performance profit is there to expect from such changes. I haven't seen the compiler even attempting to use full-register AVX operations by itself, and I've only seen very few samples that came out reasonably using compiler auto-vectorization of code.

khagaroth, that indeed does look interesting. The samples are unfortunately not even vectorized. I would have to do quite a lot of editing to insert it into the renderer, as it doesn't fit the regular one horizontal + one vertical resize system used by all multi-pass resizers I have right now.
I can easily do better than the 16.2 ms statistic gilic mentioned. I am worried though about the pass with the calculation of partial derivatives of the continuous interpolation method. For all current resizers these derivatives are mostly formalized before and at compile time (the quintic, septic and the sinc-based functions even to more degrees than one). Calculating the formalization of that at runtime can't really be optimized much, and is very expensive.

JEEB, did you try resetting the full set of settings or just the renderer settings? What output do you get when trying another mixer, such as VMR-9 r.? If it is an EVR-specific problem; how well do my previous builds work for you, and does disabling all enhancement filters in the graphics adapter's control panel help?
As usual, I can issue debug builds for this issue. If it's the driver fault, we can try submitting a bug report. We had good results in the past with getting such fixes on the driver side.

[JEEB]

JEEB, did you try resetting the full set of settings or just the renderer settings? What output do you get when trying another mixer, such as VMR-9 r.? If it is an EVR-specific problem; how well do my previous builds work for you, and does disabling all enhancement filters in the graphics adapter's control panel help?
As usual, I can issue debug builds for this issue. If it's the driver fault, we can try submitting a bug report. We had good results in the past with getting such fixes on the driver side.
I did and do a full settings reset before and after every time I poke these builds.

Didn't think of testing the custom VMR-9 renderer, that one seems to output a picture seemingly alright. I will test some older build later on, if I have the time. I have all of the video-related "enhancement" crap disabled in nvidia's panel (nvidia doesn't enable this stuff by default unless your screen is a "TV" afaik).

As for a debug build, I can produce one myself, was mostly thinking of if there was anything I could do before building such. I guess I'll try running a debug build under MSVS later.

[JanWillem32]

You will probably want to use the DirectX control panel. It's inside the DirectX SDK folder, and is seperate for x64 and x86, but both executables are named dxcpl.exe. "Maximum Validation", "Break on Memory Leaks", "Enable Multi-mon Debugging" and the verbosity slider will work fine. The reference and software devices are useless to the mixer, shader debugging doesn't work well with D3DEx devices and the debug build can select the debug runtime on its own when built with D3D_DEBUG_INFO defined (common.props). The warning messages about locking being unavailable and bound rendertarget textures in a rendering pass you can safely ignore.
As for the mixer, you can uncomment line 1649 of EVRAllocatorPresenter.cpp to allow testing the mixer transform status. Note that that line will fail quite often at any resets, such as on resizing. If it's failing continuously, the mixer isn't working.

[generalmx]

By the way, when rendering at 2560×1440 the comparison with xy-VSFilter isn't really fair. Unless you use a 2560×1440 video to render on, the render size will be different. The ISR has to move textures before usage to video memory. On top of that, the subtitle renderer's ouput textures are pretty bad, shading is required for its blending functionality. Both of these actions require extra rendering time, but may be done asynchronously as usual. (Note: doing these actions asynchronously would mostly obscure the actual rendering time. The APIs that are in use don't allow measuring performance in a time fraction of a specific rendering pass if it's done asynchronously.)
That's understandable, I just wanted to report it, as I've been using 1600p and 1440p rendering for years, as well as using your builds for years, and didn't have problems with subtitle syncing until I updated.

[XRyche]

For some reason ffdshow's video filters are crashing MPC-HC.

[JanWillem32]

As subtitle performance was reported as worse last time, I tried to fix some subtitle-specific SSE2 code this time. (Actually, I was just doing some housekeeping on SSE2 items. As I stumbled on some bad code in the vector subtitle renderer core, I decided to quickly fix some parts. As it was the typical subtitle renderer code, 'quickly' turned out to be not an option unfortunately.)
If any functionality broke, if there are cases of worse performance or there are crashes by the subtitle renderer when handling vector subtitles with these builds, please report.
I edited the window handling code again, to fix what Skibicki reported. If the video window broke again, please report.
I fixed some initialization and closing bugs for when using VMR-9 r..
I revised the custom pixel shader functions.
Because I edited the subtitle renderer this time, I probably broke VSFilter again in the worst possible way (the usual). I'll have to go through the agony of testing and probably fixing that again. That's why this version is only an intermediate. I did test these builds in combination with external filters this time.

x64: http://www.mediafire.com/download.php?oiztajygt5333u4
x86 SSE2: http://www.mediafire.com/download.php?s71fqukdpdvtfd7
x86 SSE: http://www.mediafire.com/download.php?lkolg3lt2wq6vee

XRyche, are the errors just stack overflows again?

[gilic]

I did a quick test and didn't notice any new bugs.

[JanWillem32]

As the edits in dfr7287i seemed to work well enough for all components, I decided to build a standard set this time.
I compiled these with Visual Studio 2012. I'd like to know if there are problems or improvements compared to dfr7287i (compiled with Visual Studio 2010). I edited as little as possible this time, so pretty much everything may be attributed to the compiler.
I linked to d3dcompiler_46.dll, as the new SDK supplies it. I don't know if it will improve performance. At a first glance, it seems to work pretty much the same as the previous version (43). If it doesn't seem to work, please let me know.
The links are on the first page.

[derpycat]

The new build seems to display weird subtitles. Some files display subs correctly but in other videos I get something in the format: "xyz,0,a,,0000,0000,0000,,b", where "xyz" represents three random numbers, "a" represents something like the name of the film, and "b" represents the actual subtitles. The font in these scenarios is in some cases very small as well (smaller than usual), though not in others.

[JanWillem32]

That seems to be an issue with some string parser for the SSA/ASS subtitle type. None of my current samples behave that way, so I'll need some help with this bug.
Is it specifically with build dfr7313? Does it happen with all variants of build dfr7313? Is the problem constantly reproducible on the same parts of a subtitle? Can I have samples of only the failing subtitles?
As far as I know this type of subtitle comes as either a separate SSA/ASS file or an embedded type for Matroska Media containers. If it's embedded you can use MKVToolNix' MkvExtract (with MKVExtractGUI-2 or MKVcleaver if you need a GUI frontend) to extract the subtitles.

[derpycat]

1. It doesn't happen in revision 7190, so it is a new bug.
2. It happens in the SSE2 and SSE versions, as well as the one I use - the x86 AVX version.
3. I haven't watched any subtitled films all the way through on this new build, but playing them briefly or seeking throughout them seems to show that problematic ones stay problematic throughout the entire duration, while problem-free films run fine. The same files always display the same symptoms (i.e. it's consistent whether a file is problematic or not).
4. It seems all the problematic files use ASS/SSA subs. In those files that have multiple types of sub file, any non-ASS/SSA subs work fine.

I've attached one of the ASS subs as requested (sorry, it's actually a ".ass" file, but it's renamed to ".7z" so it could be attached - I've no idea how to upload a file more gracefully :p).

[JanWillem32]

I mostly meant dfr7313 versus dfr7287i, dfr7190 is rather old. I changed quite a lot of subtitle-specific code after dfr7190, but I didn't change anything subtitle-specific after dfr7287i.
ASS/SSA, SRT and TXT subtitles are plain text, and can be opened with notepad. You can put shorter strings of text in a post here inside a CODE block, else there are services such as pastebin.com that are more suitable for larger amounts of text. Attachments require approval, which may take a while.

[derpycat]

Derp. I deleted the sub file and uninstalled and deleted the MKV extract program. It never helps when I obsessively delete files immediately after using them in order to keep my pc "tidy" lol. Well, here it is anyway: http://pastebin.com/2tkXJ3Qv

And it seems dfr7287i (SSE and SSE2) has no problems interpreting ASS/SSA subs either.

[Gaius]

I'm new to these builds and I'm wondering, is there a guide to which resizer works the best according to what hardware you have? Is the resizer that is set by default (Mitchell-Netravali Spline4) what most people should use?

[derpycat]

Another bug that is nonexistent in 7190 and 7287i: wmv files crash the player. Fault module is quartz.dll, if that helps.

[fagoatse]

I'm new to these builds and I'm wondering, is there a guide to which resizer works the best according to what hardware you have? Is the resizer that is set by default (Mitchell-Netravali Spline4) what most people should use?

I doubt thats the default resizer. Anyway, I run bicubic A = -0.6 on my amd apu e-350 just fine. I guess 10bit integer with some basic dithering would do if i drivers werent broken lol.
Has anybody benchmarked JW32's ISR vs xy-vsfilter btw?

[Tyestor]

Subtitles are borked.

Build 7313 x86 AVX w/ LAV Filters 0.57 and madVR 0.86.1. Works fine if I disable the ISR and use xy-VSFilter.

ISR on, xy-VSFilter off: http://i.imgur.com/M2p8Ez2.jpg
xy-VSFilter on, ISR off: http://i.imgur.com/M2p8Ez2.jpg

Subtitle file: http://www.mediafire.com/?taj2s7v3712nc7o (I demuxed this from an mkv w/ mkvmerge, that's why it's .mks. It's aactually an SRT sub file).

EDIT: Oh and MPC-HC also crashes when doing this (same file as the above issue): Right click video > filters > DirectSound: Speakers *sound device name* > Pin-Info
Here's the minidump: http://www.mediafire.com/?ybllcrolp1gc91u

[PetitDragon]

Thank you Jan for the new Build 7313. Implementing D3D Fullscreen mode with 10-bit Output is really greate.

I would report some problems here:

1, When Switching from GDI Fullscreen to D3D Fullscreen (Ctrl-Alt-F), mouse cursor disappears.
2, D3D Fullscreen mode seems to not work well after auto-changing display refreshrate (It just goes black screen). Restarting MPC-HC solves the problem.

Thanks again for your hard work.

[gilic]

fyi there is a rewrite for the d3d fullscreen implementation here https://github.com/mpc-hc/mpc-hc/pull/89

[PetitDragon]

Thanks for the news.

Unfortunately it (7361 test build from Armada651) crashes immediately if I run D3DFullscreen mode with 10-bit output. And switching between GDI Fullscreen and D3D Fullscreen seems to not be implemented yet.

[gilic]

I don't use d3d fullscreen, but did just now a test (with 10 bit output): the display reinitialized, i had no video and apparently i lost my highest resolution setting in the windows settings o_O Fixed it with a pc restart.

[JanWillem32]

I could luckily reproduce pretty much all issues reported here. That is; on release versions of x86 builds, but not in debug builds nor on x64.
It was rather hard to analyze and fix the problems. All issues reported turned out to be a single bug in the compiler.
For this reason, I removed the links to the problematic builds in the first post.
While debugging, I got a report that stated some ISR functionality was still broken. Compared to VSFiler, the ISR didn't scale subtitles to anamorphic video correctly and blur effects were not scaled correctly either. I fixed these bugs.
I also fixed an initialization bug for the x86 SSE build for when using EVR CP.
There's a good chance that all newly reported bugs are solved. Please report if some things are still broken.

x64: http://www.mediafire.com/download/rfa29pc79m6e0nh/mpc-hc64_tester_dfr7313ri.7z
x86 SSE2: http://www.mediafire.com/download/wjab3zj369dth93/mpc-hc_SSE2_tester_dfr7313ri.7z
x86 SSE: http://www.mediafire.com/download/tz54l65wt0s1r8m/mpc-hc_SSE_tester_dfr7313ri.7z


Gaius, that resizer is indeed default. As to how heavy the resizers are, they pretty much scale linearly by the number of samples in their kernel. Lanczos filters are slightly heavier on average because of their sine-based functions and truncated kernel compensation function.
-Nearest neighbor is the lightest, but mostly for testing purposes. (1 sample in its kernel)
-Bilinear is available for systems that can't use heavier resizers, it's light and looks at least decent. (2 samples in its kernel)
-Perlin smootherstep is the first pixel shaded resizer in the list, it's therefore significantly heavier than bilinear. (2 samples in its kernel)
-Spline4, cubic and Lanczos2 filters are two-pass, and are therefore significantly heavier than the three single-pass resizers. (4 samples in their kernels)
-Spline6 and Lanczos3 filters are next. (6 samples in their kernels)
-Spline8 and Lanczos4 filters are next. (8 samples in their kernels)

If a resizer pass isn't required, the renderer will either skip it if possible, else it will issue a surface copy.
As for personal preference, just try them. Tey all have different properties in terms of percieved sharpness, aliasing, anisotropy etc..
It's possible you can't see the difference between the Catmull-Rom spline and the Lanczos types. Rest assured, neither can I. Their filter kernel weights are really close to one another, so that's to be expected.
In general, I would say that any GPU that isn't an old IGP or on a very low-budget card, and is set to decent clocks will be able to run all of these resizers. Otherwise, you are generally stuck with bilinear, as pixel-shaded resizers are significantly heavier than the fixed-function nearest neighbor and bilinear parts.
Note 1: the input video resolution doesn't matter for a resizer itself in terms of processing load.
Note 2: when down-sizing, pre-processing requires an additional, rather heavy processing stage. It is only enabled for pixel-shaded resizers because of that.

fagoatse, I don't think benchmarking is that useful. I didn't really change much in the subtitle renderer that will cause it to really outperform the one in the trunk build. I mostly focused on fixing the bugs that were reported.

PetitDragon, D3D fullscreen mode is easy in a normal D3D program, but difficult to use in MPC-HC. The code for the main player window and attached parts (where the main thread runs in) are really unsuitable for interacting with D3D. Handling D3D correctly would require refactoring tons of code.
This part of the code is edited often by other programmers (it just does a little bit of everything). Refactoring it would probably mean major issues when merging updated code from the trunk build.
It is on the agenda, but preferably after merging to the trunk.
The auto-change display refreshrate function is completely independent from the renderer. The video renderer has no clue whatsoever that something might have altered the refresh rate during playback. However, the video renderer is required to pass a refresh rate to its initialization/reset function. Its current behavior is to try not changing it. I will investigate this issue some more, perhaps I can improve compatibility. A better option would be to let the renderer handle refresh rates natively.
I can fiddle a bit with the mouse cursor code parts, I made some changes to those in these builds.

[derpycat]

The wmv and ASS subtitle problems seem to be fixed. We appreciate your hard work :)

[janos666]

There seems to be a problem with the 32-bit surface format which also causes the D3DFS mode to show a constant black screen (at least with 10-bit display mode enabled).

And I just noticed that I get incorrect black levels. Video Y=16 is not R=G=B=0 now (not even on the black bars below and above the 2.35 picture on a 16:9 TV) but it's 13,11,12 (weird).

MPC-HC 7334 SSE2
Catalyst: 2013.04.16 (13.5b2)

[fagoatse]

There seems to be a problem with the 32-bit surface format which also causes the D3DFS mode to show a constant black screen (at least with 10-bit display mode enabled).

And I just noticed that I get incorrect black levels. Video Y=16 is not R=G=B=0 now (not even on the black bars below and above the 2.35 picture on a 16:9 TV) but it's 13,11,12 (weird).

MPC-HC 7334 SSE2
Catalyst: 2013.04.16 (13.5b2)

Same driver and hd6300 here and 16fp/32fp somewhat work but 10bit integer is totally broken. There are some weird glitches on darker(greenish layers of pixels or sth) areas of the video. It's definitely a driver bug. What about non-d3dfs mode?

[JanWillem32]

Because internal filters wouldn't compile again, I made Lite builds this time.
I made some minor optimizations to the frame interpolator, it's a bit more efficient now. I also re-named its options in the menus.
I removed the 10-bit surfaces option (didn't do anything for quality anyway), and added a full 32-bit floating-point path again (for debugging). This means that users will have to reset their setting for the surfaces option.
I added the B-spline8 resizer. Users of the last 4 resizers will need to reset their resizer setting.
I revised the chroma up-samplers, and added B-spline8. Users of the last 4 resizers will need to reset their up-sampler setting.

x64: http://www.mediafire.com/download/evjavn02xgg8npd/mpc-hc64_tester_dfr7370li.7z
x86 SSE2: http://www.mediafire.com/download/vmlehsb4jey6qm6/mpc-hc_SSE2_tester_dfr7370li.7z
x86 SSE: http://www.mediafire.com/download/kow3166qh7dn0ak/mpc-hc_SSE_tester_dfr7370li.7z

janos666, these issues are a bit odd. I have a card of a previous generation (using the 13.4 legacy driver), and I can't replicate any of the issues. Does it matter if resizing is active or not? Are you sure all the video filters are disabled in the CCC?
I made the fully 32-bit floating-point path available again, maybe that can help to debug these problems.

[PetitDragon]

@JanWillem32 or other experts

When I use linear RGB optimized shaders with the recent test builds, do I still need to do manually such as following:

(pre-resize)
1, "gamma conversion of video RGB to linear RGB for floating point surfaces"
2, "r=6, sharpen complex, deband and minimal denoise"
(post-resize)
3, "gamma conversion of linear RGB to video RGB for floating point surfaces"

or I just add "r=6, sharpen complex, deband and minimal denoise" only and it's done (because already linear RGB internal including resizers?)?

Additional, when doing "16/32-bit Floating Point Surfaces" processing, I notice the surface is "A16B16G16R16" (16-bit integer). Then what type of conversion shader should I use (still floating point, or integer)?

Thanks in advance for help.

[janos666]

Where did you get this D3Dcompiler_46.dll file?

I can't use EVR-CP without this (the player semi-silently falls back to the default "video renderer": I get an error message about the missing dll from EVR and the video shows up without further error informations) but mpc-hc.exe instantly crashes during the file opening if I leave this dll in the directory.

I just ran the DirectX End-user runtime web installer and D3DCompiler_43.dll is the last version I get in my system32 directory (Windows 8 x64). Did this come from the latest Visual Studio? I couldn't find a separately downloadable Direct SDK installer which is newer than the latest end-user runtime installer (both from 2011 with the v43 dlls).

[JanWillem32]

D3Dcompiler_46.dll is indeed part of the new SDK.
Loading the dll should not be a problem. I just verified the content of my previous SSE2 upload and the correct, intact dlls are in the archive. Is the crash report really pointing at D3Dcompiler_46.dll?
Maybe a debug build can help. (This one does not require the D3D debug runtime.)
mpc-hc SSE2 debug tester dfr7370li: http://www.mediafire.com/download/dggo8rvm1s6z8cj/mpc-hc_SSE2_debug_tester_dfr7370li.7z

PetitDragon, the renderer uses full range R'G'B' (of the input format, usually HD, NTSC or PAL/SECAM) in the 8-bit performance mode. It uses linear XYZ in the quality mode, full range for the floating-point types, limited range [16384/65535, 49151/65535] for the 16-bit integer mode. For the quality mode the renderer offers the user the option to disable the color conversion steps from the mixer output. That disables the optional chroma up-sampling as well.
When I have the time, I should probably update the pixel shader set. A lot has changed about the renderer in the mean time.

[PetitDragon]

Thanks Jan for the answer. Can't wait to to see the updated pixel shader set, for the new test builds.:thanks:

[gilic]

Is it possible for the frame interpolator to interfere with the ctrl+j statistics? I noticed some warping around some letters in the top left corner of the video.

[JanWillem32]

Yes, indeed. I wrote it as a merged filter with the final pass. That means it alters the OSD, stats screen, and worse of all, the subtitles. I should probably just move it to a pre-resize stage.

[berga.d]

Hi JanWillem, I've found some problems about the color management changes in last months builds.
It seems you've removed the "perceptual" intent, and now using an ArgyllCMS LUT profile generate some weird problems, like brown instead of black, and all the whitelights crushed in White in 2.2 gamma, or a blue tint using 2.4.
It doesn't seems to change between relative/absolute/BP compens/White adapt.
The profile works ok using standard mpc-hc CMM and perceptual intent.
Here a link: http://sdrv.ms/10YCOk0

[derpycat]

Oh I just noticed while SSA subtitles are fixed, .srt external subtitles crash the player with a ntdll.dll fault module. Builds 7287i and 7190 are fine, but anything after that crashes immediately.

[Casshern]

Does this version of MPC peacefully coexist with the MPC-HC main branch? Are the settings stored independently?

[nghiabeo20]

Hi Jan Willem, I can't use your builds. I tried build 7100 x86 sse2, but it show an error message: mpc-hc.exe - Entry Point Not Found: the proceduce entry point RegGetValueW could not be located in the dynamic link library ADVAPI32.dll. Please help me!

[nevcairiel]

Does this version of MPC peacefully coexist with the MPC-HC main branch? Are the settings stored independently?

No, the settings are the same as normal MPC-HC.

[fagoatse]

No, the settings are the same as normal MPC-HC.

Well, except for some renderer settings.

Revise you settings when going from vanilla to jw32 or just reset them to default values.