MPC-HC tester builds for internal renderer fixes

[JEEB]

BTW, as you now have your own git fork, I really recommend you look into 'git rebase'. Rebasing is not something you should do on a stable repository, but it is very useful for keeping up to a remote.

With merging you get:
<older commits you originally forked onto><your changes><merge commits><your changes><merge commits>...

With rebase you get:
<older commits><newer commits from upstream><your changes>

It should be quite obvious why the latter is better when working on a fork, as you will be able to keep those changes always up-to-date to the current status of upstream, unlike what you do with, say, svn or cvs. Of course, git rebase will change the history of the repository, and, thus, will also require you to force the push. The way to keep certain changesets in the repository for keeping the source code around for various releases is to make annotated tags of all such points.

As you already have merge commits in your current master, you also might have to use interactive rebasing (git rebase -i), which will basically let you select the commits you want to rebase onto a given branch's current HEAD. Although I do recommend setting the text editor of your choice as the EDITOR variable before doing it, as by default it will open vim, and not all people are used to it :) . Same goes for commit messages, but this is a bit more important to be in complete control of.

Documentation: 1 (http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) (rebase), 2 (http://git-scm.com/book/en/Git-Branching-Rebasing) (rebase), 3 (http://learn.github.com/p/tagging.html) (tagging).

Example of a rebase:

git fetch remotename (fetches the information of that remote's current status, 'git pull' is internally 'git fetch && git merge')
git rebase remotename/branchname | git rebase -i remotename/branchname (I don't remember if it was remotename/branchname or remotename branchname, but it should work like that, either normal automatic rebase, or a manual interactive rebase)

If a rebase fails at something, in most cases you can just drop out of it with 'git rebase --abort'.

[JanWillem32]

I integrated revisions from the trunk twice: https://github.com/JanWillem32/mpc-hc/network .
I haven't had the pleasure of resolving code yet, as nothing clashed yet. I'll keep my fingers crossed and hope for the best for once that does happen. Once I get home, I'll try to update my fork further. The only renderer I (partially) updated for now is the OSD, which is tiny compared to any other renderer.

[JEEB]

I'm just noting that for such usage as yours, rebase > merging. When you have the time you can try it with a separate branch or even a separate clone of the repository if you're afraid of breaking something while learning it.

tl;dr It's better to have your own changes always at the top of changes, and not somewhere in the middle with merges in between.

[JanWillem32]

Not much new this time. I've mostly been struggling with integrating the various changes from the trunk.
If anything on the new Options, Output tab doesn't work, please report. Pretty much all functions broke when integrating it, and I haven't had the time to test everything.
I did change a few things:
I changed the Lanczos filters to windowed filter truncation factor compensated types, to alleviate some of the artifacts. If users like this modification, I'll keep it. Please report if anything seems wrong with the filters. I'm planning to add the Lanczos filters to the set of chroma filters soon.
The 32-bit surfaces type has been changed to 32-bit floating point mixer surfaces (I can't get around that, the mixer design is poor when using integer output surfaces) and 16-bit unsigned integer surfaces for the regular surfaces (compressed interval to center; black at .25, XYZ color space white at .75). I haven't adapted the color management yet, so only the bt.709 profiles work for now. The renderer will transform video of the two bt.601 types correctly to XYZ on entry, so using a bt.709 profile won't damage quality of the colors inside the profile. 3D lookup table constructors with a better flexibility and range than a static bt.709 profile are possible, but I'll have to write them first. Note that xvYCC compatibility on incoming video is already working with the 16- and 32-bit floating point surface types. I'd like to add support for extended color on display output with color management enabled as well.

x86 SSE: http://www.mediafire.com/download.php?suz70unfdmve3ob
x86 SSE2: http://www.mediafire.com/download.php?7v7iwin8mzatkna
x64: http://www.mediafire.com/download.php?a1231ehd2s429aq

[Anatasia]

Remember file position is not working. Personally, I do like the lanczos2 filter,less artifacts IMHO.

[Skwelcha]

I can confirm the problem for the file position, it's the same here unfortunatly :/
It always unticks itself after closing MPC-HC

[JanWillem32]

Thanks for reporting. I fixed it, but it wasn't odd I broke that in the first place. It was in one of those parts again that needs some proper maintenance. For programmers: we generally use an 'm_' (or some similar) prefix on named variables inside a class. Unfortunately, the main application settings class doesn't have this kind of naming. When performing maintenance on such parts, there's quite a risk that things break because programmers can't discern local function variables from class variables. Various other code, such as that for the renderers were not flawless in this aspect either. I fixed a lot of things by simply renaming variables properly and checking the code associated with those.

[ForceX]

16 bit Floating Point output now looks messed up, and 32 bit FP has opaque box around subtitles, stats screen is illegible. Previous build was working fine.

And 32 bit FP seems to take quite a bit to initiate. Each time the OSD pops up the screen turns black for a second or so.

[JanWillem32]

Let's try to debug that. Can you make screenshots (or partial ones) of the issues with the renderer in a near-neutral state? Reset all your settings (miscellaneous tab) and only enable the 16-bit floating-point or 32-bit floating-point surfaces. I might have struck some hardware or driver incompatibility (as it seems to work perfectly fine to me).

[ForceX]

Settings reset.
Proper output in FP32 http://i.imgur.com/JBtQr.png
FP16 http://i.imgur.com/P5rdI.png
FP32 Subtitle http://i.imgur.com/hy14k.png

And about OSD in FP32, as long as the OSD is shown the screen is blank http://i.imgur.com/WChcg.png

Stats in FP32, same frame: http://i.imgur.com/ekzyC.png (no video)
http://i.imgur.com/5TOGQ.png (video visible)

Int10 has always been horrible (somewhat like FP16 now, but worse) for me so I never used that.

Nvidia 310M, Forceware 302.77

[JanWillem32]

The transforms I wrote are indeed not very suitable to be used with 10-bit normalized unsigned integer surfaces. Maybe I should just scrap that one.
I think I gravely overestimated the precision of the FP16 format. The banding is extreme. I'll try to mend that one later (I'll try a different interval). For the FP32 one, I wonder why a Direct3D 10.1 compatible GPU would have issues with alpha blending stages (subtitles, OSD stats screen) on 16-bit normalized unsigned integer surfaces. Complete compatibility with this format, with all operations is required for Direct3D 10 certification. (It's in the compatibility list: http://msdn.microsoft.com/en-us/library/windows/desktop/cc308051%28v=vs.85%29.aspx .) Let's see where I can find a contact form, maybe it can be mended by a driver update.

[HitomiKun]

I recently found an mpciconlib.dll in your mediafire folder. I set it right next to my mpc-hc.exe, but it still shows "no mpcinonlib.dll found". Did I do something wrong?

[JanWillem32]

I think I mixed up the x64 and x86 ones, so I re-compiled and re-uploaded them.

[Skibicki]

Has anyone tried this player on Windows 8 RTM? I did and noticed EVR-CP works poorly compared to Win 7, of course this should be expected on a new OS but I thought was interesting.

[burfadel]

What do you mean by it working poorly? Can you explain?

[Skibicki]

What do you mean by it working poorly? Can you explain?Video was stuttering.

[onomatopellan]

Tried latest version 5855li and it works fine in Windows 8 Pro RTM.

[sexus]

hey janwillem32 how you feel about joining the BE mod project its being started up again , im sure you would make an excellent addition to the team

http://sourceforge.net/projects/mpcbe/

[Squallff8aus]

Hi Jan,

I would like to report a problem that I've encountered while using both the x64 and x86 version of the mpc tester dfr5855li.
I have 3 monitors. Each driven by a different video card. Left monitor is driven by a AMD HD6450. Middle Monitor : AMD HD7800. Right (TV) monitor: Intel HD 3000 in a i7 2600 CPU.

While playing a video (that is started on the middle monitor), when I drag the video to the right monitor I get a BSOD. But it is perfectly ok if I drag it to the Left monitor. I tried this with AMD HD7800 and Intel HD 3000 as the renderer.
The BSOD message can be seen here: http://desmond.imageshack.us/Himg854/scaled.php?server=854&filename=img0081lbh.jpg&res=landing

I've also tried this briefly with mpc-hc SSE2 tester dfr5494li and the same thing happened.

mpc-hc64 AVX tester dfr5050_x64 and the x86 equivalent did not have this problem.

Thanks.

[G_M_C]

Hi Jan,
[...]
The BSOD message can be seen here: http://desmond.imageshack.us/Himg854/scaled.php?server=854&filename=img0081lbh.jpg&res=landing
[...]


Also see: http://msdn.microsoft.com/en-us/library/ff558949

The most posted recommendation is that you update all video-drivers and see if problem persists.

[JanWillem32]

Today I had some time to spare to do some programming (only 2 minor changes).
I fixed a DXVA closing problem during resets. Resets should be faster now, both with DXVA decoding active and without.
I added extra constants to the pixel shader post-resize stage. The rules can be seen in the basic pass-through pixel shader. These changes are fully backwards compatible.

x64: http://www.mediafire.com/?5ylgg8rdci1br9b
x86 SSE2: http://www.mediafire.com/?kad1yznowhxaomp
x86 SSE: http://www.mediafire.com/?h8qq0o64s7uk7x8
The pixel shaders that require the new constants:// (C) 2012 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// Side-by-side to checkerboard 3D stereoscopic view
// This shader should be run as a screen space pixel shader.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// For this shader to work correctly, the video width on screen has to be an even amount and be fully visible.

sampler s0;
float2 c0;
float4 c1;
float4 c2;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
if((tex.x >= c2.x) && (tex.x <= c2.z) && (tex.y >= c2.y) && (tex.y <= c2.w)) {// test for within video rect
float2 vr = c0.xx*c2.xz;
float2 CurPixel = tex*c0;
float ox = CurPixel.x-vr.x;// video-relative x position
float PixelOffset = floor(-.5*ox+.25);// the two images are half-width, compensate for that, round half-pixel offsets down

float2 MonitorPos = CurPixel+c1.zw;// to monitor-relative coordinates
// check to see if we need to be using data from the frame on the right side of the video data
float n = frac(dot(1, MonitorPos)*.5-.25);// also compensate coordinate right-left

// adjust the pixel offset, in to the video frame on the right side of the video data where required
if(n >= .5) PixelOffset += .5*(vr.y-vr.x);

// adjust the x coordinate of the source position to the correct side of the video image using the pixel offset we just calculated
tex.x += PixelOffset*c1.x;}

return tex2D(s0, tex);
}


// (C) 2012 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// Top-and-bottom to checkerboard 3D stereoscopic view
// This shader should be run as a screen space pixel shader.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// For this shader to work correctly, the video height on screen has to be an even amount and be fully visible.

sampler s0;
float2 c0;
float4 c1;
float4 c2;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
if((tex.x >= c2.x) && (tex.x <= c2.z) && (tex.y >= c2.y) && (tex.y <= c2.w)) {// test for within video rect
float2 vr = c0.yy*c2.yw;
float2 CurPixel = tex*c0;
float oy = CurPixel.y-vr.x;// video-relative y position
float PixelOffset = floor(-.5*oy+.25);// the two images are half-height, compensate for that, round half-pixel offsets down

float2 MonitorPos = CurPixel+c1.zw;// to monitor-relative coordinates
// check to see if we need to be using data from the frame on the right side of the video data
float n = frac(dot(1, MonitorPos)*.5-.25);

// adjust the pixel offset, in to the video frame on the right side of the video data where required
if(n >= .5) PixelOffset += (vr.y-vr.x)*.5+.5;// also compensate coordinate bottom-top

// adjust the y coordinate of the source position to the correct side of the video image using the pixel offset we just calculated
tex.y += PixelOffset*c1.y;}

return tex2D(s0, tex);
}
@Squallff8aus: If updating the driver doesn't work, we can try a debug session with the Direct3D runtime and MPC-HC in debug mode.

@sexus: If a project is in need of a DirectX 11 + low-level procedures (SSE, assembly, intrinsics, etc.) specialist for some parts, help can be requested. Though generally, I do not care about anything GUI related.

@Skibicki: I also heard that the quality of drivers for Windows 8 varies. The revised driver model is a major factor, of course. Are your drivers up-to-date? How is the base performance in D3D fullscreen mode? If performance problems persist for a while (after a few driver revisions), we can try to do some performance tuning.

@ForceX: I'm sorry, but I still don't have an update on your issues yet. The FP16 issue needs fixing on my end (it's not that difficult), but I really think the UI16 format is broken in the driver. There's nothing wrong with the compatibility testing and handling of the format in the renderer as far as I can see.

[sexus]

its not just the gui being modified theyre changing quite abit about the entire layout and player , you should check it out janwillem , id really appreciate it if youd join in , not like ive requested you to do gui stuff ,lols

of course i requested you because you bring so many great additions to mpchc , im serious , please reconsider and please contact them , only epic things could come of this teamup , peace

[Skibicki]

@Skibicki: I also heard that the quality of drivers for Windows 8 varies. The revised driver model is a major factor, of course. Are your drivers up-to-date?It was a mistake, I had the internal subtitle renderer enabled. Performance appears to be same as Win 7
Win 8 RTM
AMD 12.8 drivers
LAV Filters 0.51.3
xyVSFilter 3.0.0.144

[burfadel]

Alternative scheduler uses considerably more CPU (at least double).

[Nyanya]

broken chroma up-sampling is still occurred in your latest build (EVR CP/ Intel HD4000 - latest official Intel driver for win 7 / Win7SP1).
is there possible to fix that like MPC-HC do for ATI/AMD before ... ??

Thanks for your hard work !!, Sorry for my "engrish" ...

[THX-UltraII]

What are the benifits of using this MPC-HC version instead of the regular build?

[JanWillem32]

@burfadel: On my performance monitor I see about 40% higher peak load, but an average that is pretty much the same for windowed mode. The difference is less for D3D FS. If your performance logs indicate a higher average load, I'll gladly take a look at them. The subjects of interest are MPC-HC, DWM.exe, the service started by the video card manufacturer, and maybe others that are using a bit more resources during playback (I'm not sure which ones would).

@Nyanya: What are the surface types during playback? The renderer in quality mode (10-, 16- or 16/32-bit working surfaces) should automatically pick up the chroma type for surfaces such as NV12 or YUY2 and add the chroma up-sampling stages to the renderer chain for video cards identified by either the AMD, ATi or Intel manufacturer code. The working surfaces type, the video transport type to the mixer and the video card's ID should all be visible in the main stats screen during playback.
The chroma up-sampling method is selectable in the "Renderer Settings", "Presentation" menu.

@THX-UltraII: I mostly specialize in changing the custom video renderers and support for the external video renderers with a socket for the subtitle renderer. I will sometimes be tempted to edit parts of the subtitle renderers themselves. I recently also edited the OSD and audio switcher to name some other parts. I'm more into the experimental kinds of changes (that also rely heavily on driver support for some parts), and because of that, my work needs quite a bit of testing (before I start with the typical optimization of routines, of course). Plenty of posts in this thread are about performance gains. The quality of the renderer path is currently in a bit of an intermediate state for the 10- and 16-bit types (they don't handle the color space well). The 16/32-bit mixed type apparently has a driver problem in one case as well. These are still experimental builds; there's plenty still to do. If one doesn't work for you, report the problems. I sometimes also do feature requests. I sometimes do private debugging sessions. I also keep older versions of the builds around for debugging. (Things tend to break at a certain point, but are usually reported much later.) Anyway, if people know that these builds are experimental, and can be of use to me while developing, I'll happily invite people to try a few builds.

Latest work done: I changed the new feature of the pixel shaders to handle the video rectangle better. The next build will change variables a bit, so that for the pixel shaders I posted two days ago, the video on screen doesn't have to be fully visible anymore.

[Nyanya]

@Nyanya: What are the surface types during playback? The renderer in quality mode (10-, 16- or 16/32-bit working surfaces) should automatically pick up the chroma type for surfaces such as NV12 or YUY2 and add the chroma up-sampling stages to the renderer chain for video cards identified by either the AMD, ATi or Intel manufacturer code. The working surfaces type, the video transport type to the mixer and the video card's ID should all be visible in the main stats screen during playback.
The chroma up-sampling method is selectable in the "Renderer Settings", "Presentation" menu.

I'm using 8-bit surface, because 10-, 16- or 16/32-bit surfaces will give me black playback (i think Intel didn't support > 8-bit surface yet) ...

