MPC-HC tester builds for internal renderer fixes

[burfadel]

@ Hera -
When I enable 'D3D Fullscreen Mode' under Renderer Setting=>Presentation,
I don't get any menus,bars,controls,etc... so it's not for me,
because 25-50% of time I use MPC-HC in windowed mode, not in fullscreen

@ dukey -
I agree we should remove it,
but maybe it's left for testing proposes... :p

I've just noticed that myself. The progress bar doesn't appear like it is meant to. It seems to only show when the video is paused.

[JanWillem32]

- Nearest neighbor (PS 2.0) resizer don't work,
changing to it from other resizer causes MPC-HC to crash;For the Nearest Neighbor resizer I tried to insert a method to use the resizer in the EVR mixer. CruNcher mentioned that he was interested in using that one, because of the implementation on the Intel GPU he uses. Unfortunately, my implementation of this functionality isn't exactly optimal. The resizer can't handle down-scaling at all, only 8-bit surfaces work well for it and the re-initialization function I wrote for when resizing the window isn't working properly either.
It's very hard to implement functions that use different mixer functionality in the renderer. Changing the rendering paths inside of the renderer is done for various reasons, the main two are the split in the paths made for the four presenting modes (depending on scheduler), and the split in the path at the end of the rendering chain for the regular frame finalization and the constant frame interpolator. All these split paths converge again within the same function (they're all just if-else branches in CDX9AllocatorPresenter::Paint()). This resizer function doesn't fit in that way. I'll have to look up how to operate the EVR to get this function to work properly, or else remove it.

The regular Nearest Neighbor and Bilinear resizers are handled through the bog standard StretchRect() DirectX call. These are easy to handle (once the clipping and resizing rectangles are calculated). StrectchRect() is also used for a direct copy to a back buffer for when no resizing, pixel shaders and final pass filters are used. The regular Nearest Neighbor filter might not look the nicest, but it's a valid resizing filter, so we implement it.- Enable Post-Resize Pixel Shaders don't work,
when it's enabled while playing file, video stops updating,
when it's enabled before playing file, video didn't start;Post-Resize Pixel Shaders needed a fix for the 8-bit mode indeed. Thanks for noticing.- pausing is lagged,
when it's used, it pauses but next it 'plays/adds' some frames ahead and then video finally stops;Lag in the video is caused by the queue. In the last debug run I did, I saw the queue depth go up to 14 screen refreshes. When a video is paused, the queue isn't aborted. The frames that are inside it are presented as usual, the renderer just doesn't add new frames to the queue. Similar behavior is observed on seeking, resetting and closing.- going to fullscreen gives some artifacts in between this operationIt takes time to reset the device's back buffers and vertex caches when resizing the window. Artifacts such as these are acceptable, just as long as the player continues to render properly after the reset.When I enable 'D3D Fullscreen Mode' under Renderer Setting=>Presentation,
I don't get any menus,bars,controls,etc... so it's not for me,
because 25-50% of time I use MPC-HC in windowed mode, not in fullscreenThe D3D exclusive mode can be switched on the fly. The default key combination for it is Ctrl+F, but you can of course assign any key on the keyboard/mouse/remote control for it. Note that the window used by the fullscreen mode doesn't have to be on top of the player. For those with two displays or more, the "Options", "Fullscreen" tab allows setting the fullscreen monitor.I've just noticed that myself. The progress bar doesn't appear like it is meant to. It seems to only show when the video is paused.I've had that same problem a while ago. I used a reset of all settings and set my regular settings up again manually, after that it worked properly again. Note that the OSD has to be enabled to get the seek bar in D3D exclusive mode.

[stranger_in_the_night]

Thanks for fixing the previously posted bugs (GPU, A. Schdl).

I've done some more troubleshooting in an effort to isolate the pause problem, here's some notes:

It doesn't occur at all if Aero (uxsms service) is off.

If Aero is on, it occurs sometimes on first play. Seeking within chaptered files generally won't trigger another pause.

If Aero is on, and D3FS mode is entered, then exited, seeking with chapters will cause pauses every time. For bluray playlists, sometimes resuming play will cause it to restart from the beginning. In this case the resumed playback seems not to seek to the correct frame either (some sort of queue problem?).
A Schdl. on or off seems to make no difference.


Some other things:

If you come out of D3FS mode into a window (rather than full screen) the cursor sometimes disappears in the playback part of the window. Right-clicking seems to bring the cursor back.

With regard to multiple monitors, if you start playing a file on a particular display, drag it to another display, and activate D3FS mode it tries and fails to activate on the wrong display. Is there any way for it to detect the correct display to change modes onto?

