MPC-HC tester builds for internal renderer fixes

[Skibicki]

Do any issues exist with EVR? It is not working for me.

[sexus]

Video have the same quality regardless. The only things that somewhat affect it is correct dithering, good upsample algorythm (or better so say wide choice of them for pleasure of different people), correct colorimetry handling... madvr does everything in "correct" way, it delivers maximum quality but it no way improves quality in a way you seems to be thinking of. In other words you won't see more quality untill someone will invent a way to produce details from air and apply to the video.

good to hear where already getting the best of the best puts me somewhat at ease, thanks

[JanWillem32]

@janos666: I looked into the graphics adapter driver interface add-ons from AMD and Nvidia. Selecting the different output types is available trough these. However, I don't know at what level these interfaces change things. If these merely change the output type after RGB front buffer conversion, I can't use them. My currently only display only has a D-SUB connector (a CRT that will become 10 years old in two weeks), so I can't test anything of this sort of things myself.

@gilic: The data requested from the monitor miniport is supposed to be in 0.01 Hz units. If a display manufacturer uses the wrong decimal factor, I'll just have to make the renderer a bit more non-compliance friendly...
The subtitle bug was an optimization flaw I made. Thanks for reporting. (I've also taken the opportunity to clean up some of the code while browsing trough it.)

@Skibicki: Which one? There's vanilla EVR, EVR CP and EVR Sync. If in the last build none of these work, you can try VMR-9 r. next. I can supply debug builds to diagnose errors, too.

To celebrate the change of the chroma up-sampling fix, I've added all previous up-sampling types, except Lanczos for now. (My fingers hurt from all the typing I did already.)
x64: http://www.mediafire.com/?65iza913zt17b16
x86 SSE2: http://www.mediafire.com/?dio4rrgkpd7t4h5
x86 SSE: http://www.mediafire.com/?ipi1aogr079c33c

[gilic]

Everything fixed, thank you.

[Skibicki]

@Skibicki: Which one? There's vanilla EVR, EVR CP and EVR Sync. If in the last build none of these work, you can try VMR-9 r. next. I can supply debug builds to diagnose errors, too. Vanilla EVR is the one. Most others have been buggy or too inefficient for my relatively weak pc (actually my slow pc is probably to blame :) ). All video formats refuse to play, though it has been a long time since using any vmr renderer so I will try that.
The tested setup is identical to my sig except for 5403li SSE2

edit: the player generates a dmp file... going to get that and more information for you later :)

[ikarad]

Can you to see if you can solve this problem?
https://sourceforge.net/apps/trac/mpc-hc/ticket/48#comment:25

[Skibicki]

Tested in 1.6.3.5429 SSE 2
OK, this is the dmp file. I will try other renderers now.
http://www.mediafire.com/download.php?81h3n01ftdu08ty

EVR CP and VMR-9 r worked well. EVR CP stutters a bit less.

EVR Sync results
http://i.imgur.com/xyK5C.jpg

[sexus]

the audio switcher in mpchc doesnt work correctly with your latest release , when i load a video unless i go to audio switcher and then click ok then all of the sudden my audio is normal volume again before that you can hardly hear anything , can this be fixed? since in earlier and regular trunk builds this problem doesnt exist

p.s: and somebody for the love of god bring back BE mod gui i cant believe nobody cares about the default windows 95 mpchc layout where in 2012 here -.-

[JanWillem32]

@ikarad: I'm aware of this issue, and I definitely would like to try to fix it with a new texture manager for the bitmapped subtitle types. It will take some time though, as VSFilter still isn't extracted from the main code. This prevents me from changing fundamental things the right way in the subtitle renderer.

@Skibicki: That DMP file indicates a crash inside evr.dll. My best guess is that the EVR started a DXVA decoding session, and then xyVSFilter tried to lock a surface (which is illegal for the surfaces used for DXVA). Note that the vanilla EVR is fully external. EVR CP, EVR Sync and VMR-9 r. have internal renderer parts which we maintain.

@sexus: The code for the audio parts are unaltered compared to the trunk build. Are there any specific settings, audio codecs, and such involved so that I can try to replicate this issue?