for information, this problem not only occurred in your build but also on regular build.

screenshot for info:
h**p://i47.tinypic.com/286po4.png

Thank for your fast responds !!

[vivan]

Nyanya,
it works if you choose VMR-9 http://forum.doom9.org/showthread.php?p=1581726#post1581726
If you have discrete GPU you can also switch to it. Or try madVR.

[JanWillem32]

@Nyanya: The Intel support community archive features a thread on this: http://communities.intel.com/message/139632 . It seems it only happens if the driver applies filtering in the mixer stages. Can you test again with these filters disabled on the video tab of the graphics configuration panel? You might want to revive that thread if it's the same issue, maybe they will fix it in a while.

[Nyanya]

@vivan & JanWillem32,

VMR-9 (Renderless/Windowed) give same result as EVR-CP (With all filter disabled in Intel Driver setting).
I had tested all renderer in MPC-HC (64bit & 32Bit) and MPC-HC JanWilliem32 (64bit & 32Bit), only EVR Vanilla, VMR-7, and Overlay Renderer give me correct chroma up-sampling, so i think this is not driver related issue ... maybe something wrong in MPC-HC renderer presenter (CMIIW) ...

Maybe I'll stay for a while in EVR Vanilla until the problem is solved.
Thank you for your support !!

[Skwelcha]