Seeking with A. Schdl in these builds is improved from the previous builds, although there are still problems; a fair chunk of them seeming to stem from calculations re the frame rate (e.g. when seeking and on initial playback there seems to be spikes in the frame rate which throw off the frame lock; VFR files (e.g. mixed 24p/30p) are another source). Is there any way to filter out the 'junk' data (beyond the averaging which is already done)?

DTV-DVD decoded video still seems to be glitchy, although subjectively less than before. Screenshot of observed behaviour at http://i.imgur.com/XSYwI.jpg.

As an aside, I'm wondering whether its possible to display any further statistics to identify judder (Aero replaces tearing with judder). It's possible to 'see' it in video terms with 30p pans for example, but that doesn't show up as any particular statistic in the current graphs.

I'm also wondering what the benefit is of having the different methods of scheduler is, given that under Aero neither scheduler will tear (i.e. does or should the alternative scheduler perform better in this sense?).

Finally, re the previous post: I would concur with the sentiment if D3FS is the preferred behaviour (it would be similar to the way the MadVR renderer behaves if this is how it is setup).

EDIT: One more thing: As per my last post, sometimes I'm seeing the framerate not being detected properly (particularly with DVD stuff) - screenshot: http://i.imgur.com/8xMPK.jpg.

[JanWillem32]

@Stephen R. Savage: The functionality isn't easy to implement. The D3D fullscreen setting is only used for a few renderers and is a signaled event to the renderer. The other fullscreen option is available for even the system renderers and isn't signaled to the renderer. The two options are unrelated.

@stranger_in_the_night: I don't mind exposing judder. I've added the graph for it (yellow), the graph crossing it (blue) is the recorded, detected (locked) frame rate at that point.
I'll answer the other things when I have more time.

I've made the alternative scheduler a bit more rigid in creating its cycles. If this method doesn't work correctly for anybody, I'll revert it to the previous version.

[RGold]

I have a strange problem. I can't open any second video after first one finished in any build after 4588. The player trying to launch and terminate itself. 4588 has no problem.

[kasper93]

@JanWillem32:
What do you thing about new tab in options window for renderer settings? There are so many settings and it's inconvenient to set them through context menu.
Also statistic(ctrl+j) font looks ugly on big screens, in my opinion.

[burfadel]

For the last couple of versions, it skips some files in the playlist. To be more precise, it tries to load them, fails, and then goes to the next file. Sometimes it can occur on multiple files. If you go back and try to load the files skipped it usually plays, but sometimes you have to change the position of the files in the playlist for it to actually load. I have tried resetting the settings with no luck.

Has anyone else come across this?

[JanWillem32]

If you come out of D3FS mode into a window (rather than full screen) the cursor sometimes disappears in the playback part of the window. Right-clicking seems to bring the cursor back.That one used to be even worse. When the full screen exclusive mode switched back with the cursor still hidden, it stayed hidden until the window focus was lost. I'll see if I can refine it a bit more.With regard to multiple monitors, if you start playing a file on a particular display, drag it to another display, and activate D3FS mode it tries and fails to activate on the wrong display. Is there any way for it to detect the correct display to change modes onto?It's too bad my secondary display is currently out of order. I can only look at the code right now. When making a full screen window, it looks by default at the nearest monitor the main player window is at. If a full screen monitor is selected in the options menu, it should be selected properly during switching. I wish I could actually test and debug this.Seeking with A. Schdl in these builds is improved from the previous builds, although there are still problems; a fair chunk of them seeming to stem from calculations re the frame rate (e.g. when seeking and on initial playback there seems to be spikes in the frame rate which throw off the frame lock; VFR files (e.g. mixed 24p/30p) are another source). Is there any way to filter out the 'junk' data (beyond the averaging which is already done)?I'll try to fine-tune it some more. It's just annoying that video streams may change the frame rate on the fly without any signal to the renderer other than just other spacing of the time stamps passed with every frame.DTV-DVD decoded video still seems to be glitchy, although subjectively less than before.I'm not surprised. The magenta graph shows the raw time stamps from the video. These are the worst I've ever seen. Even when performing 3:2 pull-down the time stamps look better than that. Do other decoders fare any better with the sample you used there?I'm also wondering what the benefit is of having the different methods of scheduler is, given that under Aero neither scheduler will tear (i.e. does or should the alternative scheduler perform better in this sense?).To make that more correct: neither the Aero desktop nor D3D full screen exclusive mode will tear. That's why I disable the VSync functions written by my predecessor in these modes.
The default frame scheduler is not very accurate nor efficient. It doesn't buffer and schedule multiple frames ahead of time. It merely renders one frame at a time and puts the renderer thread to sleep until it's time to present the next frame.
The alternative scheduler and constant frame interpolator fill the queue with multiple frames. If the queue is full, the renderer is waiting on a subtitle or the system is busy, the renderer thread can afford being paused up to dozens of milliseconds in the middle of rendering as long as there are frames still in the queue. On top of that, these schedulers specify the amount of screen refreshes per frame to display.Finally, re the previous post: I would concur with the sentiment if D3FS is the preferred behavior (it would be similar to the way the MadVR renderer behaves if this is how it is setup).I don't mind standardizing the D3D fs mode for more uses, but I'll probably have to write a better control bar than the current one first. As that bar is inherited from the OSD renderer, I'll probably have to replace that one, too.EDIT: One more thing: As per my last post, sometimes I'm seeing the frame rate not being detected properly (particularly with DVD stuff)...I've noticed it. The DVD menu areas don't set any time stamps. I've changed the stats processing sections to ignore these frames for gathering stats (for the most part already in the build I put here earlier).