For this release I mostly worked on minor optimizations and a dirty patch to correct colors for subtitles. The new behavior of the ISR mimics the horribly distorted color processing used by VSFilter. Because of the nature of this change, the color correction is only applied with 10-, 16-, or 32-bit surfaces enabled with the internal renderers. (Pixel shading on blending just doesn't fit in well when using the 8-bit surfaces performance path.)

I can still only produce 'Lite' builds for now. These doesn't have codecs and splitters internally, so users will have to install some external ones when using these builds. (Just a hint for the new users. I'll try to fix the codec section and go back to regular builds later on.)
x64: http://www.mediafire.com/?cxl6gl9b87jbflc
x86 SSE2: http://www.mediafire.com/?laygac14hex7eyy
x86 SSE: http://www.mediafire.com/?so0baslk9ot622a

[G_M_C]

JanWillem, i have a feeling that working on light builds have advantages too. You can concentrate on de renderer-side of things.

For instance, you could work towards linking/building with xy-VSFilterin stead of the ISR, cause that would suite your needs better. At the time the main branch devs catch up, and are ready to switch to xy-VSFilter too, your branch / fork and theirs can merge.

As it stands now, you keep beeing very dependant on the slow progress on the main branch. Progress on your (better / more advanced renderer) is hindered by this situation.

So working on light builds, where users have to use their own splitter and decoders (i.e. LAV Video / audio), is a good option. Forthermore, its not even very strange; The most used 'codec pack' is shipped with a light build, and the LAV decoders.

In the most extreme case you could work towards LAV filters intirely, dropping internal decoders completely, if this is needed to 'get things done'. Progress towards a newer renderer is more important than keeping compatibillity at all cost (as it stands now). Cause keeping compaitbillity at all costs, inevetably leeds to very bloated an difficult to maintain software.

[sexus]

@ikarad: I'm aware of this issue, and I definitely would like to try to fix it with a new texture manager for the bitmapped subtitle types. It will take some time though, as VSFilter still isn't extracted from the main code. This prevents me from changing fundamental things the right way in the subtitle renderer.

@Skibicki: That DMP file indicates a crash inside evr.dll. My best guess is that the EVR started a DXVA decoding session, and then xyVSFilter tried to lock a surface (which is illegal for the surfaces used for DXVA). Note that the vanilla EVR is fully external. EVR CP, EVR Sync and VMR-9 r. have internal renderer parts which we maintain.

@sexus: The code for the audio parts are unaltered compared to the trunk build. Are there any specific settings, audio codecs, and such involved so that I can try to replicate this issue?

For this release I mostly worked on minor optimizations and a dirty patch to correct colors for subtitles. The new behavior of the ISR mimics the horribly distorted color processing used by VSFilter. Because of the nature of this change, the color correction is only applied with 10-, 16-, or 32-bit surfaces enabled with the internal renderers. (Pixel shading on blending just doesn't fit in well when using the 8-bit surfaces performance path.)

I can still only produce 'Lite' builds for now. These doesn't have codecs and splitters internally, so users will have to install some external ones when using these builds. (Just a hint for the new users. I'll try to fix the codec section and go back to regular builds later on.)
x64: http://www.mediafire.com/?cxl6gl9b87jbflc
x86 SSE2: http://www.mediafire.com/?laygac14hex7eyy
x86 SSE: http://www.mediafire.com/?so0baslk9ot622a

try this build and then yours set the settings as follows and youll see what im talking about

http://henry.fushizen.eu/builds/MPC-HC/MPC-HC.1.6.3.5454.x86.exe

http://i1033.photobucket.com/albums/a413/breakdown23/settings2.jpg

http://i1033.photobucket.com/albums/a413/breakdown23/settings1.jpg


your build = need to go to audio switcher and click ok then works , regular build = no such issue, wonder why and dont matter if external filters or not

[shimaflarex]

Can you make the "D3D fullscreen" be automatically toggled on fullscreen mode?

[Skibicki]

Thank you for helping. :thanks: @Skibicki: That DMP file indicates a crash inside evr.dll. My best guess is that the EVR started a DXVA decoding session, and then xyVSFilter tried to lock a surface That may not be true. The same error occured after disabling DXVA in LAV Filters, disabling the ISR, and removing xy-vsfilter from the graph. It also never starts a video whether it is 8 or 10-bit. Here is the DMP from taking those steps in 1.6.3.5454 - http://www.mediafire.com/download.php?4lwff8azxi0oz1i
http://filecloud.io/2xyn0cvi
Note that the vanilla EVR is fully external. Would that make it a Windows issue? EVR has worked fine on vanilla MPC - HC.