The "Remember File position" is still not working for me. Now it doesn't untick itself, but when I start the file again it still beginns with the first frame. That's really disappointing right now, seems like I really have to go back to older builds. Imho it's on of the most important features...

[JanWillem32]

@Nyanya: The allocator-presenter can't edit any mixer settings, that's the territory of the mixer handlers for the external VMR-9 and EVR. If I could directly override the chroma up-sampling, I would have done so a long time ago. Unfortunately, it's not an option. There's no chroma up-sampling executed with Intel and AMD/ATi video adapters on surfaces other than X8R8G8B8. That was merely observed. The mixer doesn't actually expose its internal rendering stages to the renderer. What it does expose is that it can render to X8R8G8B8 (and R5G6B5 or X1R5G5B5). The 10-, 16- and 16/32-bit surfaces are technically out-of-spec. That's generally not a problem; pretty much all of the mixer stages are pixel shaded anyway. Pixel shaders can work on pretty much all surfaces. Chroma up-sampling is apparently done in a fixed function unit for Intel and AMD/ATi adapters, which can't work on alternative surface formats. For that, a set of three sequential pixel shaders are used inside the allocator-presenter to correct the issue (and do color conversion to the renderer's internal format). These can be disabled partially or in full by the two corresponding renderer options.
In the case of X8R8G8B8 being specified as a valid renderer target by the mixer (and I know for sure it is), and no chroma up-sampling is done in that case, it's a driver bug. (Note that it isn't rare; I've seen many video functions break because of drivers over time with all video adapter manufacturers.)
Do other users of the same driver and video adapter series experience this bug as well? It might be worth it to send a report.