@RGold and burfadel: The issues might be related. I can't seem to replicate it. I'll do some more testing and regular editing. If I can't come up with a direct solution, let's take a look at the log created by a debug build.

@kasper93: I'd love to add a menu tab for the renderer settings. More room for descriptions of items makes them a lot more accessible. Also setting up a regular set of options is annoying, as you have to navigate through the same menus multiple times. So far, I haven't altered the menus and settings structure fundamentally. I'll have to ask the rest of the development team, before I'll change something like this.
The statistics font is relatively cheap and easy to render. Of course it's not the best quality. I can change the font, but I'm not so sure I should change the alpha transparency around the borders of the characters.

[burfadel]

I'm quite happy to help with debugging if you like.

I must admit I am using reclock, ffdshow as the decoder (I use it for postprocessing, temporal smooth (only) set to 1) and the resize filter to output in HD), and ac3filter. I also use some of the shader filters (greyscale noise, sharpen etc). In saying that earlier versions work without issue. I also tried doing away with some of that stuff with no luck.

[JanWillem32]

I've tried to debug a few things, but I couldn't directly get clues to solving things.
One thing I did add was an item for the subtitle renderer (adapted from code by demi_alucard). It now has to option to render less than full texture resolution. The options are full, 3/4 and 1/2 size. Once I'm convinced I did a proper job on the vertex math, I'll make an intermediate set of builds.
Debug description: http://forum.doom9.org/showthread.php?p=1553934#post1553934

[HoP]

~52mb??
why??
=====
do you have any plan to add your 'pixel shaders' to your builds?

[JanWillem32]

Debug builds contain a full library of the components the executable is built from. Additionally, many debug tests are added to catch bugs early on and report statuses. The compiler doesn't optimize the code in debug builds. That also makes them big and slow.
I can add some pixel shaders, once there's consensus about the integration form, how pixel shaders are loaded and how to deal with the .INI settings issue. (If you store settings as .INI, only a few pixel shaders will fit, else the data gets cut off at the end.)

[stranger_in_the_night]

Thanks for the feedback above, I appreciate it.


Regarding the pause issue: I've posted up a 'working' debugview log at http://pastebin.com/raw.php?i=qMSz3D9q versus a 'non-working' debugview at http://pastebin.com/raw.php?i=vai7wYQX.

There doesn't seem to be a whole lot to work with there (in fact, they look basically identical to me), so if there's any other bits and pieces that need to be installed to get a more complete picture let me know.


Is it possible to make available the relevant .pdb files with future builds? I had some issues in the previous build where MPC-HC would sometimes crash and produce a minidump when opening from or dragging to the secondary screen, and as far as I know I can't get any relevant debugging information from that minidump without the .pdb file for your build.

WRT the DVD problems I was having, it seems to have stemmed from the DVD splitter I was using (the open source one, as opposed to the one built into windows) - the built-in one seems to work much better so apologies if I have mislaid the blame on that one.