[burfadel]

With the Full Screen D3D mode on another screen, if I currently click back on the other screen the video screen goes blank. If paused and I click back on the other screen, sound plays but no picture, and if it's playing when I click off it and back on it, it may show the picture again if it's not too long between screen switching. I believe this may be due to using LAVF (latest builds), I'll see how it goes with the internal filters once that is rectified.

[RGold]

Just wondering - madVR already is handling the scaling and up sampling pretty well. Why there is a need to improve/develop EVR like JanWillem project?

[Keiyakusha]

I have question too. Why EVR-CP again, why not the whole thing from scratch? Something like JW Video Renderer ^__^

[Hera]

Just wondering - madVR already is handling the scaling and up sampling pretty well. Why there is a need to improve/develop EVR like JanWillem project?

Because MadVR is a joke compared to EVR:CP in performance and hardware compatibility.

[JanWillem32]

@G_M_C: My wish is to not deviate more from the trunk than the set of internal renderers. I don't mind tinkering with a few additional things, as long as those are easy to patch into the trunk build. I'd like to avoid breaking any functionality in the tester builds relative to the trunk, as it would cause problems when integrating items.

@sexus: It should be fixed now, with a bonus.
I've added an option to the channel mixer to add an empty channel. It's now easier to map 5.0 audio to a 5.1 output. Note that the channel names are still invalid. The channel mixer doesn't keep relations to named output channels. It only outputs to a channel count. I'll contact the rest of the development team to ask what they would like to change about the channel mixer.

@shimaflarex: The toggle for fullscreen is used for multiple renderers, and isn't a signalled event to the renderers. The D3D fullscreen option only works for the internal renderers. Also, switching between the two fullscreen modes is legal. I don't know if I can change much about these two settings, they are not really related.

@Skibicki: I fixed it again. Thanks for reporting.

@burfadel: I should get a secondary monitor to be able to debug things like this. Since which build does this issue occur?

@Stephen R. Savage: EVR will usually reject YV12 and I420/IYUV inputs. An input of X8R8G8B8 usually means that the renderer is either getting images from the Windows still image filter (for loading .BMP files), or that the mixer rejected a more compatible input from other sources. Usually, the mixer will work fine with NV12 for 4:2:0 Y'CbCr input, and YUY2 for 4:2:2 Y'CbCr input. The mixing is done externally. The display driver implements the methods for that. In known cases of failed chroma up-sampling, I've added an initial shader pass to correct the issue (only in the quality rendering path). Are you sure NV12 doesn't work for most videos?

About the internal renderers item... I'm not only working on EVR CP. I've changed things for VMR-9 r., the DirectX 9 handlers for RealMedia and QuickTime, (I should also work on) EVR Sync, I've edited the handlers for external filters and some more parts. I just like to write code and publish it.
The standalone renderer is the (very) unfinished DirectX 11.1 one. I'll maybe pick it up once the current items are integrated, and I can focus on new things. Note that the DirectX 9 renderers will still be required. If I get around to writing the DirectX 11.1 one, it won't have the compatibility and performance rendering paths. DirectX 10 and onwards have a minimum hardware requirement (and some of the renderer stuff has requirements on top of that).

[JanWillem32]

I've also done some optimizations in general on top of the things I already mentioned. I've mostly focused on the frame dropping section of the alternative scheduler and general things in the final pass/constant frame interpolator sections.

x64: http://www.mediafire.com/?a5pi5s5s74bqews
x86 SSE2: http://www.mediafire.com/?yt5vld9b0qbgcfz
x86 SSE: http://www.mediafire.com/?9dvlgyuur3f29u0
Source code: http://www.mediafire.com/?g2fh7bbuzuauv41

[sexus]

yep that fixed it thanks, btw any plans on integrating sse4.2 etc?

ranpha doesnt suggest x64 builds due to codec compatibility issues and there being 0% difference in performance , check out her checklist in her video playback setup guide

http://imouto.my/watching-h264-videos-using-compute-unified-device-architecture-cuda/