@Skwelcha: The latest intermediate build I'm working on seems fine. I edited a lot of settings, and had to resolve conflicting code some time ago when merging from the trunk build. That's what caused the issues in this case. As usual, let's try again with the next build.

status update:
-I added the queue depth stats to the stats screen.
-I re-worked the queue system to allow the video renderer to pause for a while if the subtitle renderer needs some time to catch up. If the queue permits it, that can be up to .1875 s minus one frame time.
I made the latency time of the renderer .1875 s (or slightly under that) for every frame rate. It used to be fixed at 6 screen refreshes. During heavy processing (generally caused by the subtitle renderer), the responsiveness can drop to 3 s (not the video renderer's fault). Responsiveness during resets of the video renderer can drop a lot as well.
-I edited the stats processing code to cope with the newest changes.
For that last item: The alternative scheduler handled fine. The constant frame interpolator needs a bit of work (the code for the stats can't deal with the multiple frames in a batch system) and the other schedulers are currently out-of-order.
This part of the code is problematic; it was made to do synchronous analysis on the video renderer's timeline while it processes one frame at a time. The newer schedulers happily insert a batch of 20 frames to process, while the first frame has not even been presented yet. It's easy to query the driver for the currently displayed frame. The old code that is used to analyze timing just can't deal with this information on asynchronous processing. Whatever I try to get decent analysis on the timing, it doesn't work. I still need to do a lot of work on this part.

[fagoatse]

yo, been a while. I'm 3 versions behind but everything is working wonders so kudos for your work. Anyway, I've stumbled upon 2 shaders that were made to work with mpc-hc and they seem to be an interesting addition to the default collection.
http://forums.guru3d.com/showpost.php?p=4404811&postcount=830

[HoP]

@fagoatse

Wow.Vibrance is very good shader.i love it.thanks for that.http://forum.doom9.org/images/smilies/thanks-t.gif

[gilic]

JanWillem32 I noticed with your two latest builds that the control bar(Fullscreen) doesn't show up when I move my mouse the the bottom. Setting is auto-hide.

[HoP]

@JanWillem32
can you use MPC-BE skin for your builds.i mean your builds with MPC-BE skin will be awesome :D
thanks in advance

[menlvd]

MPC-BE + MPC-HC tester builds = ROCK!!!

[JEEB]

Let the man focus on functional changes, other people can take them and mix them up with whatever you want :)

Not to mention that he hasn't really finished anything yet (although his changes have worked for quite some people so far).

[cez4r]

@JanWillem32

I'm not a programmer, so I don't know if it helps in your work with MPC-HC and AMD/ATI graphics, but maybe it will be usefull for you.
A few days ago AMD released the first public beta of its CodeXL software debugging and profiling tool:

CodeXL is a big step forward for AMD’s developer relations efforts. With CodeXL essentially anyone can profile both the CPU and GPU code execution of their application. Additionally, CodeXL allows developers to debug both OpenCL and OpenGL code, and has the ability to do static kernel analysis, which can accurately estimate how your code is going to perform without compiling it.

There is a standalone version for Windows, another standalone version for Linux, and a third version that is a plugin for Microsoft’s Visual Studio development environment.

More on this subject: http://semiaccurate.com/2012/09/25/amd-releases-codexl-public-beta/
CodeXL download, docs and so on: http://developer.amd.com/tools/hc/CodeXL/Pages/default.aspx
Release notes: http://developer.amd.com/tools/hc/CodeXL/Assets/AMDCodeXL_1.0_Beta3Releasenotes.docx

Hope it helps :)