It does bring me to a broader point however that although the alternative scheduler may be a nicer solution, the fact that it relies so heavily on those timestamps should be a cause for concern. The previous method may be flawed, but it has none of the problems that the newer method does (i.e. incorrect or no timestamps don't affect playback in the same way it does for the other scheduler). If we can get the newer scheduler up to the same level of reliability compared to the older one then I guess that point would be moot though; in my opinion though it's too soon to be trying to get it into trunk if it's less reliable than the older method.

EDIT:

I tried the nearest neighbour resizer as well (the one that is supposed to use EVR resizing), and get Debug Assertion Failed for evrallocationpresenter.cpp at line 710 four times (hitting ignore), then Debug Assertion Failed for !m_bFlushing, line 3113 of amfilter.cpp; if that means anything significant in trying to track down whatever's wrong with that?

It seems to me that the behaviour for the alternative scheduler and D3FS modes is almost identical now (in that they generate almost identical stat graphs); does that sound about right? I went back and had a look at some of the documentation and posts from the GothSync project, and it seems that D3FS mode was arguably only necessary for XP, as Aero on Vista/7 dealt with tearing without it (this was also the part of the argument the developer made for not continuing development on that code, as he thought it was redundant because of Aero dealing with the tearing problem).

I've also seen it said in the past that D3FS mode was the most 'desirable' in that it provided the most reliable rendering experience compared to windowed modes. I never used it until recently because of a) the need to have it active before playback, and b) can't switch back to windowed mode without stopping playback - given that you've been working on fixing these problems it seems more attractive to me to use now if it's beneficial for playback (I can live without the control buttons/seek bar if in full screen mode).

In terms of integrating the Gothsync code back into EVR-custom, it seem to me that the only one worth doing is the 'sync video to display' (this would need reclock-style adjustments though? - arguably you're already doing this via the frame interpolator anyway), as 'Present at nearest vsync' seems to replicate the default scheduler behaviour, and 'Synchronize display refresh rate to video frame rate' is pointless to implement given that it required the use of powerstrip, which as far as I know doesn't support any recent gpu hardware.

One final thing; sometimes I see the paint time 'glitch' up, or down. It doesn't seem to matter whether I'm using software or hardware based decoders, so I don't think its a decoding speed problem. Is this normal, and if not is there anything that can be done to work around it? (particularly for 60p content, where one of these paint glitches seems to correspond directly with judder)

[burfadel]

I've tried to debug a few things, but I couldn't directly get clues to solving things.
One thing I did add was an item for the subtitle renderer (adapted from code by demi_alucard). It now has to option to render less than full texture resolution. The options are full, 3/4 and 1/2 size. Once I'm convinced I did a proper job on the vertex math, I'll make an intermediate set of builds.
Debug description: http://forum.doom9.org/showthread.php?p=1553934#post1553934

x86 SSE2: http://www.mediafire.com/download.php?q00l4psdnzjpg4z
x64: http://www.mediafire.com/download.php?p7xq5qul5mqw21b

I get a debug assertion failed!
dx9allocatorpresenter.cpp
Line: 788

When I click retry, I get:
Application Timestamp: 4fbd3484
Fault Module Name: mpc-hc.exe
Fault Module Version: 1.6.2.4860
Fault Module Timestamp: 4fbd3484
Exception Code: 80000003
Exception Offset: 01584ea6
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 3081
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[tetsuo55]

Did it create a mini-dump?

If so could you upload that somewhere and post the link here?

[burfadel]

So after the issue of the debug build not working (even after a system restart), I tried a vanilla build of MPC-HC, r4867, and the renderer settings were missing (as expected I guess). After reselecting EVR-CP, and the options such as 10-bit output, force10-bit RGB input, Full Floating-point etc, I watched a show and it worked fine going on to the next file. I then retried the debug build... and it worked! I reset the settings, went back to the debug build and set everything up again and it worked (I mean reset the settings through the view-->options-->miscellaneous page.

I had already done this with the previous builds, it did not help the skipping files issue. So, not sure what's going on!

The debug build still skips files (tries to open them, but just goes on to the next one). How do I work the debug version to show this, in terms of logging etc?

[JanWillem32]

@burfadel: That assertion is not a very critical issue. (But I changed it anyway.) Let's try again.

Regarding the pause issue: I've posted up a 'working' debugview log at http://pastebin.com/raw.php?i=qMSz3D9q versus a 'non-working' debugview at http://pastebin.com/raw.php?i=vai7wYQX.

There doesn't seem to be a whole lot to work with there (in fact, they look basically identical to me), so if there's any other bits and pieces that need to be installed to get a more complete picture let me know.They are very much not identical. The device creation points are different.
"Direct3D9: :BackBufferCount not specified, considered default 1" -> Those are created by the external EVR.
The block before it without the warning is the one used by the renderer. It seems that the external EVR is initializing multiple times for some reason. I'll enable the EVR debug logging option (hope it still works).Is it possible to make available the relevant .pdb files with future builds?Most certainly.WRT the DVD problems I was having, it seems to have stemmed from the DVD splitter I was using (the open source one, as opposed to the one built into windows) - the built-in one seems to work much better so apologies if I have mislaid the blame on that one.

It does bring me to a broader point however that although the alternative scheduler may be a nicer solution, the fact that it relies so heavily on those timestamps should be a cause for concern. The previous method may be flawed, but it has none of the problems that the newer method does (i.e. incorrect or no timestamps don't affect playback in the same way it does for the other scheduler). If we can get the newer scheduler up to the same level of reliability compared to the older one then I guess that point would be moot though; in my opinion though it's too soon to be trying to get it into trunk if it's less reliable than the older method.Actually, the default scheduler has the same issues. It just has judder&jitter issues on a per-frame basis while there is no frame rate lock. The alternative scheduler has to chew for six frames on a bad time stamp.I tried the nearest neighbour resizer as well (the one that is supposed to use EVR resizing), and get Debug Assertion Failed for evrallocationpresenter.cpp at line 710 four times (hitting ignore), then Debug Assertion Failed for !m_bFlushing, line 3113 of amfilter.cpp; if that means anything significant in trying to track down whatever's wrong with that?I already know it's broken. I just don't have the time right now to plough trough the huge database for EVR functionality right now to fix it.It seems to me that the behaviour for the alternative scheduler and D3FS modes is almost identical now (in that they generate almost identical stat graphs); does that sound about right? I went back and had a look at some of the documentation and posts from the GothSync project, and it seems that D3FS mode was arguably only necessary for XP, as Aero on Vista/7 dealt with tearing without it (this was also the part of the argument the developer made for not continuing development on that code, as he thought it was redundant because of Aero dealing with the tearing problem).The alternative scheduler can work both in Aero desktop and D3D FS mode. (Also applies for the constant frame interpolator.) The Aero desktop and D3D FS modes can both do a proper VSync, but can't schedule frames on their own.I've also seen it said in the past that D3FS mode was the most 'desirable' in that it provided the most reliable rendering experience compared to windowed modes. I never used it until recently because of a) the need to have it active before playback, and b) can't switch back to windowed mode without stopping playback - given that you've been working on fixing these problems it seems more attractive to me to use now if it's beneficial for playback (I can live without the control buttons/seek bar if in full screen mode).When the OSD is enabled, there's a seek bar. The D3D FS exclusive mode is mostly efficient in usage. It allows a program to present to the adapter's back- and frontbuffers. In desktop mode, an extra copy is made to paste the rendered image onto the desktop. The desktop will present the composed image to the adapter's back- and frontbuffers. That operation takes processing power and time.In terms of integrating the Gothsync code back into EVR-custom, it seem to me that the only one worth doing is the 'sync video to display' (this would need reclock-style adjustments though? - arguably you're already doing this via the frame interpolator anyway), as 'Present at nearest vsync' seems to replicate the default scheduler behaviour, and 'Synchronize display refresh rate to video frame rate' is pointless to implement given that it required the use of powerstrip, which as far as I know doesn't support any recent gpu hardware.I unfortunately don't know much about the schedulers written by my predecessors. I merely try to port them, because the development team requested that. I'm actually not very interested in schedulers that can't buffer frames ahead.One final thing; sometimes I see the paint time 'glitch' up, or down. It doesn't seem to matter whether I'm using software or hardware based decoders, so I don't think its a decoding speed problem. Is this normal, and if not is there anything that can be done to work around it? (particularly for 60p content, where one of these paint glitches seems to correspond directly with judder)It depends entirely on the cycle generator. - As you can see, the normal cycle is a 'W'. Once in a while, it generates 'WV' to correct the imperfect 50:almost 80 Hz ratio of the video to my monitor. (I tried some settings that normally would generate a more uneven green graph, but it didn't work as planned.) If the green graph hits the +1/2 or -1/2 frame limit in the graph, the cycle will be adjusted to prevent desynchronization. If a full frame time needs to be adjusted, two screen refreshes are added or removed from a present. When four frame times late, another frame is dropped completely.

[stranger_in_the_night]

Working: http://pastebin.com/raw.php?i=rQ4iz9QP
Not working: http://pastebin.com/raw.php?i=yhEXLJce

[burfadel]

dfr4880i debug build still skips some things in the list (tries to load but then goes on to the next file). There is no crash etc information coming up. How do you use the debug version to determine the issue?

Also, with the first file I played the seekbar and all functions (such as volume, and clicking to pause) didn't work, but the second file it did (after it skipped to the third file I double-clicked back on the second file and played it). Other than that it works fine!...

[Virtual_ManPL]

@ JanWillem32 - Thank you for fixes and detailed info about each report ;)

For artifacts it's just annoying to see them, but fast fix will be always using D3DFS in full screen mode, like ex. binding 2 features (enabling D3DFS and going to full screen).

I can also confirm that going to next file is broken in most cases. File don't want to load, but MPC-HC tries many times. This also happen when you use playlist.

[burfadel]

I can also confirm that going to next file is broken in most cases. File don't want to load, but MPC-HC tries many times. This also happen when you use playlist.

That is a better way of explaining the issue!

[TheElix]

Hey, Jan! Wasn't able to find your pixel shaders thread, so I'm putting this info here. I hope you'll find it interesting. http://www.freepatentsonline.com/7995835.html
As a result of this http://darbeevision.com/gallery

[JanWillem32]

That's quite a generic software patent. It's also rather old in terms of rendering technology. For example, it still features black- and white clipping steps, instead of the more common high dynamic range imaging that simply allows values past the nominal [0, 1] intervals.
The working color space isn't even noted in the patent at all. That's rather odd. An image in memory is handled very differently for if the color space and encoding is for example bt.709 Y'CbCr, R'G'B' or a more professional type like XYZ.
The methods in the patent mostly describe a simple, large-area sharpening convolution kernel, with fine-tuning by hand on mostly a per-picture basis, with the help of Adobe Photoshop.
I already made a few pixel shaders that feature large area convolution kernels, though not with such a large area as in the patent (a 15-pixel radius solid circle).
http://en.wikipedia.org/wiki/Acutance
There's nothing inherently wrong about such a sharpening method. Digital imaging systems just produce rather soft images naturally. You just have to be careful when editing a picture to never apply sharpening before any other filtering passes. The overshoot areas (can clearly be seen in the Wikipedia page) are non-uniformly transformed relative to the solid internal parts. That makes proper filtering with normal filters that expect natural gradients on a specific area impossible. Proper sequencing of imaging filters requires quite a bit of skill. It's very common that the intermediate image layers used in editing an image are plain ugly and often don't look any better after a single filter pass. Entire editing and texture sequences are commonly stored while editing. Early stages in these sequences are edited often and tested if the changes work well for the picture in its finalized form.

Status update; I put some effort into getting some parts into the trunk build - with very meager results. I've been away from home for more than week because of my sisters lovely wedding, so I couldn't develop much. The recent changes to the code in the trunk didn't make my work easy, as a lot of code conflicted. The most recent change to the alternative scheduler failed, as its sequence generator can't produce complex judder patterns (so I reverted it to the previous type).
I'll mostly concentrate my work on getting the pausing bug resolved. After that, I'll look at the constant frame interpolator, as I have a new base method ready for its filter sequences.

[JanWillem32]

For this release, I included the pdb files, for if someone would like to use them.
I solved the pausing and file skipping bug. (Although I think the external EVR still re-initializes various components far too often during start up, but that's the same as with the trunk build.)
I've taken a look at the AviSynth issues, but I couldn't get it to work at all, even with the trunk build. Other developers noted that it broke in changeset 2374: http://sourceforge.net/apps/trac/mpc-hc/changeset/2374 . There's no good workaround for that. On top of that, the x64 version never worked at all. If anyone has any clues how to get AviSynth to work, please tell me.
The links to the builds, source code and pdb files are in the OP.

[Hera]

Cool, will test.

EDIT: Stats seem broken - video plays smoothly, stats refresh every second showing stuff which feels inaccurate.
Yeah - stats do not refresh or anything - fully useless.

[stranger_in_the_night]

Thanks for fixing the EVR bug.



Stats seem broken

Confirmed here. They won't work if A. Schdl is off. They come back to life if the interpolator is on though.

[burfadel]

Thanks for fixing the EVR bug, I can begin using it again! (the skipping of files became a little too annoying)!

I'm on the Windows 8 Preview release 8400. I have noticed that when loading and changing files MPC-HC works a LOT quicker, probably due to an update to the EVR. Disable Desktop Composition doesn't seem to do anything, although it may be fractionally quicker etc with it disabled (haven't really tested it on or on). In any case, it seems the issues with desktop items and running MPC-HC in D3D mode on a different monitor concurrently (hence the requirement for the desktop composition option) are gone in Windows 8. I'm guessing its due to WDDM 1.2, and changes to the DWM etc?

[Hera]

When NVIDIA will man up and release good drivers for ION for W8, I will test more on W8 - I don't feel like hard rebooting my hardware a lot.

[Mercury_22]

@ JanWillem Can you please help patching EVRMixer (http://sourceforge.net/apps/trac/mpc-hc/ticket/1295)to be able to use DSLibBluRay Blu-ray disc navigator filter (http://forum.doom9.org/showthread.php?t=164314) to enable Blu-Ray menus in MPC-HC ?

[dukey]

probably would be better off just getting it working with straight EVR to start with

[HoP]

@ JanWillem
can you compile it without internal filters?

@Stephen R. Savage
i reported "AviSynth issues".
problem with new build 5050
info:
ffdshow_rev4459_20120530_xhmikosr_icl12_x64
avsplitter_x64_1.2.2.8
avisynth:

SetMemoryMax(512)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)
MT("LimitedSharpenFaster(ss_x=1.0,ss_y=1.0,strength=80,soft=10)",4)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last


ps: i havent problem with "mpc-hc_lite_x64_r4947"[henry build (http://henry.fushizen.eu/builds/MPC-HC)]

[RGold]

I see tearing with the 5050 build at the first minute of the video. No tearing with 4504i and other latest intermediate builds. I use LAV for everything - do I gain any thing in 5050?

[fagoatse]

I see tearing with the 5050 build at the first minute of the video. No tearing with 4504i and other latest intermediate builds. I use LAV for everything - do I gain any thing in 5050?

Hmm... I've noticed a performance increase of the ISR since 4739. Frame drops occuring in scenes with karaoke subs or some fancy effects have been alleviated a bit once again, at least for me. Didn't experience any new issues and most older ones are gone(for instance the pause bug seems to have been resolved). The transition to fullscreen in non-d3d exclusive mode still looks a bit off though.
Other than that, an outstanding job, Jan. Thanks.

[JanWillem32]

@burfadel: The new drivers may of course fix a few things. The performance still varies a bit: http://benchmark3d.com/amd-catalyst-8-93-7-windows-8-benchmark/2 (I haven't seen any benchmarks with the Intel or Nvidia drivers yet).

@Mercury_22: dukey is probably right. EVR CP is quite complex and its mixer is a bit restricted. I don't mind adding interfaces later on.

@HoP: I can compile without internal filters. I'm just not sure I should deviate more from the trunk builds than I currently do, though.
I still can't get AviSynth to work. Even with the fully external renderers, using the trunk build, it crashes or doesn't load.

@fagoatse: That's a bit odd. The only change lately was on the video renderer side, the option to render at 3/4 or 1/2 screen resolution. The ISR itself hasn't been changed in a while.

I've edited the stats processing code, this solves the problem with the stats screen and Alternative VSync.
I've edited the window handling code, to prevent flicker during resets and such.

x64: http://www.mediafire.com/download.php?0hkcamysqm1iad1
x86 SSE2: http://www.mediafire.com/download.php?jtikcqjgcb7x20k
x86 SSE: http://www.mediafire.com/download.php?5uqdw6khhnehnb7

[dukey]

@Mercury_22: dukey is probably right. EVR CP is quite complex and its mixer is a bit restricted. I don't mind adding interfaces later on.



na it's not hard. I could probably add it myself. It just makes sense though to implement functionality so you can actually use the filter first. Using evr-cp support can come later.

[Hera]

With the new build I have just experienced some really weird stuff - like V-Sync, where top sometimes shows something before ... I don't know - will test more.

EDIT: I think getting stuck behavior is back - I mean video just gets stuck which is disastrous for D3DFS mode. Could be LAV's fault, but it seemed to work better the build before the last.

[CruNcher]

Thanks for fixing the EVR bug, I can begin using it again! (the skipping of files became a little too annoying)!

I'm on the Windows 8 Preview release 8400. I have noticed that when loading and changing files MPC-HC works a LOT quicker, probably due to an update to the EVR. Disable Desktop Composition doesn't seem to do anything, although it may be fractionally quicker etc with it disabled (haven't really tested it on or on). In any case, it seems the issues with desktop items and running MPC-HC in D3D mode on a different monitor concurrently (hence the requirement for the desktop composition option) are gone in Windows 8. I'm guessing its due to WDDM 1.2, and changes to the DWM etc?

This is because the whole latency everywhere in the GFX Pipeline is lower thx to WDDM 1.2 and D2D got a efficiency boost compared to Win 7 also :)

And both things together lower latency and better performance are what makes Win 8 very interesting even for XP enthusiasts and Win 7 lover ;) as it is the first step to merge both Worlds Low Latency and High Performance into 1 improving the GPU pipeline was important though well see hopefully someone doing some real tests of how efficient latency evolved now from XP -> Vista WDDM 1.0 /7 WDDM 1.1 -> 8 WDDM 1.2 the future for upto WDDM 2.1 was allready setup @ WINHEC 2006 before NT 6 was released many things found their way into 1.2 already http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/pri103_wh06.ppt. So after 6 years we finally have the most important features, though you need a pretty new GPU to get full advantage of the entire WDDM 1.2 feature set :)

People look to much only into Performance http://msdn.microsoft.com/en-us/library/windows/desktop/hh404540%28v=vs.85%29.aspx ;)

[Keiyakusha]

Disable Desktop Composition doesn't seem to do anything, although it may be fractionally quicker etc with it disabled (haven't really tested it on or on)

I haven't looked into win8 and unlikely ever will, but i read somewhere that aero was removed from it. So of course Disable Desktop Composition not works anymore, nothing to disable...
Under win7 you can do the same for any executable in compatibility properties, however on many systems it actually helps to get smooth playback (while this option is not checked).

[JanWillem32]

I've fixed the external EVR-derived resizer. It was a lot of work to finally fix the functions' problems, but it seems to be stable now. It's still listed as nearest neighbor. I'd like to collect some performance data on it. Could some people compare it to bilinear? I've already noticed that it only performs well in 8-bit surfaces mode for my setup.
Various other small bugfixes and optimizations were done. On the trunk build's side, some nasty bugs were fixed as well.

[clsid]

I haven't looked into win8 and unlikely ever will, but i read somewhere that aero was removed from it. So of course Disable Desktop Composition not works anymore, nothing to disable...
Under win7 you can do the same for any executable in compatibility properties, however on many systems it actually helps to get smooth playback (while this option is not checked).The Aero Glass theme is going to be removed, not all Aero features.
Desktop Composition is still present in Win8. In fact, it is now always enabled. So the option in MPC should be hidden.
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848042%28v=vs.85%29.aspx

[Hera]

Well that build is completely borked - no sound. Seeking gets sound for a fraction of a second then it is gone again...
Oh and video doesn't work right either, stops, resumes, goes fast, goes slow...

Same with D3D:FS

EDIT:
The last two builds you posted, essentially destroyed everything :P

5101i
regression: video and audio stops from time to time, CTRL-C does NOT work when this happens
regression: resizing sometimes forgets to resize subtitles
5141i:
regression: audio cuts out almost immediately and video is irrational

[CruNcher]

The Aero Glass theme is going to be removed, not all Aero features.
Desktop Composition is still present in Win8. In fact, it is now always enabled. So the option in MPC should be hidden.
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848042%28v=vs.85%29.aspx

Yep which shows they are very sure they got to XP levels or even bellow again which makes workaround DWMs high latency unnecessary :)

Unfortunately many applications aren't there yet to fully utilize the efficiency if i look @ Firefox for example it's D2D is still very inefficient also MPC-HC with it's very old GDI base is not really efficient, Mobile users with Win RT will realize that first.

[stranger_in_the_night]

Well that build is completely borked - no sound. Seeking gets sound for a fraction of a second then it is gone again...

Can confirm that again here - seems broken regardless of scheduler. Video renders a few frames on first playback, then stops, then sometimes renders one frame every few seconds. It does sortof work if you turn on the interpolator, but the video is behind in the frame rate, and the sync offset produces junk output (very high, then very low figures).

EDIT: Screenshot of the stat screen with interpolator on: http://i.imgur.com/WRkOe.jpg.

[JanWillem32]

double Target = dPerfC - static_cast<double>(nsCurrentTime) * m_dModeratedTimeSpeed + dClockTime;
to:
double Target = (dPerfC - static_cast<double>(nsCurrentTime)) * m_dModeratedTimeSpeed + dClockTime;I'm such a bad programmer every now and then...

x64: http://www.mediafire.com/download.php?y7ayzdlqiyz74cf
x86 SSE2: http://www.mediafire.com/download.php?ay7k1tlmmxageb8
x86 SSE: http://www.mediafire.com/download.php?46421vpwr1b3ge8

[stranger_in_the_night]

Thanks for fixing that bug.

Testing the EVR resizer isn't going too well so far. The player starts in a downscaled box (tiny compared to video resolution). Resizing the window generally causes a crash (minidump:http://www.mediafire.com/download.php?s1jzvprgwy7k8u7 , windbg output:http://pastebin.com/raw.php?i=KxPHAiiS).

If I switch between another resizer and the EVR resizer, it seems to work okay apart from some juddering which occurs continuously after the resizer change (even if you switch back) which doesn't show up on the stats. Memory use is slightly up on the normal resizers after switching while GPU usage seems to be about the same.

[sexus]

could you possibly make a BE Mod version of your mpchc build? i just love the BE mod mpchc editions , but your build is the best , so combining both the looks of BE and your rock solid build im sure there would be alot that would appreciate the effort janwillem ;)

[JanWillem32]

@stranger_in_the_night: Too bad, I'll try some more. It's just that this stuff is awfully driver-specific. The bad performance/judder problem happens to me as well, if I don't select 8-bit surfaces.

@sexus: We are open to proper contributions to the GUI code. However, it's not in my portfolio to create developmental alpha versions for these kinds of changes. If changes are made in this regard for the trunk build, I'll gladly merge it from the trunk, as usual.

[CruNcher]

@Jan

using your build and Intel Driver 2761 testing some multitasking WDDM 1.1 works flawless no drops no stutter fluid playback :)

http://forum.doom9.org/showpost.php?p=1578615&postcount=1443


PS: Added Nvidia result

[ryrynz]

could you possibly make a BE Mod version of your mpchc build? i just love the BE mod mpchc editions , but your build is the best , so combining both the looks of BE and your rock solid build im sure there would be alot that would appreciate the effort janwillem ;)

It's currently being added to the trunk by Bobdynlan, give it a few weeks or so and it'll be there for everyone.

[Hera]

Got black screen doing this, (only did this once, don't know why or if steps are correct)
1. Play something in exclusive mode
2. Let laptop hibernate during playback (battery low)
3. Connect power and HDMI to HDTV, resume from hibernate

Got it to playback stuck by, (Small Chance and CTRL-C will not work)
1. Dual Audio MP4 / Exclusive Mode / LAV Video (no splitter used)
2. Switch audio at start

Otherwise seems to work well :)