p.s: damn was hoping that mentioned bonus would be BE mod guification goodness apparently im the only one that cant take the windows 95 look anymore -.-

btw am looking forward to that dx11.1 renderer , wonder if its gona be like madvr? just a ton better or something ? since a member here mentioned madvr already being the pinnacle of video renderers and evr-cp ? what is this the 90s xD , was dumped long ago in favor of madvr in this house ;)

[ryrynz]

yep that fixed it thanks, btw any plans on integrating sse4.2 etc?

I wouldn't be worrying about that right now there's much more important things to be done with the code.


p.s: damn was hoping that mentioned bonus would be BE mod guification goodness apparently im the only one that cant take the windows 95 look anymore -.-


I'm as keen as that as you are, but you're just gonna have to wait until bobdynlan has integrated it. There hasn't been any update regarding that as of yet.

[Hera]

Latest versions were fairly stable recently.
Interface glitched out twice in a non-reproducible fashion in the previous build on W8. Not very common at all.

Now this is with latest 3xx W8 NV drivers (stable release) and 16f,
First of all, I can manage 16f I noticed. Not sure if you, W8, or NV. Good thing, I fathom for sure.

Second, I get washed out video - like limited luma range washed out with D3D fullscreen - monitor switched to 16-235.
And for soft subbed video, 16f behaves with D3D fullscreen enabled.
Now colors get washed out just due to using D3D FS - not 16f related.

I noticed that I can get rich colors back by disconnecting and reconnecting monitor.

Not sure if I should persue further as W8 is not even out yet.


EDIT,

Another bad behavior,
1. Open video
2. Stop video
3. Switch to D3D FS

Expected: Nothing happens. Video is stopped.
Actual Results: Player starts exclusive mode.

EDIT,
Whatever that ugly thing is on the previous page. I am here to say that it looks like ****. If you want MPC:HC to look modern, copy WMP.

[burfadel]

@burfadel: I should get a secondary monitor to be able to debug things like this. Since which build does this issue occur?


Only 5454li from what I can tell. 5470li also does it. As I was saying, not sure if it is to do with the player or the codecs. I'm using ffdshow of the decoding, and lavf for the splitter (latest builds).

A new problem with 5470li, the Normalise function under options --> audio switcher does NOT work!

Looking at the output levels, when enabled they whole line is green, as if its blasted a billion times boost and the system is automatically cutting it out. When disabled, sound plays fine. This is a new issue only with 5470li.

[JanWillem32]

@sexus & ryrynz: The image/thumbnail saving code in the renderer actually has 4 paths: aligned SSE4.1, unaligned SSE4.1, aligned SSE, and unaligned SSE. Depending on the source image width, aligned or unaligned is used, and depending on support, the SSE4.1 or SSE paths are chosen.
The SSE build type is for legacy support. Because the player has to be able to run on a Pentium 3 with an IGP on Windows XP SP3, it's still provided. The SSE2 type allows a few compiler optimizations, and some of my (rather simple) context switches to use SSE2 where available. (I'm actually just waiting for the minimum support level bump to allow SSE2 or hopefully even SSE3 by default so I can add the usual SSE stuff without having to add legacy support code.)
I actually like the x64 builds. It's mostly because the debug version of the x64 build can actually render subtitles. The x86 versions rarely deliver a rendered picture, making them a bit useless if you try to debug the subtitle renderers. I don't know how much difference there is for release builds, though. The video renderer is certainly not CPU bound. Even the renderer in the trunk build doesn't have that much CPU usage (just a lot of cases of interruptions in the rendering process).

I'll probably won't be able to best madVR for a while. It has had more TLC than the renderers I've been working on. Madshi is most certainly more experienced with the DirectShow systems than I am.
I don't mind providing the two external renderers with updates on their renderer sockets. It's the least I can do.
For work on the various renderer parts and some other stuff, I wouldn't mind having more developers and other staff around.

By the way, what could be more important than low-level optimizations for the resource-hungry parts? The performance optimizations I made were certainly noticed. In terms of fixing problems I'd say I'm doing pretty well. Initialization times are a bit harder to improve, it seems. The graph builder takes a long time to get around to start, and in the mean time it re-initializes many filters many times (which is a disaster for large, complex classes, such as a video renderer).