[adrianmak]

JanWillem32 I noticed with your two latest builds that the control bar(Fullscreen) doesn't show up when I move my mouse the the bottom. Setting is auto-hide.


Same issue of mine.

[Hypers]

Help me please i've got a problem: When i try to use [URL="http://forum.doom9.org/showthread.php?t=156191"]LAV video filters/URL with any x64 version of your mpc build(1.6.4.5855 (2f0eed8)) with Nvidia Driver 306.23WHQL(GeForce? 460) on Windows x64.
I cant activate CUVID acceleration and even CoreAVC cuda Doesnt work.
But it work on [URL="http://www.xvidvideo.ru/component/docman/doc_download/9063-media-player-classic-homecinema-x64-1634992-without-installer.html"]standart mpc-hc build/URL
it also worked with your mpc build on 301.42 Nvidia driver

[Sylt]

Hello JanWillem32,

can you update please your git repository (https://github.com/JanWillem32), so we can see the lasted renderer fixes changes.

[burfadel]

Kind of curious when the next update will be available, it's been a while (220 main branch revisions behind) :)

[Hera]

I would donate to keep this better-than-trunk project going, but I has no moneys.

[JbstormburstADV]

Hey, JanWillem32, is there any chance you could do something like integrate xy-vsfillter into MPC's internal subtitle filter? While the sub filter is great for quality, it usually does not show subs that are done in the Kareoke sub format. If you want to see what I'm talking about, I could attach a .SSA/.ASS of one of the shows that I am having issues with.

Also, what is with the delay when you use the seek bar to skip forward or backwards in a file?

[Yoshi8765]

@JanWillem32
Sorry for sounding like a noob, but how exactly do I update my current build I have from you (mpc-hc-dfr5050) to this one?
I built an intermediate version, mostly to try the changes to the queue I already mentioned. As usual, if there are problems/suggestions/other things, please tell me.
x64: http://www.mediafire.com/download.php?avn2srxnxudfoig
x86 SSE2: http://www.mediafire.com/download.php?apaviajqja6od77
x86 SSE: http://www.mediafire.com/download.php?d2u2wm71w5ewwus
Do I just overwrite the mpc-hc.exe in my program files folder? does this retain all the settings in options?

[HoP]

@ Yoshi8765

you can export your settings into a reg file (or ini file).
Options->Miscellaneous->Settings management-Export

[Yoshi8765]

Perfect, thank you.
Do I have to install my current version of mpc-hc first and then just use the mpc-hc.exe in (for example) the mpc-hc SSE2 tester temp folder? Or Do I overwrite the mpc-hc.exe from the current version?

[kasper93]

@JanWillem32: Does changes to ISR could be ported to MPC-HC or they need to be merged along with many other renderer changes? Changes that you made are very sane, I mean revised options window, and some bug are fixed also. FWIW you should try to start porting changes to mpc-hc. We can't fear forever that something will behave differently than it's now. Stagnation is just not good for anyone.