@Hera: The mode for 'stopped' isn't the same as 'closed'. The stopped mode still has the renderer running. (It re-paints every .5 second.)
In the renderer there isn't a switch for ordering limited ranges conversion from the driver on the front- and backbuffers. I'd have to add some driver interfaces to the renderer for such a thing, and the option would be worse than the current solution: letting the shadercore do it before converting to limited ranges (options available under color management). If disconnecting and reconnecting the monitor corrects the issue, it's the driver's fault.

@burfadel: The normalization item is probably easy to fix. For the other item, wouldn't know what change would have caused that issue. It might take a while to resolve it. edit: I fixed the normalization (the code is still very crappy, but that's not because of me).

[ryrynz]

By the way, what could be more important than low-level optimizations for the resource-hungry parts?

Since you've already optimized the resource hungry parts how much extra performance is there to be gained? and how noticeable is it going to be given that in order to support this instruction set you require a fairly quick processor anyway?

Getting things merged into the trunk seems more important I think :) It'd be nice to see some solid commits, there's only so much cosmetic stuff that can be done with the code :D

[burfadel]

I thought the normalisation error would be something pretty simple :)

As far as the other issue is concerned, it could be to do with MPC-HC itself, or it could be to do with the use of an external filter that wasn't in use before, so I guess I won't know until they become available again. The only external filter that I can think of that is being used now that wasn't before is LAVF splitter.

Also in D3D fullscreen mode (not sure whether it's the same for other modes), I notice that the progress bar doesn't actually progress on the play screen, it just stays wherever the last pause/play point was.

[sexus]

JanWillem32 maybe you could ask madshi for some assistance if possible , id say he would be the right guy for the job in terms of help on renderers and hes pretty open to new suggestions , so just to make sure for us people with 980x i7 cpus we should go with the sse2 build i asume then? all these builds are confusing the heck out of me

[sexus]

Latest versions were fairly stable recently.
Interface glitched out twice in a non-reproducible fashion in the previous build on W8. Not very common at all.

Now this is with latest 3xx W8 NV drivers (stable release) and 16f,
First of all, I can manage 16f I noticed. Not sure if you, W8, or NV. Good thing, I fathom for sure.

Second, I get washed out video - like limited luma range washed out with D3D fullscreen - monitor switched to 16-235.
And for soft subbed video, 16f behaves with D3D fullscreen enabled.
Now colors get washed out just due to using D3D FS - not 16f related.

I noticed that I can get rich colors back by disconnecting and reconnecting monitor.

Not sure if I should persue further as W8 is not even out yet.


EDIT,

Another bad behavior,
1. Open video
2. Stop video
3. Switch to D3D FS

Expected: Nothing happens. Video is stopped.
Actual Results: Player starts exclusive mode.

EDIT,
Whatever that ugly thing is on the previous page. I am here to say that it looks like ****. If you want MPC:HC to look modern, copy WMP.

and what would that ugly thing exactly be? :sly: fyi wmp does NOT look modern they stopped working on its gui back in 2000 the way it looks and yes we know that mpchc needs an visual overhaul since a very long time , which BE mod quite successfully managed to do without too much work , of course even that could be improved but its a start , atm were all waiting for bobdynlan to update the trunk build with BE so we can atleast start moving from the windows 95 esque look to something more sophisticated , as ryrynz already said bobdynlan is taking his sweet time ;)

[Hera]

and what would that ugly thing exactly be? :sly: fyi wmp does NOT look modern they stopped working on its gui back in 2000 the way it looks and yes we know that mpchc needs an visual overhaul since a very long time , which BE mod quite successfully managed to do without too much work , of course even that could be improved but its a start , atm were all waiting for bobdynlan to update the trunk build with BE so we can atleast start moving from the windows 95 esque look to something more sophisticated , as ryrynz already said bobdynlan is taking his sweet time ;)

You seem to be stuck on Windows 2000 or something because your statement makes no sense and little grammatical sense as well. Either that or you are talking about something else than Windows Media Player.

[JanWillem32]

@ryrynz: There's plenty to optimize left. I really wouldn't say every processor capable of SSE2 (2001) and SSE3 (2004) is fast at all. The SSE4.1 path in the image collecting function of the renderer is meant to speed up memory transactions that are terribly slow on even recent hardware.
As for merging stuff, I've submitted patches for changing only the most the simple items as of yet. It just takes a lot of time before those are approved.

@Stephen R. Savage: The quality video rendering path is activated with the 10-, 16- and 32-bit surfaces options. (A lot of other renderer options become available after activating one of these.) Color space conversion is handled in the decoders or in a seperate converter. The EVR itself doesn't facilitate much in terms of color space conversion. Note that VMR-9 does have a set of software converters.
When entering paused mode, the frames that have already been submitted are displayed as usual, and then the player pauses. Entering paused mode doesn't abort the rendering queue. If required, frame stepping and seek to time stamp/frame number is available.

@sexus: You can use either the SSE2 or x64 builds, just not the AVX builds. The SSE builds are only for legacy support. Descriptions of the builds are in the OP.

[ryrynz]

@ryrynz: There's plenty to optimize left. I really wouldn't say every processor capable of SSE2 (2001) and SSE3 (2004) is fast at all.


I was referring to processors that have SSE 4.2 (i series) and supporting that as sexus's comment was about supporting that instruction set primarily.


The SSE4.1 path in the image collecting function of the renderer is meant to speed up memory transactions that are terribly slow on even recent hardware.


Interesting, thanks.


As for merging stuff, I've submitted patches for changing only the most the simple items as of yet. It just takes a lot of time before those are approved.


How long does the process usually take? Considering we're not talking about inserting code into a final build here and your changes are simple items taking such time seems overly extreme.
What happened to nightlies being nightlies? Seems little point in committing changes in small increments if they're undergoing such testing.
Isn't that what this topic is for anyway? That and the whole nightly build process.. Essentially we have three testing phases for alpha/beta code.. This topic, Developer testing, MPC-HC topic.
MPC could really stand to be a little more on the bleeding edge letting the users do more testing rather than the developers. As it stands every minor change in builds is basically stable.

[Keiyakusha]

MPC could really stand to be a little more on the bleeding edge letting the users do more testing rather than the developers. As it stands every minor change in builds is basically stable.

I don't know how long you follow mpc-hc development, but by checking svn changes, what gets commited, by who, what things rejected etc., after some time it becomes clear that dev's only commit changes they want to see. And they ushually don't want to see anything that is not a bugfix or something like moving checkbox 2px left or right. That's why they don't need nightly builds in the way its normally seen and nightly builds in reality more stable than release ones. So until you convince them that they will like feature in question - you won't see it in trunk. And its not easy to do so - that's why it takes a lot of time. There is also no main developer who can decide what is good, what is bad. The one who should (and tried) to do so got his access to svn removed for some reason (as far as i understand).

[Hera]

How about making this a fork of MPC-HC? With a new name and boasting about optimization and user experience improvements?

"MPC-HC tester builds for internal renderer fixes" simply doesn't have that ring to it...

[Keiyakusha]

How about making this a fork of MPC-HC? With a new name and boasting about optimization and user experience improvements?
It already exists. Just available only for limited beta-testers circle at this moment. Its not related to JanWillem's work however

JanWillem32
Do you think you can alter standalone vsfilter's code in a way like adding some kind of new connection logic/interface? I was reading that you want to see internal subtitle renderer split from vsfilter, but maybe it is good idea to drop internal one completely and only use standalone with interface (http://madshi.net/SubRenderIntf.h) developed by madshi? I'm not the one who should explain how it works but from what I understand by using this interface vsfilter sends data to renderer directly via some custom connection, not overlays on video stream. Even if madshi will come back soon, EVR still needs to be developed to support this so maybe it worth a look. I think it can't be developed on vsfilter or renderer side only, you need both at once to see results.

[ryrynz]

Today over at the CCCP forum (http://www.cccp-project.net/forums/index.php?topic=5976.msg41370#msg41370http://)

xy-VSFilter 3.0.0.111 Beta

Change: Initial commits to prepare for implementation of xy-VSFilter's new subtitle interface.

[Keiyakusha]

Today over at the CCCP forum (http://www.cccp-project.net/forums/index.php?topic=5976.msg41370#msg41370http://)

Oh very nice! Can't really read all places so I'm a bit behind :D
Maybe the part where I asked about vsfilter is not needed, only support on evr side will be needed. And I really think that among other things it solves the issue with splitting internal and external renderers.

[nevcairiel]

How about making this a fork of MPC-HC? With a new name and boasting about optimization and user experience improvements?

To do that it would need to be more stable, as it is now every other build something new breaks - which is also the reason everyone is reluctant merging stuff to MPC-HC, stuff is still changing too much.

[sexus]

You seem to be stuck on Windows 2000 or something because your statement makes no sense and little grammatical sense as well. Either that or you are talking about something else than Windows Media Player.

no what i meant was wmp isnt all as fancy as you make it seem to be and its gui design hasnt changed much from its past versions , thou it does look better than mpchc ..atm, which were all waiting for it to change soon :)

p.s: a w7 x64 user btw ;) , thanks for clearing that build question for me janwillem32

[JanWillem32]

I fixed a few things yesterday for the things burfadel mentioned. The D3D FS mode's window handling code was altered a few revisions ago, so I changed it back this time. (I hope it helps, else I'll try again.)
The problems with the messages in the OSD not hiding, the mouse cursor not hiding and the seekbar in D3D FS not updating is caused by malfunctioning timers (it's random per session). The issue for the messages in the OSD was solved by using a different type of timer, maybe I should do the same for the other parts as well. (I'm just not to keen on reordering code in mainfrm.cpp for this item.)
I'm out of time to put more text here, so maybe later.

x64: http://www.mediafire.com/?d852d5gbz4gn64q
SSE2: http://www.mediafire.com/?jlyqojv0nh31b2r
SSE: http://www.mediafire.com/?6o836ouoizqkka6

[burfadel]

Normalisation works :)
Progress bar still doesn't progress.
The screen still goes black when you click on the main screen.

Does 'feel' a little better though! and now if you pause it (click on the play screen) click on the main screen so the play screen goes black, you can click back on the play screen and the picture will re-appear. It did not do this before, so it is an improvement! I should point out that the main screen flicks blank very quickly when the switch occurs.

[burfadel]

New info:
On the second screen, the mouse cursor does not disappear and the progress bar does not move. HOWEVER, if I click on the main screen (where the play screen goes black) and back on the play screen (so the picture appears again, but is paused of course), once played again the progress bar does progress and the mouse cursor does disappear after a couple of seconds like it is meant to!

[HoP]

missing indicator for DXVA in the status bar ("playing [DXVA]") even when DXVA is used
video renderer: EVR CP

[hayan]

I'm actually just waiting for the minimum support level bump to allow SSE2 or hopefully even SSE3 by default so I can add the usual SSE stuff without having to add legacy support code
All Dual-Core processor have SSE3, hopefully SSE3 by default.

[sexus]

this BE mod sure is taking its sweet time -.-

[ryrynz]

It's listed as a branch of MPC here https://github.com/mpc-hc/mpc-hc/branches And honestly I think it's a case of when it's done it's done. He could be working on it and not submitting any commits.

At this rate It may not be released until the end of the year.. It's probably not worth mentioning it again here. If we havent seen anything come end of August I'll ask for an update.

[sexus]

thanks ryrynz i think that would be the best route

[JanWillem32]

Sorry for not updating more often. The re-exam period will start soon, and I'd like to focus on studying for that. I made a Git repository for development: https://github.com/JanWillem32 . I'll be slowly updating it with very minor changes for now. (Inserting the complete new renderer code would be far too much to digest for the rest of the development team at this point.) The development of the renderer code will be a bit slow for a while, but I did change the fundamental format of the quality video rendering path. As I successfully worked out the math for complete Y'CbCr/xvYCC<->R'G'B'<->XYZ conversions and set intervals of [.25, .75] in the 16-bit unsigned integer surface format, I'm testing if I can standardize that for the quality video path. The results seem fine for now, but I will have to adapt the color management section accordingly.

[Hera]

Seems to work on XP / Atom N270 / Intel GPU
Just for some reason it defaulted to perlin smoothstep which did not run smoothly at all.

[JanWillem32]

As far as I know, I set the default to Bilinear. When you reset your settings, does it default to something else?

[fagoatse]

As far as I know, I set the default to Bilinear. When you reset your settings, does it default to something else?

I can confirm that bilinear is indeed the default setting.