MPC-HC tester builds for internal renderer fixes [Archive] - Page 2

JanWillem32

18th May 2012, 20:27

- 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

19th May 2012, 16:33

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

20th May 2012, 15:33

@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

21st May 2012, 04:49

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

21st May 2012, 11:44

@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

21st May 2012, 15:59

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

23rd May 2012, 00:06

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

23rd May 2012, 15:14

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

23rd May 2012, 20:48

HoP

23rd May 2012, 21:25

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

JanWillem32

23rd May 2012, 22:23

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

24th May 2012, 03:11

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

24th May 2012, 13:36

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

24th May 2012, 14:15

Did it create a mini-dump?

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

burfadel

24th May 2012, 15:14

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

25th May 2012, 22:56

@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

26th May 2012, 05:44

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

burfadel

26th May 2012, 15:21

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

31st May 2012, 14:53

@ 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

31st May 2012, 15:40

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

4th June 2012, 21:30

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

5th June 2012, 21:13

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

8th June 2012, 22:04

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

8th June 2012, 23:18

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

9th June 2012, 00:13

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

9th June 2012, 01:36

Hera

9th June 2012, 01:38

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

9th June 2012, 16:28

@ 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

9th June 2012, 19:25

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

HoP

9th June 2012, 22:58

@ 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

10th June 2012, 06:14

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

10th June 2012, 14:28

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

12th June 2012, 17:59

@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

12th June 2012, 19:57

@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

12th June 2012, 22:16

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

15th June 2012, 19:31

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

15th June 2012, 19:39

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

15th June 2012, 19:55

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

15th June 2012, 20:00

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

15th June 2012, 20:29

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

15th June 2012, 20:33

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

15th June 2012, 20:45

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

15th June 2012, 22:52

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

15th June 2012, 23:33

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

16th June 2012, 17:15

JanWillem32

16th June 2012, 19:47

@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

16th June 2012, 20:37

@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

17th June 2012, 00:39

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

18th June 2012, 03:36

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 :)

RGold

18th June 2012, 07:02

Get sound loop when I do the following:

1. Player in Windowed mode
2. Drag&drop a video file and automatically start playback.
3. Switch to full screen - no exclusive.

Notes:
1. Using auto change full screen monitor mode. I.E, refresh will be 23.981Hz for 24 Hz video material.
2. Using latest build - didn't see this issue with 4504i
3. Using EVR Custom Pres. With LAV for everything.

burfadel

18th June 2012, 12:37

Latest build for me works on Windows 7 and 8. Went back to 7 as I thought there was a memory leak with Windows 8, turns out it was because of Avast 7.0.1442 beta lol. It does seem to change between files quicker now even on Windows 7 (not as fast as on 8 though) but still a nice change over previous versions.

CruNcher

19th June 2012, 17:46

I found it funny what recently happened on the Surface Keynote Sinofsky Surface Windows 8 RT freezed *g* i guess that one will go into the list of funny crash, freeze, bug moments in a Microsoft official Demonstration but they are prepared very well these days if such things happen ;)

Already started, hes though the best that could happen to the Windows Team including Russinovich he's inteligent,creative and sporty as well ;)

http://www.youtube.com/watch?v=4z-KXYUP5r8

sexus

20th June 2012, 16:20

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

sounds most excellent ;)

Virtual_ManPL

23rd June 2012, 10:36

Some more bugs:

1. I see no visual difference with Catmull-Rom spline4 and Catmull-Rom spline6. Probably the code is duplicated in both methods. (see test)

2. Nearest Neighbor code is probably swapped with Perlin Smootherstep, because Nearest Neighbor look better than Perlin Smootherstep, which it shouldn't and also Perlin Smootherstep is pixelated which should be Nearest Neighbor. (see test)

3. Lanczos is bugged, I see vertical lines on low quality video (SAMPLE (http://depositfiles.com/files/d9kpmu8qu)) and on zoom I see some kind of 'blocked pixel mask'
Bugged Lanczos (http://i.imgur.com/COzpr.png)
Not Bugged Bicubic (http://i.imgur.com/QIgba.png)

4. Automatic hiding menus don't work in some cases. The best way to reproduce is to do a circle mouse movements near Win start bar hooking also MPC-HC bottom bars and next go to fullscreen. The MPC-HC menus like Seekbar, Control and Status don't want to hide automatically if this steps are performed.

Now some resizer method test (not the same frame in all SS, but I was trying ;p) TESTED FILE (http://depositfiles.com/files/7xhbl0y9j)
Bicubic -0.6 (http://i.imgur.com/dfhUm.jpg)
Bicubic -0.8 (http://i.imgur.com/9ZnCU.jpg)
Bicubic -1 (http://i.imgur.com/yEzBX.jpg)
Bilinear (http://i.imgur.com/8BjnZ.jpg)
B-spline4 (http://i.imgur.com/SxekF.jpg)
B-spline6 (http://i.imgur.com/3USAB.jpg)
Catmull-Rom spline4 (http://i.imgur.com/2sPSM.jpg)
Catmull-Rom spline6 (http://i.imgur.com/Js4TI.jpg)
Lanczos2 (http://i.imgur.com/vRrsS.jpg)
Lanczos3 (http://i.imgur.com/2at7P.jpg)
Lanczos4 (http://i.imgur.com/mS04e.jpg)
Mitchell-Netravali spline4 (http://i.imgur.com/bsaoh.jpg)
Mitchell-Netravali spline6 (http://i.imgur.com/X2F1U.jpg)
Nearest Neighbor (http://i.imgur.com/mmxRE.jpg)
Perlin Smootherstep (http://i.imgur.com/2GdQL.jpg)

In my opinion Bicubic -1.0 still look the best, look on letters on the bottom-left side of the screenshot.
When video is very low quality we can use B-splite4, it greatly masks artifacts. Dunno why B-spline6 look worse, maybe too much sharp effect.
Also I was thinking that Lanczos should be the best, but looking on letters, it isn't. Odd because on normal images, it works the best in all graphic programs.

burfadel

23rd June 2012, 15:30

I've noticed the OSD stuff doesn't disappear either, particularly the file name at the top of the screen (note this is Direct3D on another monitor). You can hide that by pausing and starting it again, upon which point 'play' may or not be stuck up there!

JanWillem32

23rd June 2012, 19:38

@Hera: I've been able to replicate the problem. It's marked in the source code of the trunk (exactly at the point where the exception is made), and has been there since there were only VMR-7 and VMR-9 r.. It's an old problem caused by the quality of service (stats) interface in a DirectShow part of the player. It's not a real renderer issue, and I don't know if I can solve the problem anytime soon.

@RGold: I haven't been able to reproduce this issue yet. Does it occur when you disable the auto change full screen monitor mode feature?

@Virtual_ManPL: It's been a while since I made some screenshots of the resizers in action. Note that to test resizers, you need large magnification factors on lossless images.

The Lanczos filters have a truncation fault, which is native to the windowed sinc filters: http://forum.doom9.org/showthread.php?p=1540386#post1540386 .
Depending on the position of the source pixel(s) relative to the destination pixels(s), such filters will give brightness artifacts. In the case of equal resizing amounts for horizontal and vertical directions, the artifacts will be lines drawing squares on the picture.
Perlin Smootherstep has a square affinity. It simply works like that.
Nearest Neighbor for EVR CP is a placeholder for the EVR-inherited resizer. Its device is created by the display driver.

When the renderer is placed in fullscreen windowed mode, it skips the check for changes in the window bottom parameter. This is to prevent resizing because the bottom bar pushes the renderer window away. The correct solution would be to not use this trick and just let the renderer reset itself because the window resized (how it previously was), but I doubt people would like that. I know the fullscreen windowed mode is not bug-free (it never was), so if anyone wants to re-design the player menu to correct it, they're welcome to try.

@burfadel: I noticed it as well. It mostly happens when you switch from one file to the next in D3D FS mode. I'll take a look at why the OSD doesn't properly clear its status.

Development status: creating the code to allow the alternative scheduler on Vista in Aero desktop mode. (It already works for D3D FS, and on 7 in Aero desktop mode.)

resizers comparison pictures (44.4 MB): http://www.mediafire.com/download.php?5uhh2nha5iaczer

burfadel

24th June 2012, 01:41

Interesting enough, now that I wrote there is an issue with the OSD stuff not disappearing... its disappearing like it should! maybe it depends on the source of the file?

Admittedly I changed from a HD6950 to a HD7870 (Gigabyte OC model) Friday night, but I doubt whether that has anything to do with it since I don't use DXVA.

Seems its back again! Don't know why it worked flawlessly for a while...

RGold

25th June 2012, 01:37

@RGold: I haven't been able to reproduce this issue yet. Does it occur when you disable the auto change full screen monitor mode feature?

It does not occur when disabling the auto change full screen monitor mode feature.

Virtual_ManPL

26th June 2012, 20:58

@ JanWillem32 -
Thanks for resizers comparison test.

I'm curious why other resizers are so poor in my test.
No other method will smooth this 'stairs' on letters so good like the Bicubic -1.

I have an idea. How about making D3DFS default mode for going into fullscreen by binding Enter key etc.
It will prevent us for seeing this annoying artifacts in non D3DFS mode.

Hera

5th July 2012, 04:48

Performs even better on W8 with 3xx drivers.

burfadel

5th July 2012, 07:30

Just wondering whether there will be a new build any time soon, since its already over 220 builds behind the main branch (r5365 main vs r5142 JW at time of writing)...

Thanks :)

ryrynz

5th July 2012, 09:14

I've wondered that myself..

JanWillem32

6th July 2012, 01:18

It indeed has been a while.
I re-organized the EVR mixer handler for EVR CP. When running the debug DirectX runtime this is visible because of the lack of additional devices next to the main one.
I re-wrote many parts of the OSD system (the same as usual when I start working on something; it was in a pretty bad state).
I edited the subtitle renderer stats section.

Because the internal filters can't be compiled at this time because of a linker error, only 'lite' builds this time. I won't make a habit of this.
x64: http://www.mediafire.com/download.php?zlwfk87b3dm4bik
x86 SSE2: http://www.mediafire.com/download.php?mqcr33mc5u5xdma
x86 SSE: http://www.mediafire.com/download.php?551s34nyy4irwz1

HoP

6th July 2012, 16:06

a newbie question:
what is the work of this option?
http://imgair.net/i/clipboard01-1341568727.jpg

JanWillem32

6th July 2012, 16:44

On some systems the actual refresh rate is a bit different than the one reported by the DirectX 9 runtime. That one only reports whole integers, so I programmed it to adapt to the typical NTSC types already: double drr = static_cast<double>(rr);// the standard converter only does a proper job with signed values
m_dDetectedRefreshRate = m_dRefreshRate = m_CurrentRendererSettings.m_RenderSettings.dRefreshRateAdjust * ((rr == 119 || rr == 89 || rr == 71 || rr == 59 || rr == 47 || rr == 29 || rr == 23) ? (drr + 1.0) / 1.001/* NTSC adapted, don't include 95*/ : drr); // exact amounts
The user can refine the refresh rate adjustment factor even further. A good tool for this is PowerStrip. In my case, the refresh rate is reported as 79.939 Hz (at a setting of 80 Hz), so I use an adaptation factor of 0.9992375. Note that the alternative scheduler and constant frame interpolator can also make small adjustments when anomalies are detected.
I might be able to integrate display information functions to process this automatically in the future.

HoP

6th July 2012, 18:16

@JanWillem32
many thanks for info
another question
when i choose EVR CP,video is normal:

http://imgair.net/i/clipboard11-1341576353.jpg

but when i choose EVR Sync,video get zoomed.why??

http://imgair.net/i/clipboard12-1341576480.jpg

+
when i press ENTER for full screen,video get freeze for 1sec and then resize(EVR CP).

gilic

6th July 2012, 19:01

Don't use EVR-sync it is outdated and unmaintained. The dev left some time ago.

You could test different resizers under options>output, maybe your system isn't powerful enough for the selected resizer and causes the freeze. I think the resizers are sorted from simple at the beginning to complex at the end of the list.

JanWillem32

6th July 2012, 19:55

I haven't had the time yet to fully update EVR Sync yet. As you can see, I integrated the new resizer section, but the EVR Sync rending path isn't fully compatible with them.
The video renderer needs a reset like with any other resizing of the video window, and that simply takes a while. For switching the fullscreen borderless mode, the re-arranging of the bottom toolbar takes additional time (albeit much less than the reset). The reset duration of purely the resizer sections can be tested easily: just switch the resizer type on the fly. It hardly distorts playback.

HoP

6th July 2012, 20:38

@gilic & JanWillem32
many many thanks for info
goodluck

burfadel

6th July 2012, 21:07

Unfortunately the OSD stuff still doesn't disappear in full screen D3D mode for me with r5373.

JanWillem32

6th July 2012, 21:17

The OSD timer is still very unreliable, I'm trying to use a different one, but it isn't easy to find such a thing.

shadewither

7th July 2012, 02:07

@Virtual_ManPL: It's been a while since I made some screenshots of the resizers in action. Note that to test resizers, you need large magnification factors on lossless images.

The Lanczos filters have a truncation fault, which is native to the windowed sinc filters: http://forum.doom9.org/showthread.php?p=1540386#post1540386 .
Depending on the position of the source pixel(s) relative to the destination pixels(s), such filters will give brightness artifacts. In the case of equal resizing amounts for horizontal and vertical directions, the artifacts will be lines drawing squares on the picture.
Perlin Smootherstep has a square affinity. It simply works like that.
Nearest Neighbor for EVR CP is a placeholder for the EVR-inherited resizer. Its device is created by the display driver.

resizers comparison pictures (44.4 MB): http://www.mediafire.com/download.php?5uhh2nha5iaczer

I'd like to ask a few question about resizers backed on signal-processing:

1. Interpolation Coord:
e.g. For image 100x100 => 200x200, let corner pixel be (0,0)
** Is dst (0,0) = src (-0.25,-0.25) ?
** When interplating out of boundary, is source mirrored? e.g. source(-2,-3)=source(2,3)?

2. Downscaling resizers:
a) Downscaling a lot:
I suppose larger window = better?
b) Downscaling by > 0.5:
What is blurry and sinc-like resizer's characteristics?
Both blurring and ringing are affecting less dst pixels, but I wonder if they are getting worse or alleviated.

3. Is any resizer both intensity and gradient interpolating?

JanWillem32

8th July 2012, 02:11

x86 SSE: http://www.mediafire.com/download.php?234wpnwhnso4npo
x86 SSE2: http://www.mediafire.com/download.php?35vcolr2oz95jx3
x64: http://www.mediafire.com/download.php?zopg7v7e81c2cea

I've changed the timer (a type I actually like is used now). The OSD should be okay for now.
I added automatic monitor refresh rate detection to the system. It should activate for Vista and onwards. Note that setting "Refresh Rate Adjustment" to something else than 1 will disable the function. The effect can be seen in the stats screen, and I'd be glad to get some feedback on if it's working for others, too.

@shadewither: 1. It's (-0.5, -0.5). DirectX 9 sets vertices on pixel boundaries, not centres. http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690%28v=vs.85%29.aspx
There are various states you can pin to a sampled texture stage. For example, you can even set this odd mix of settings:m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSV, D3DTADDRESS_WRAP);
m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSW, D3DTADDRESS_MIRROR); Note that for mirrorring, the mirroring happens on odd-plane coordinates. From the standard viewport, with mirroring states on U and V: the samles at the interval [(0, 0), (1, 1)] will be oriented the same as [(2, 2), (3, 3)]. [(1, 1), (2, 2)] will be mirrorred horizontally and vertically. Clamp, wrap and mirror once are a bit more straight forward. http://msdn.microsoft.com/en-us/library/bb174456%28v=vs.85%29.aspx

2. For large factor down-scaling, the typical usage is a (large) gaussian kernel. It just averages a lot of pixels and then outputs one blurred pixel.
For exact down-sizing with a factor of 2 or 3, just average the source pixels.
In a 3D renderer mipmaps are often used to scale images down, while keeping the same texture in memory. This way it's easy to re-use, even if the orientation and visible size of the object changes. http://en.wikipedia.org/wiki/Mipmap
"What is blurry and sinc-like resizer's characteristics?" I guess you mean 'Bicubic' and 'windowed sinc'?
Windowed sinc filters have a basis function, such as Lanczos (a sine type), and a window size. The basis function remains the same for all window sizes, you just add more samples with every larger window step (and less weight on the sample, caused by the base function). These functions only add up to 100% when you sample infinite samples.
The segmented filters, which includes bicubic types have a kernel with weights that always add up to 100%. These kernels don't simply expand by adding samples. The kernel for a spline4 and a spline6 are mathemathically different, and these filters often don't react the same way when extended to larger sampling areas.
Blurring is a welcome trait when down-sizing. Ringing is unfortunately pretty much the same for up- and down-scaling. When down-scaling, the artifacts from ringing will become slimmer, but still very present.

3. The interpolators (both resizers and frame time types) interpolate over the individual R, G and B channels. (Over the gamma slope in 8-bit mode, as a performance compromise. The stages are gammaless in the 10-, 16- and 32-bit surface modes.) I didn't use the gradient operators, as these are not supported on pre-ps3.0 adapters. I also don't think it would be useful to use these, either. (These are more a 3D thing, when you have to deal with orientation and size factors.)

burfadel

8th July 2012, 03:15

Any idea why the internal filters don't compile with yours but do with the normal builds?

JanWillem32

8th July 2012, 04:05

It's a recent development. I get a well-known, but annoying single linker error ("__image_base__" unknown on both x86 and x64). I don't know where it's coming from. __image_base__ is one of the symbols made by the external g++ compiler. I didn't edit any of the third-party code for the internal filters that gets compiled by g++. I'll have to search a bit, I guess.

burfadel

8th July 2012, 07:31

OSD in the new version works fine :) thanks!

HoP

8th July 2012, 09:47

@JanWillem32
another newbie question(i have many question :D )
what is the difference between Video Renderers?
in this thread (http://forum.doom9.org/showthread.php?t=159614) nevcairiel said:

The Video Renderer is responsible for showing the video frames on your screen, in the proper order and proper timing

now i want to know what makes difference between them?
for example why madVR is a good video renderer?

vivan

8th July 2012, 13:12

features (that affect quality) and bugs, stability, resource consumption.
Why madVR is good you can read in madVR thread (http://forum.doom9.org/showthread.php?t=146228).

JanWillem32,
On Intel HD 3000 gpu, when I choose >8 bit in presentation I get no video... With nVidia 540M everything is ok. Is this hardware limitation?

Hera

8th July 2012, 14:27

x64 is pdb

JanWillem32

8th July 2012, 15:16

Thanks, Hera. I changed the link.

@HoP: Various renderers have various ages. Some renderers are just old, such as Overlay, Old renderer and VMR-7. VMR-9 is reasonably new (it's 11 years old). It supports a DirectX 9 level as renderer to use the video card to transform images and paint it on screen. EVR adds a bit of functionality on top of that, mostly to accommodate the MediaFoundation and new DXVA capabilities of recent hardware.
Haali, MadVR, VMR-9 r. and EVR CP are all renderers based on DirectX 9, but have extensions in the programming to support additional functionality for video playback. The basic added functionality is support for OSDs, stats screens, subtitles and custom resizers. The more advanced features for MadVR can be read in the madVR thread. For the guide on VMR-9 r. and EVR CP, I still need someone to gather, compile and edit the text. I've already written a few parts for usage on the Russian site: http://arestarh.pp.ua/ . There isn't a recent guide in English available. (I still have the original text for the items I already wrote in English, of course.)
The new renderer features in these builds are alpha status code. I will sometimes have to change the name of a certain function later on. Descriptions of these functions are still scattered throughout this thread.

@vivan: The EVR mixer can black out without a warning for various reasons with more-than-8-bit outputs. Try disabling the additional video playback filter options in the Intel video control panel. You can also try VMR-9 r., which has worse timing and lacks some functions, but is generally more lenient with its output surfaces option. CruNcher has a very recent Intel CPU with IGP, but I think he also never got that one to work with more-than-8-bit outputs on EVR either.

GTPVHD

8th July 2012, 15:28

Jan, can you see if you can start implementing D3D11.1 support?

http://msdn.microsoft.com/en-us/library/windows/desktop/hh404562

"Process video resources with shaders" section seems interesting, but I don't know if it's feasible or not.

JanWillem32

8th July 2012, 15:40

I'm indeed looking forward to DirectX 11.1, but the DirectX 11 renderer I already started on isn't quite working (the EVR chokes on it, even with the DirectX 9 compatibility layer). DirectX 11.1 adds many video playback-specific upgrades, which I'd love to try in a while. (I should first get the current renderer in proper working order.)

vivan

8th July 2012, 15:51

Try disabling the additional video playback filter options in the Intel video control panelThey are all disabled.

You can also try VMR-9 r.Yes, with VMR-9 renderless it works... Unless I choose shader "YV12 Chroma Upsampling" (since Intel uses NN for chroma upsampling, like ati) =/ It works only with 8-bit surfaces.

Hera

8th July 2012, 16:17

I tried DX10 renderer for Unreal Tournament GOTYE and my CPU told me to GTFO. Is that what you mean by "EVR chocked on it"?

shadewither

8th July 2012, 16:52

Thanks for the reply.

@shadewither: 1. It's (-0.5, -0.5). DirectX 9 sets vertices on pixel boundaries, not centres. http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690%28v=vs.85%29.aspx
There are various states you can pin to a sampled texture stage. For example, you can even set this odd mix of settings:m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSV, D3DTADDRESS_WRAP);
m_pD3DDev->SetSamplerState(2, D3DSAMP_ADDRESSW, D3DTADDRESS_MIRROR); Note that for mirrorring, the mirroring happens on odd-plane coordinates. From the standard viewport, with mirroring states on U and V: the samles at the interval [(0, 0), (1, 1)] will be oriented the same as [(2, 2), (3, 3)]. [(1, 1), (2, 2)] will be mirrorred horizontally and vertically. Clamp, wrap and mirror once are a bit more straight forward. http://msdn.microsoft.com/en-us/library/bb174456%28v=vs.85%29.aspx

I meant for a theoretical pure image resizer (e.g. in plain C, so 1=1 pixel/texel; x,y=0,1,...,100, not uv coord).
I thought that pixel=middle of pixel, so after 100x100=>200x200 resize, NEW pixel(0,0)=NEW position(0,0), should map to a OLD position(-0.25,-0.25) ?

2. For large factor down-scaling, the typical usage is a (large) gaussian kernel. It just averages a lot of pixels and then outputs one blurred pixel.
For exact down-sizing with a factor of 2 or 3, just average the source pixels.
In a 3D renderer mipmaps are often used to scale images down, while keeping the same texture in memory. This way it's easy to re-use, even if the orientation and visible size of the object changes. http://en.wikipedia.org/wiki/Mipmap

So Mipmaps are typically generated by averaging 4 pixels?

JanWillem32

8th July 2012, 17:46

@vivan: good to know that Intel chips also need the extra chroma up-sampling stuff. I'll add it to the list of auto-detection for this item, and change the name of the chroma up-sampling fix.

@Hera: EVR just refused to output on the DirectX 11 surfaces I gave it. It never started to output at all. Later on, I found out that DirectX 11.1 support was added to the EVR.dll/DXVA2.dll version in Windows 8. I don't know about the status of upgrading the DirectX base in Vista and 7 to 11.1 yet. They upgraded Vista to DirectX 11, let's hope 11.1 is pushed in the same way in the near future.

@shadewither: Then you are correct. The pixel center is .25 pixel size top left of the old pixel center for the top left pixel when doing a plain 2× resize. Resizing is done using clamping on the borders, by the way. Mirrored sampling gives ringing artifacts.
Mipmaps are half-size-rounded-up for every step into the mipmap, for every dimension. That way, the lowest mipmap is always a single pixel. Sampling a mipmap is easy. It's presented in the sampling intrinsic as an extra dimension. For 2D textures you sample 8 pixels: 2 (width) × 2 (height) × 2 (mipmap). For 3D textures it's 16 pixels for the depth factor. The output sample is typically linearly interpolated (I'll skip anisotropy for now).

janos666

9th July 2012, 02:18

I guess older Windows versions will get the new DX with their next service packs. Win7 will likely have it but I am not sure about Vista.

I use the Windows 8 RP right now and I would gladly test an mpchc build with a DX11 renderer. :)

By the way... Any news about a real YCC 4:2:0 HDMI output?

ryrynz

9th July 2012, 02:33

Win7 will likely have it but I am not sure about Vista.

7 is guaranteed. Vista won't get it.

nevcairiel

9th July 2012, 05:59

By the way... Any news about a real YCC 4:2:0 HDMI output?

HDMI doesn't support 4:2:0, you need to upsample to 4:2:2 at least.

burfadel

9th July 2012, 08:42

Agreed, Vista won't get Directx 11.1 but Windows 7 should.

gilic

9th July 2012, 09:53

This is how my stats screen looks like with the new version. I don't know if 6Hz is supposed to be correct.
pic (http://postimage.org/image/nn7154snr/full/)

janos666

9th July 2012, 16:10

HDMI doesn't support 4:2:0, you need to upsample to 4:2:2 at least.

Ah, yes, sorry. So, any news about a real YCC 4:2:2 output?:o

Hera

9th July 2012, 17:32

Latest build seems to work well in as so far.

gilic

9th July 2012, 19:30

I've found some sort of regression with your build JanWillem32. The subtitles of this really low res video aren't displayed, normal nightlies and xy-filter both work. Other subtitled videos with a more sane resolution also work correct. The video in question is hyouko 11.5 from this page here (http://mazuisubs.com/212). Settings are subpictures 6, screen resolution and both checkboxes ticked.

edit: Not sure if this is caused by lav splitter. I backtracked to your oldest revision @ mediafire, which has the same issue in combination with lav splitter, the internal splitter works.
edit2: tested so far:

dfr5403li with lav 0.51 -> doesn't work
dfr4739 with lav 0.51 -> doesn't work
dfr4739 with internal splitter -> works
1.6.3.5417.x86.Lite nightly with lav 0.51 -> works

Gelatinous

9th July 2012, 20:08

sexus

9th July 2012, 22:33

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

has it already been added?

p.s: this D3D11.1 support should be interesting with madvr dont tell me even more epic video quality perhaps? OMG!!!!!!!

ryrynz

9th July 2012, 22:38

It hasn't. I figured a slight overhaul of the existing code wouldn't take very long, looks like he's pacing himself.

sexus

9th July 2012, 22:40

darn was hoping i could enjoy myself some gui goodness again , well i sure hope it gets added soon

Keiyakusha

9th July 2012, 23:08

p.s: this D3D11.1 support should be interesting with madvr dont tell me even more epic video quality perhaps? OMG!!!!!!!

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.

Skibicki

10th July 2012, 03:34

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

sexus

10th July 2012, 06:59

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

10th July 2012, 07:59

@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

10th July 2012, 09:28

Everything fixed, thank you.

Skibicki

11th July 2012, 03:21

@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

11th July 2012, 22:31

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

Skibicki

12th July 2012, 04:41

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

12th July 2012, 16:45

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

12th July 2012, 23:38

@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

13th July 2012, 12:05

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

13th July 2012, 16:39

shimaflarex

13th July 2012, 17:21

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

Skibicki

14th July 2012, 01:03

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

14th July 2012, 01:26

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

15th July 2012, 00:21

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

15th July 2012, 00:59

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

Hera

15th July 2012, 01:38

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

15th July 2012, 04:38

@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

15th July 2012, 05:31

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

15th July 2012, 06:58

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

15th July 2012, 07:19

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

15th July 2012, 08:19

burfadel

15th July 2012, 09:09

@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

15th July 2012, 10:44

@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

15th July 2012, 11:46

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

15th July 2012, 12:19

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

15th July 2012, 16:32

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

15th July 2012, 16:40

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

15th July 2012, 18:45

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

15th July 2012, 22:30

@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

15th July 2012, 23:58

@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

16th July 2012, 02:54

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

16th July 2012, 03:13

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

16th July 2012, 03:43

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

16th July 2012, 04:38

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

16th July 2012, 04:46

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

16th July 2012, 06:59

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

16th July 2012, 07:38

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

16th July 2012, 11:01

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

16th July 2012, 13:50

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

16th July 2012, 18:18

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

19th July 2012, 19:13

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

hayan

30th July 2012, 20:38

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

31st July 2012, 06:49

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

ryrynz

31st July 2012, 06:59

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

31st July 2012, 11:45

thanks ryrynz i think that would be the best route

JanWillem32

31st July 2012, 18:17

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

5th August 2012, 08:15

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

6th August 2012, 11:50

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

fagoatse

7th August 2012, 11:14

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.

JEEB

7th August 2012, 12:51

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

7th August 2012, 13:35

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

7th August 2012, 13:45

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

20th August 2012, 16:18

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

22nd August 2012, 15:28

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

Skwelcha

22nd August 2012, 18:29

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

JanWillem32

23rd August 2012, 10:58

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

25th August 2012, 13:45

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

25th August 2012, 15:04

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

25th August 2012, 18:54

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

25th August 2012, 20:15

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

28th August 2012, 14:43

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

28th August 2012, 17:10

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

Skibicki

2nd September 2012, 02:09

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

2nd September 2012, 03:21

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

Skibicki

2nd September 2012, 03:48

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

onomatopellan

4th September 2012, 00:22

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

sexus

5th September 2012, 11:09

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

6th September 2012, 15:45

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

6th September 2012, 16:27

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

7th September 2012, 01:29

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

7th September 2012, 12:13

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

8th September 2012, 01:53

@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

8th September 2012, 04:45

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

Nyanya

8th September 2012, 06:12

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

9th September 2012, 07:01

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

JanWillem32

9th September 2012, 15:55

@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

9th September 2012, 18:02

@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

9th September 2012, 23:03

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

10th September 2012, 10:22

@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

10th September 2012, 15:20

@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

11th September 2012, 12:13

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

11th September 2012, 15:19

@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

12th September 2012, 18:47

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

14th September 2012, 19:50

@fagoatse

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

gilic

14th September 2012, 22:53

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

15th September 2012, 09:23

@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

17th September 2012, 22:07

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

JEEB

17th September 2012, 22:21

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

30th September 2012, 09:04

@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

2nd October 2012, 03:44

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

3rd October 2012, 06:04

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

3rd October 2012, 12:52

Hello JanWillem32,

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

burfadel

9th October 2012, 17:00

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

Hera

11th October 2012, 21:01

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

JbstormburstADV

16th October 2012, 03:23

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

19th October 2012, 20:19

@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

20th October 2012, 10:58

@ Yoshi8765

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

Yoshi8765

23rd October 2012, 22:17

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

24th October 2012, 11:08

@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.

HoP

24th October 2012, 21:16

@ Yoshi8765
1- export your settings to reg file
2- delete the old version completely
3- extract new version(zip file) and place that where you want
4- double click on reg file and apply it to registry
5- Have fun :D

kasper93

25th October 2012, 01:05

@HoP: He can just overwrite .exe file... Settings will remain in register unless you delete them ;p

Yoshi8765

25th October 2012, 01:25

@HoP and kasper93:
Thanks to both of you. I overwriting just like kasper93 said and it looks like it worked. :D Perfect!
I'm using lav filters+madVR to use DXVA and another question came up: under output, I have madVR selected for 'directshow video'. It shows only subtitles with a check, not screenshot, shaders, rotation or (most importantly) DXVA. Should I just ignore this? I guess it's not detecting LAVfilters?

HoP

25th October 2012, 01:34

@kasper93
yes.but i clean registry after removing software :D

@ Yoshi8765
It shows only subtitles with a check, not screenshot, shaders, rotation or (most importantly) DXVA
cause madVR doesn't support them.(if im not wrong)
look at madVR thread . for example ↓
hardware accelerated video decoding (DXVA) is currently not supported

Yoshi8765

25th October 2012, 05:14

@HoP
By DXVA, I mean DXVA2. Does this make a difference?
If madVR doesn't support DXVA2, then the guide I used to set up MPC-HC makes no sense....

HoP

25th October 2012, 23:06

@ Yoshi8765
ask in madVR thread

@JanWillem32
any news?? any new build??

Warlock

7th November 2012, 13:19

JanWillem32, can you create a version with installer? It's much more practical, as well as facilitates the maintenance of the same, especially in relation to the windows registry.

JanWillem32

13th November 2012, 23:14

Sorry for my absence, I'll try to update somewhat regularly again. I haven't been developing much, but I guess I can still report a few things.

@cez4r: Thanks for the links. These are OpenGL and OpenCL tools. The items I'm working with are DirectX based. It's still nice to see that there's improvement to the toolset and support of OpenGL and OpenCL.

@Hypers: It's been a while, and newer drivers are out. Can someone replicate issues with the latest Nvidia Driver (beta or stable)? If this continues to be an issue, I can make a debug build specific to trace problems of this type.

@Sylt: I can shove the entire block of code in a repository, but it will be pretty rough work. The developmental alpha version has a few rough edges. Of course I don't mind sharing the code, though.

@JbstormburstADV: I don't mind integrating new code, as long as I don't have to deal with the current situation of a shared code path of VSFilter and the ISR. I had enough trouble updating the internal section of video renderers and video renderer handlers for Haali renderer and MadVR. (I still haven't even updated EVR Sync.)
A code transplant is not to be taken lightly: the video renderer I imported for fitting on the DirectX 9 parts was not very compatible with the player to say the least. It took weeks before it properly rendered any video. (The previous renderer was such a mess I couldn't work with it at all.)
If integration of new code is worth it and long-term planning can be made to integrate and test the improved code, along with the massive amount of adjustments required to make it work with the ISR, I'd be happy to help. For now, I'll stick with what I have. Most of the changes I made were to get the ISR stable and capable of handling a video renderer's asynchronous queue system. That at least worked out well, but only scratches the surface. The subtitle renderers mostly have issues with image rendering and not so much in terms of allocation parts for the video renderers.

@kasper93: I expect I can patch the subtitle improvements separately from the rest of the items, as these parts are limited in interface changes. The changes to the video renderer section are small and should be compatible with the old set of video renderers and external video renderer sockets.

@HoP: If wanted, I can issue slightly updated builds, but still based on r5855. I haven't been able to integrate anything from the trunk lately.

@Warlock: These are alpha-state tester builds. Although generally working fine, these builds are not intended to replace the standard line of beta and stable versions. I provide them for testing purposes. Users should certainly compare these builds against the trunk versions. As such, be able to switch between and run both (and probably some older versions as well). Building the installer would not help me test the parts of the code I changed. It would only suit the "easy install once and done" case. I'm not targeting that.

Some updates;
- I gave the windowed fullscreen mode another dirty fix. It's not perfect. (It doesn't always detect it when the window behind it changes in size. The organization of the sub-windows hosted by the player is just badly suited for a video renderer.)
- I was notified that my quintic spline algorithms were wrong. After analysis, I found out that I made an iteration for them that is only commonly used for fractal mathematics. Spline forms work somewhat differently. I found the standard weights for the quintic B-spline and I calculated the weights for a Catmull-Rom spline through its Cardinal spline origins with the common quintic Hermite polynomial basis functions. These two resizers are fully functional now. However, the quintic Mitchell-Netravali spline isn't defined through basis functions like Bèzier curves, the B-spline or the class of cardinal splines, but rather something in between. I haven't been able to find much literature on this part unfortunately. I'd like to integrate it though, so in case anyone knows something about polynomial basis functions for the class of BC-splines, or just the given quintic Mitchell-Netravali spline weights, please tell me. Maybe I should also post this question in the main thread, maybe it will reach more people.

kasper93

14th November 2012, 02:40

@kasper93: I expect I can patch the subtitle improvements separately from the rest of the items, as these parts are limited in interface changes. The changes to the video renderer section are small and should be compatible with the old set of video renderers and external video renderer sockets.

Good to hear. I'm mostly interested in bug fix for resizing video frame and subtitles. It's explained here http://afternoonnapsempire.org/subtitle-renderer-matters/ This file http://www.mediafire.com/?301dtzr51lflvj2 show the problem nicely.

BTW. This sample doesn't work with VMR9 in yours build.

madshi

14th November 2012, 08:15

Just for your information, the next xy-vsfilter version (due out in maybe 3 or 4 weeks or so) is supposed to get support for the new subtitle interface discussed here (http://code.google.com/p/xy-vsfilter/issues/detail?id=91). This should allow xy-vsfilter to fully replace the internal MPC-HC subtitle renderer, but for that the MPC-HC internal video renderers would have to get support for the new subtitle interface.

gilic

14th November 2012, 17:40

Welcome back JanWillem32 you have been missed :)
Regarding your resizing algorithms there was some discussion in madshis thread starting here: http://forum.doom9.org/showthread.php?t=146228&page=725 (could be helpful or maybe not ;))

regards

HoP

14th November 2012, 21:06

@JanWillem32
yes,i want a new build,please :D
thanks in advance

fagoatse

24th November 2012, 17:41

any chance for a build compatible with the latest madvr and upcoming xy-vsfilter?

nevcairiel

24th November 2012, 17:55

If you use neither the internal renderer, nor the internal subtitle renderer, what exactly does still build still improve upon? :D

fagoatse

25th November 2012, 00:08

If you use neither the internal renderer, nor the internal subtitle renderer, what exactly does still build still improve upon? :D

Performance comparison between evr-cp and madvr = P.

fagoatse

3rd December 2012, 23:20

So, im trying the latest release (5855 li or sth) and there seems to be a problem with the seekbar, it simply disappears when going into fullscreen and detaches itself from the main window when back into windowed mode.

v0lt

16th March 2013, 17:40

@JanWillem32
I think you may be interested.

MPC-HC test build - MPC-HC 6946 shaders
1. Shaders are now stored in "Shaders" folder, which is located in user profile (if settings in registry) or in player folder (if settings in ini).
2. Shader version is now stored in the shader code. If the shader version is not specified, then used "ps_2_0".

commit da59b57a76 (https://github.com/mpc-hc/mpc-hc/commit/da59b57a76da243275345bc5e6045382e13102e8)

clsid

16th March 2013, 18:35

I would prefer if the Shaders folder would always be stored inside the MPC-HC folder and never in registry or user profile. That makes it easy to include shaders with MPC-HC and share them between all users. It also avoids more mess. Very few people (frequently) modify shaders from within MPC-HC. I propose showing an error message like "Please run MPC-HC as administrator if you wish to edit shaders." when saving a shader fails when using the internal editor. Shaders are also not really a setting in my opinion. It is more a resource.

nevcairiel

16th March 2013, 18:38

Running MPC-HC as an admin is not always possible, and very inconvenient.

clsid

16th March 2013, 20:59

For deployment with the installer the shaders need to be in a shared location. If using the registry is desirable, then the installer could write shaders to HKLM. MPC-HC can read those and add any new ones to the ones stored in HKCU (where they are stored now).

v0lt

20th March 2013, 19:17

As done in the MPC-BE 2309:

1. If the settings in the ini, then shaders are taken from the %player_folder%\Shaders.

2. If the settings in the registry, the shaders are taken from the %APPDATA%\MPC-BE\Shaders.
If this folder does not exist (user does not use installers for religious reasons), the player tries to open the shaders from %player_folder%\Shaders. If he succeeds, then after closing the shaders will be saved to %APPDATA%\MPC-BE\Shaders.

clsid

21st March 2013, 00:44

That would be fine.

Perhaps reading/copying shaders could be delayed until one of the following conditions is true:
- shaders are enabled
- user clicks on "select shaders" or "edit shaders" or "shader editor" in the menu

That should make loading of MPC-HC a little bit faster for people who don't use shaders (the majority).

v0lt

22nd March 2013, 18:24

MPC-HC test build - MPC-HC 6979 shaders (http://www.mediafire.com/?6ksn493kc26fp).
second attempt
Shaders: shaders moved from ini and registry to separate folder.
(MPC-BE 2296, 2297, 2309, 2342)

PS: I canceled this changes to the 6980 version, because other developers insist on a separate branch. But I can not create it.

JanWillem32

24th March 2013, 20:40

Not much new this time. I've mostly been struggling with integrating the various changes from the trunk. If anything got broken in the integration process, please tell me. I had a lot to fix up.
The links are on the first page.
I changed the resizers, and added a few more. For those that set a resizer beyond "Bicubic A=-1.0" will need to re-select the resizer in the options menu.
All resizers can now be selected in the chroma up-sampling renderer options menu.
Color management was updated. Old profiles can be deleted from the user folder. New entries will be saved to the shared program settings folder. It should never trigger an UAC prompt in doing so.
I updated the frame interpolation parts. The "precise" option is a debug mode for now. It will still need some more work I guess...

v0lt, I think that handling the shaders that way is a good idea. I briefly tried it out, and the only remark I have is about the embedding of the compiling level in the string.
The video renderer can just auto-detect the available level of the current video adapter. As compiling with the highest available level is best, I think we should implement that. The pixel shader compiler menu can just default to level 3.0 every time it's opened.
If a shader can't be set on the current device, the set of pixel shaders are cleared anyway. That applies to both faulty shaders and shaders that can't be compiled at the current device's maximum level. The intermediate levels make it even more complicated: ps 2.0a is Nvidia-only, ps 2.0b is ATi-only, other brands skipped the intermediate compiling levels of D3D 9.0 annex b.

I'll try answering e-mail and PMs later today. There's a lot that requires my attention.

gilic

24th March 2013, 22:50

Glad to hear from you JanWillem32. I am still using one of your latest releases and will test the newest version.

regards gilic

edit: I get a "compiling initial pass pixel shader 2 failed" error with EVR-CP

Stephen R. Savage

25th March 2013, 05:34

JanWillem32:

First of all, it's good to see an update to this branch. I have since upgraded from my i965/Core2 setup, but I still like your EVR-CP branch over madVR. This file (http://www.sendspace.com/file/f21ske)doesn't play well with the new build. There seems to be some interaction with the Haali splitter, as the built-in MKV splitter doesn't have issues.

v0lt

25th March 2013, 16:05

The video renderer can just auto-detect the available level of the current video adapter. As compiling with the highest available level is best, I think we should implement that.
It is a good idea. But how to do it?

Skibicki

25th March 2013, 16:09

I noticed video jumps twice after pausing.
multiple formats tested
1.6.7.7014 (b50c26f)x64
EVR-CP
Internal Filters & Lav Filters

JanWillem32

25th March 2013, 22:48

I fixed the initial pass pixel shaders. Thanks for reporting, gilic.
I fully multi-threaded the custom pixel shader compiling passes. That should reduce the initialization time for when multiple shaders are set.
The links are on the first page, replacing the previous version.

Stephen R. Savage, a brief look at that file doesn't reveal much other than that it contains a complex subtitle. I will take some time to analyze it. Does the problem manifest itself in the same manner in the trunk build? What happens when you disable the subtitles or change the buffer size for the subtitle queue? Does the video memory and system memory stay at moderate usage while playing this sample? (You can try Sysinternals' Process Explorer to log both.)

v0lt, DX9RenderingEngine.cpp, line 654 shows a basic way to detect it by the standard caps. Detecting 2.0a and 2.0b require some more conditions of the same kind.
D3DXGetPixelShaderProfile() also works: http://msdn.microsoft.com/en-us/library/windows/desktop/bb172870%28v=vs.85%29.aspx .

Skibicki, the renderer re-initializes some parts when continuing after a pause. When playing normally, data goes into queues at various points (splitter, decoder, mixer, renderer, presentation back buffers). The renderer alone does this for up to 20 frames or .1875 s (whichever is smaller). Not much of the queue can be aborted instantly when pausing. The audio parts are usually far more responsive than the video parts. It is pretty normal for the video renderer to be a bit too much ahead when pausing. After pausing, a reset to some earlier frames can be expected. If there are problems with artifacts, losing synchronization or dropped frames when unpausing, I can look into it. Otherwise it's fine as it is now.

Stephen R. Savage

26th March 2013, 01:25

Stephen R. Savage, a brief look at that file doesn't reveal much other than that it contains a complex subtitle. I will take some time to analyze it. Does the problem manifest itself in the same manner in the trunk build? What happens when you disable the subtitles or change the buffer size for the subtitle queue? Does the video memory and system memory stay at moderate usage while playing this sample? (You can try Sysinternals' Process Explorer to log both.)

The subtitles don't appear to be relevant (subtitle rendering disabled). CPU usage and memory are not different than when playing any other file. However, the renderer updates the image very slowly, dropping many frames. In Ctrl+J, it reports the frame rate as "0.000". The file plays normally after remuxing it with mkvmerge or when using Gabest MKV instead of Haali. Regular EVR and VMR renderless are unaffected.

JEEB

26th March 2013, 12:01

The subtitles don't appear to be relevant (subtitle rendering disabled). CPU usage and memory are not different than when playing any other file. However, the renderer updates the image very slowly, dropping many frames. In Ctrl+J, it reports the frame rate as "0.000". The file plays normally after remuxing it with mkvmerge or when using Gabest MKV instead of Haali. Regular EVR and VMR renderless are unaffected.
That all sounds like Haali's gratuitous use of the DefaultDuration tag. Among other things, it seems to use it for the 'duration' field of the frame it passes through the DirectShow system (instead of, say, calculating the delta between two frames' timestamps). Which then the VSync functionality uses for timely rendering (I haven't checked JW32's sources, but this sounds just that much too close to how it goes with "normal MPC-HC").

Over at the main project the VSync functionality was disabled by default, among other reasons, because too many filters (including MS's WMV DMO stuff) pushed through invalid 'duration' fields and thus making the whole system work in a rather derpy way. If the option is available in this build, you can try it by right-clicking the video surface, and then going Renderer Settings→VSync and unchecking VSync there. That should make the file play better without fixing the DefaultDuration field or switching splitters.

JanWillem32

26th March 2013, 14:07

I fixed the issue. The video information requested by the renderer contained an indicated average frame time of 0. On top of that, some frames were marked with an extremely low frame duration. The first frame for example is set to 110 * 100 ns. That's only appropriate for 90909 Hz video.

Hera

29th March 2013, 01:58

Bugs,
- 32f is only possible in D3D:FS
- Going normal full screen frequently glitches out the seek bar - it stays on the screen looking funny
- When in non exclusive full screen, doing anything on a second monitor cause loss of full screen mode.

W864, i5 3570k 4.5Ghz, NV 660 GTX, 32 GB RAM, 2 x 1080p monitors

PS Welcome Back!

Stephen R. Savage

31st March 2013, 00:51

Perhaps I'm doing something wrong, but LCMS seems to be broken. Whenever I enable color management, I get the error message "unable to create new empty 3dlut" followed by a crash. As of now, I'm stuck on madVR since, in my foolishness, I bought a "wide gamut" display.

JanWillem32

1st April 2013, 02:24

Hera, the issue with the 32-bit floating point mixer + 16-bit normalized unsigned integer renderer surfaces option is new to me. I already saw this issue earlier: http://forum.doom9.org/showthread.php?p=1588557 (http://forum.doom9.org/showthread.php?p=1588557#post1588557) (includes images). Is it a similar case? For both the fullscreen modes the window handle isn't owned by the renderer, but by the main thread that is only bound to the main player window (with controls and all). It's a fundamental flaw. Other rendererers I ever worked on never had such an issue. Those renderers were always bound to one window for the entire runtine, and rarely had to do anything special with the window (such as allowing resizing and maintaining layered windows). I'll experiment some more with the code, perhaps I can solve the worst issues soon.

Stephen R. Savage, last week I edited the code that handles the saving of the lookup table files. I tested it, but it could very well have bugs. Does it matter if you choose "run as administrator" in the main executable's context menu? Does it matter if you switch between the settings in registry mode and the settings in .ini mode? Does a reset to default/optimal renderer settings help? What OS do you use? (It could be a Windows 8 issue with the shared program folder access.)
Don't worry about "wide gamut" stuff. What we have as "wide gamut" right now used to be commonplace among mid- to pro-level CRTs and projectors. Those always featured an sRGB or text mode to cope with then already legacy palettes. It's mostly because affordable LCD and plasma sceens that became popular had (and many still have) terrible display capabilities, the term "wide gamut" was introduced for commercial reasons with some of the relatively better LCD panels. (Even though it's often still just the same 10-bit-or-less junk panels as usual with different software contols.)

Does anyone else have issues with the color management, by the way? I may have to try a few intermediate test builds to eliminate this bug.

MCDamo

1st April 2013, 03:44

JanWillem32, firstly thank you for all the work on these builds, its certainly much appreciated by me and im sure everyone else using them.

I also have the LCMS issues, same error message as above. I tried running as Admin, but the same error occurred, on Win7 btw.

I also observed a bug using Sharpen Complex2 shaders with this build. On letterboxed movies, with black bars top and bottom, a thin yellow line borders the film itself running along the black bars.

Thanks again and looking forward to hopefully providing more input!

MCDamo

1st April 2013, 05:59

An update.
Selecting the 'store setting to ini file" setting in the player menu solved the LCMS error, its working as it should now!

JanWillem32

1st April 2013, 12:28

I just investigated the issue. The error is in the folder creation step. If the folder "Media Player Classic" is manually created in "C:\Documents and Settings\All Users\Application Data\" on XP and server 2003 or "C:\ProgramData\" on newer operating systems (folders may be hidden), the program stores the lookup files normally. I'll fix this issue when I'm back at my PC again.

MCDamo, I'll try to analyze the bug when using that shader. It's probably just not suitable for this renderer mode.

Hera

7th April 2013, 00:48

Issue with seek bar staying on, (http://magneticpudding.com/wp-content/uploads/2013/04/Untitled.png)

So the seek bar stays there - not updating itself.
It starts updating itself when the mouse is on it, but otherwise it doesn't update and just stays there.

And colors are a bit washed out with debug information on full

gilic

7th April 2013, 18:24

It seems the old bug with fullscreen auto hide controls is back. The video is moved upwards by the controls when you move the mouse to the bottom to show them.

@Hera: I think the washed out colors you noticed are because the debug screen has a light grey background.

JanWillem32

8th April 2013, 22:48

-Timing detection is now more robust in case of invalid inputs. (Although that generally means a fallback to 25 fps like the default for VSFilter and the ISR. With some luck, the frame rate lock system can switch to a different frame rate after a few seconds, so it's not that bad.)
-The folder creation routine for the color management section has been fixed. As LCMS has been updated externally as well, I advise to delete all older LUT3D files.
-I applied another fix to the code that takes care of the nasty windowed full screen toolbar. It's bound to break again at some point, but it will do for now. Note that some transitions between full-width maximized windowed and windowed full screen mode may still fail to update. The renderer can't detect this status change correctly while the toolbar of the windowed full screen mode exists. So, just try again if that happens.
-I updated some memory management parts of the ISR and video renderer sections. This is mostly to handle exceptions and for better efficiency to a lesser extent. If any of the error messages I added pop up, please report as usual.

x64: http://www.mediafire.com/download.php?64ab5ef3rox119a
x86 SSE2: http://www.mediafire.com/download.php?we57bk6dl6ylekb

Hera, what "debug information on full" are you looking at? Is it the D3D debug runtime?

MCDamo

9th April 2013, 07:13

JanWillem32,

Thank you for the new build. I tested dfr7067i, and the full-screen windowed mode appears broken. I have a black rectangle in the top left of the screen, and no picture before resizing

Hera

10th April 2013, 02:18

@Jan - I meant stuff like renderer, GPU, frames, offset, etc. CTRL-J stuff when on full

@MCDamo -
Seems to work for me. The biggest gripe is the video squishing that happens when in fullscreen the seek bar appears.

It also seems slower than it should be. There is an intermediate step where the video resizes and there is black area where the seek bar is, but the seek bar appears only moments later.

EDIT: Oi never mind major bug: video stops rendering after when going from one file to another.
That is
1. Open Video File in Directory with other Video Files
2. Using PG DOWN, go to next file
3. Video does not render just audio
4. Can be fixed by resizing
:(

EDIT 2: Yep switching to next file stops video from rendering - it starts rendering again when a resize happens.

JanWillem32

10th April 2013, 10:32

Hera

11th April 2013, 06:07

Seems to work.

MCDamo

11th April 2013, 08:17

Good work Jan!

Havent tested much yet but also seems to work well for me. Not sure why i got the errors on the last build and Hera didnt. I'm assuming system and program configs play a part.

I still have the black bar letterbox issue with pixel shaders. It seems that any "sharpen' type shader is affected. Ill try a few different configs and see if anything changes on my end.

ajp2k11

11th April 2013, 08:53

I tried to fix the window issues and make the resizing+fullscreen windowed mode's toolbar more responsive.
x64: http://www.mediafire.com/download.php?yy464jo4y9mhvd4
x86 SSE2: http://www.mediafire.com/download.php?pade0dojccuycak

About the stats screen; it has 4 modes. The three modes with the jitter graphs are on top of a darkened rectangle in the bottom right. When the mode with the most text on screen is active, the whole window area is darkened a bit under the stats screen. It's there to improve contrast a bit. I can also use some of the more traditional color schemes, such as lovely bright pink and magenta used by the legacy overlay-based renderers if people prefer that.

Using anything higher than 10-bit integer just gives me a black screen with the sound playing in the background. It's been like this for some time now, not sure if it's something I changed or what has happened. Tried it on two different computers, one with Win8/Radeon drivers 13.1 and one with Win7/Radeon drivers 13.1, same thing. Both are using LAV as decoder.

Any ideas?

gilic

11th April 2013, 09:18

There was a bug in recent AMD drivers. I'm not sure if it was 13.1

fagoatse

11th April 2013, 11:51

I tried to fix the window issues and make the resizing+fullscreen windowed mode's toolbar more responsive.
x64: http://www.mediafire.com/download.php?yy464jo4y9mhvd4
x86 SSE2: http://www.mediafire.com/download.php?pade0dojccuycak

About the stats screen; it has 4 modes. The three modes with the jitter graphs are on top of a darkened rectangle in the bottom right. When the mode with the most text on screen is active, the whole window area is darkened a bit under the stats screen. It's there to improve contrast a bit. I can also use some of the more traditional color schemes, such as lovely bright pink and magenta used by the legacy overlay-based renderers if people prefer that.

Did some extensive testing and it works rather well. The video still goes upwards when the seek bar appears but other than that it's fine. Thanks.

ajp2k11

11th April 2013, 14:49

There was a bug in recent AMD drivers. I'm not sure if it was 13.1

Ah ok, I'll try an older version and see if that helps. Thanks!

GREG1292

11th April 2013, 15:10

Ah ok, I'll try an older version and see if that helps. Thanks!

Try this works great for me and I also want to thank Jan for
a great build.

http://www.guru3d.com/files_details/amd_catalyst_13_2_download.html

ajp2k11

12th April 2013, 06:48

Try this works great for me and I also want to thank Jan for
a great build.

http://www.guru3d.com/files_details/amd_catalyst_13_2_download.html

Thanks, I tried the newer beta3 and it works perfectly! :)
http://forums.guru3d.com/showthread.php?t=376313

12.10 also seemed to work so there might be a bug in 13.1...

JanWillem32

12th April 2013, 09:44

fagoatse, the full screen windowed mode's toolbar is badly constructed. It resizes the video window, instead of overlapping the video window like a right-click menu. Without the ugly fix in the renderer code to detect this, the window just gets a regular resizing operation. That means a black screen will be seen during the transitions. Moving the video window upwards just allows both the toolbar and the video window to be seen at the same time, without resizing the video window. I tried to actually fix the toolbar before, but what I wrote just didn't work with the heavily templated window classes the main window, toolbars and menus used. My replacements for the D3D fullscreen window class and the window class I made for the video renderer's canvas seem to work decently enough.

I'm glad that the issue with the black screen output on some AMD cards with the 16- or 32-bit output modes is solved in the latest beta. Makes my work a lot easier. I'll just focus on optimizations for now, unless more bug reports or feature requests come in.

fagoatse

12th April 2013, 10:55

HitomiKun

13th April 2013, 16:12

Any version above tester dfr6995 crashes madVR. Any file that I open with tester x86 SSE2 7067 or tester x86 SSE2 7068 causes a crash inside madVR. I already talked about that problem with madshi and it seems your build is causing it.

madshi

13th April 2013, 17:05

Hera

19th April 2013, 02:05

I highly recommend using dithering for animated content.

fagoatse

19th April 2013, 08:25

I highly recommend using dithering for animated content.

What do you mean precisely? I use Bicubic A=-0.6 as the resizer and tried various integer and float point settings but it seems they are kinda bugged in the latest AMD drivers(13.3 BETA3).
8bit is fine
10 bit is fine when watching 10bit stuff, and glitches in 8bit(darker parts of the image show some strange artificats)
16bit and 32 fp seem to render stuff fine but Play/Pause/Chapters indicator is light blue(Turquoise?) in 16bit, and black in 32(and in 10bit integer as well) while its dark blue in 8bit which i assume is correct. I forgot to take screenshots, sry :(

Hera

19th April 2013, 13:27

What do you mean precisely? I use Bicubic A=-0.6 as the resizer and tried various integer and float point settings but it seems they are kinda bugged in the latest AMD drivers(13.3 BETA3).
8bit is fine
10 bit is fine when watching 10bit stuff, and glitches in 8bit(darker parts of the image show some strange artificats)
16bit and 32 fp seem to render stuff fine but Play/Pause/Chapters indicator is light blue(Turquoise?) in 16bit, and black in 32(and in 10bit integer as well) while its dark blue in 8bit which i assume is correct. I forgot to take screenshots, sry :(

I mean right click -> Renderer Settings -> Dithering Levels
I think it helps lower quality content look better, smoother.

I also cranked the renderer up to 32-bit fp - as that is a prerequisite for it. No visual glitches of any kind, but then again no AMD either (NV 600 + 4.5Ghz i5).

I also like the fact that it is not hardware taxing.

fagoatse

22nd April 2013, 13:47

Using anything higher than 10-bit integer just gives me a black screen with the sound playing in the background. It's been like this for some time now, not sure if it's something I changed or what has happened. Tried it on two different computers, one with Win8/Radeon drivers 13.1 and one with Win7/Radeon drivers 13.1, same thing. Both are using LAV as decoder.

Any ideas?

10-bit integer is still broken in 13.3 beta 3 drivers. Other modes are fine. What a shame : /

@Hera, indeed but it makes my HW melt xd Once 10bit integer is fixed i might be able to use random ordered or light random i guess. These tasks are done on the GPU so I guess there's nothing JW32 can do to optimize them.

JanWillem32

23rd April 2013, 01:58

Color management had a full revision on internal systems. Older profiles are not compatible. Settings from earlier revisions are not exactly the same and will need to be reviewed in the renderer settings panel prior to usage. Profiles are stored in the shared user program folder. If you use .ini settings storage, then profiles are stored next to the .ini file. Note: profiles do not migrate automatically when the .ini/registry setting is switched.
Because building a profile has become slower, the renderer now allows up to 8 minutes to finish the task. Your system may be less responsive when building a profile, as it's a heavy, high-priority task and reasonably well multi-threaded.

The download links are on the first page.

fagoatse, I agree on the point that the OSD could use a bit of color correction. I added a shader to do some work on it.

About the tasks that are done on the GPU: both the GPU and the CPU just run code. Different models of each will have different capabilities, but in general, I'm actually quite good at applying extreme optimizations for both sets of code. Just compare to the trunk EVR CP/VMR-9 r.. My builds are slow at (re-)initialization, but a lot better at actual rendering.

About the dithering types: no dithering is the lightest, static ordered is next, random ordered next to that and all random dither options require equally heavy processing.

About the performance and quality modes: the 8-bit surfaces option (default) is only there for its compatibility and performance. It disables all advanced functions of the renderer.
The 10-bit surfaces and onward enable quality options, if supported. These include dithering, color management and frame interpolation. Frame interpolation also requires hardware support of PS 3.0 due to complexity in the pixel shaders.
For the surfaces options, the added quality of each step up should be visible in the gradation of the color tones. (Although I'm not so sure if it's useful to keep the 10-bit option with the transforms I programmed. The quantization isn't too great.)
The surface bit depth is the quality at which each pixel is stored after every filtering pass of renderer. The renderer has several filtering passes by default. End-users can add custom pixel shaders too (in two of the renderers' stages). Each pixel shader set adds a filtering pass in the renderer.
The internal working surfaces of the renderer do not relate to the output type of the decoder (most commonly 8-bit, 4:2:0 chroma-downsampled, 8-bit, 4:2:2 chroma-downsampled and 10-bit, 4:2:0 chroma-downsampled Y'CbCr).

About intermediate builds: as it takes a much more time than I would like, I don't bother testing intermediate builds with the full set of external filters and such.
The main intention of intermediate builds is to test how the untested new code handles for a few bug fixes and/or features. As I'm always editing a lot of parts in the code at the same time, some parts can be be completely untested (and broken).
For intermediate builds;
-I write code;
-I run some stuff in the debug mode to see if it seems to work for me;
-I compile;
-I upload.

fagoatse

23rd April 2013, 08:24

@JanWillem32
Thank you for such a detailed explanation. Speaking of quality, I think the resizer has the biggest impact(Nowadays I usually have to upsample from 720p->1080p), the rest is kinda negligible(save for dithering maybe) as far as animated content is concerned. Perhaps it's because I watch stuff on a 50" plasma TV while sitting comfortably on a couch 3-3.5 meters away from it. I was kinda afraid of changing from bilinear due to performance constraints but it turned out that resizers are surprisingly well optimized.

As usual I'll provide feedback on the latest build(hopefully by the end of the week).

btw, I'll be switching to a x64 playback chain in a few months time, do 64bit builds you provide contain handwritten SSE2 codepaths as well?

JanWillem32

23rd April 2013, 19:08

The resizers are just filter stages, too. My current playback chain includes five resizing stages: horizontal chroma up-sampling, vertical chroma up-sampling, horizontal image scaling, vertical image scaling and basic bilinear resizing on subtitles. Note that all of them are optional. For all of them except the the subtitle pass quality settings matter.
SSE2 is mandatory for x64. Technically, I have to write at an SSE level as a base. If I add SSE2 parts, those need to be used in a conditional branch next to that in SSE builds. For x64 and SSE2 builds I eliminate the legacy branch for such cases. I also wrote some parts at higher SSE levels (and AVX), those get a conditional branch in the code as usual.

A warning about dfr7100: The function that switches subtitles is not thread-safe. I fixed this issue, and I will optimize this part of the code for a next release.

v0lt

24th April 2013, 17:03

Poor interpolation (decrease) in the Intel HD4000.

EVR (good, no problem)
http://i.imgur.com/zGFWfYM.png

EVR-CP Catmull-Rom spline4 (PS2.0)
http://i.imgur.com/j2MW8Zk.png

EVR-CP B-spline6 (PS2.a)
http://i.imgur.com/v3u0nMC.png

When moving frame the contours of sparks and flashes.
Changing the type of interpolation does not solve the problem.
On the MPC-HC and MPC-BE the exact same problem.

PS:
madVR Catmull-Rom (good, no problem)
http://i.imgur.com/TM4q1fZ.png

JanWillem32

25th April 2013, 10:47

I fixed and optimized some parts of the subtitle renderer. If switching subtitle tracks is still broken, or general performance is worse compared to dfr7100, please report.

v0lt, the filters in the trunk build and mine are just the regular resizers. These have limitations to their filter kernels. Folding down several pixels into one isn't their strong point. That's what you are seeing in those images. It's not a bug. For the plain EVR and madVR the image is obviously pre-processed on resizing.
Such a pre-processing filter doesn't have to be complicated. I added a version of it to the renderer. It will automatically activate when needed, except for the nearest neighbor and bilinear resizers. I'll experiment with more advanced techniques for this grade of down-sizing later on.

madshi

25th April 2013, 10:55

madVR doesn't pre-process for downscaling. It's downscaling shader is similar to how image editor applications do downscaling. Which means: Same basic algorithm as upscaling, but downscaling takes many more source pixels into account with appropriate weights...

gilic

27th April 2013, 23:53

Since revision 7100 or maybe the version before the mpc-hc process stays very often active when I exit the player (audio tracks continue to play). Has anyone else noticed something similar?

JanWillem32

28th April 2013, 10:44

gilic, I had similar reports about the trunk version as well. I actually had such a session in debug mode, so I put the debugger on break. The internal filters were given the end-of-stream message properly, but were never closed. I could not trace the issue.

gilic

28th April 2013, 11:13

For the record I'm only using LAV Filters, so I think the error must be somewhere in the exit management code parts. Maybe there is something wonky happening with some buffers? I had rarely the issue when pauseing a video in windowed mode for a longer time span (~15 minutes or longer) that audio picks up again but video is frozen forever after resuming playback.

Plutotype

30th April 2013, 00:00

euphemon

30th April 2013, 01:04

FWIW, there's no *direct* indication that the MPC-HC test build is responsible for the madVR crash, but the crash occurs at a very weird code location in madVR and it doesn't occur with any other MPC-HC or MPC-BE build, or with any other media player.

Was this ever solved? I have the exact same problem. My bug report is linked here: http://pastebin.com/7RcVQ4Dv and another one here: http://pastebin.com/gxQ6n8BD

Other problems I have with 6995 (possibly symptomatic of the same issue) is that subtitles no longer show up after I seek through a video quickly, which isn't a big deal since it's easily avoidable. But when I use page up/down to change to next/previous videos, a lot of the time MadVR gives an error saying: "madVR reports: -creating sysmem 3dlut volume texture failed".

None of these are issues in official MPC-HC releases.

JanWillem32

30th April 2013, 23:25

I refined the resizer methods for when down-sizing, I tried to fix a few small problems with the subtitle queues and clean up some code. I don't expect much improvements regarding performance this time.

Hera

1st May 2013, 03:12

It opens up in a tiny-arse window now.

gilic

1st May 2013, 09:58

I can confirm this, also with "launch files in fullscreen" active the video is black. You need to re-enter fullscreen for the video to work.

JanWillem32

1st May 2013, 11:27

This is a bit odd. I can't replicate either problem. Maybe it's a settings thing again.
I just reset all settings to default and closed the player. When starting a video, the video window made to fit the video size (zoom to 100% setting) as per standard settings. After that, I disabled the zoom to 100% setting, and indeed, when closing and starting another video, the render window is restricted to the default, small window area. After resetting all settings again, enabling the "Launch files in fullscreen" option and closing the player, the next file I opened displayed correctly in full screen windowed mode.
Can anyone confirm that the issues are resolved when resetting all options? If not, do the problems occur with all sizes of videos played back? As usual, I can upload a few debug builds if useful.

Note: mpc-hc tester dfr7128i contains an updated version of LCMS, for those that use them, delete all previous LUT3D files to renew them.

gilic

1st May 2013, 15:24

My observation was with a fresh .ini with my usual settings set. After testing it seems only to happen with files with a resolution of 720p or higher. In addition subtitles are displayed over each other and stay forever.

ajp2k11

1st May 2013, 19:26

It opens up in a tiny-arse window now.

Happens to me as well. Window when playing file is same small size as when I start mpc-hc without loading a file. Selecting zoom 100% after loading a file corrects it though.

JanWillem32

1st May 2013, 23:26

Okay, I can't replicate any of the mentioned issues, so let's try to debug some of the problems of the latest version with verbose debug builds.
note: the PDB files are useful for those that can attach the debugger.

Hera

2nd May 2013, 04:28

I think this is the stack,
assertion on open MKV

> mpc-hc64.exe!DSObjects::CDX9AllocatorPresenter::CDX9AllocatorPresenter(HWND__ * hWnd, ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * pstrError, bool bIsEVR) Line 97 C++
mpc-hc64.exe!DSObjects::CEVRAllocatorPresenter::CEVRAllocatorPresenter(HWND__ * hWnd, ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * pstrError) Line 393 C++
mpc-hc64.exe!CFGFilterVideoRenderer::Create(IBaseFilter * * ppBF, ATL::CInterfaceList<IUnknown,&IID_IUnknown> & pUnks) Line 446 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn, bool bContinueRender) Line 779 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn) Line 601 C++
mpc-hc64.exe!CFGManager::ConnectFilter(IBaseFilter * pBF, IPin * pPinIn) Line 1155 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn, bool bContinueRender) Line 815 C++
mpc-hc64.exe!CFGManager::Connect(IPin * pPinOut, IPin * pPinIn) Line 601 C++
mpc-hc64.exe!CFGManager::ConnectFilter(IBaseFilter * pBF, IPin * pPinIn) Line 1155 C++
mpc-hc64.exe!CFGManager::RenderFile(const wchar_t * lpcwstrFileName, const wchar_t * lpcwstrPlayList) Line 941 C++
mpc-hc64.exe!CMainFrame::OpenFile(OpenFileData * pOFD) Line 10391 C++
mpc-hc64.exe!CMainFrame::OpenMediaPrivate(ATL::CAutoPtr<OpenMediaData> pOMD) Line 11717 C++
mpc-hc64.exe!CMainFrame::OpenMedia(ATL::CAutoPtr<OpenMediaData> pOMD) Line 14477 C++
mpc-hc64.exe!CMainFrame::OpenCurPlaylistItem(__int64 rtStart) Line 14417 C++
mpc-hc64.exe!CMainFrame::OnRecentFile(unsigned int nID) Line 9023 C++
mpc-hc64.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void) * pfn, void * pExtra, unsigned __int64 nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 96 C++
mpc-hc64.exe!CCmdTarget::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 381 C++
mpc-hc64.exe!CFrameWnd::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 973 C++
mpc-hc64.exe!CMainFrame::OnCmdMsg(unsigned int nID, int nCode, void * pExtra, AFX_CMDHANDLERINFO * pHandlerInfo) Line 1210 C++
mpc-hc64.exe!CWnd::OnCommand(unsigned __int64 wParam, __int64 lParam) Line 2729 C++
mpc-hc64.exe!CFrameWnd::OnCommand(unsigned __int64 wParam, __int64 lParam) Line 371 C++
mpc-hc64.exe!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2101 C++
mpc-hc64.exe!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2087 C++
mpc-hc64.exe!CMainFrame::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 15807 C++
mpc-hc64.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 257 C++
mpc-hc64.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 420 C++
user32.dll!000000000329171e() Unknown
user32.dll!00000000032914d7() Unknown
mpc-hc64.exe!AfxInternalPumpMessage() Line 183 C++
mpc-hc64.exe!CWinThread::PumpMessage() Line 900 C++
mpc-hc64.exe!CWinThread::Run() Line 629 C++
mpc-hc64.exe!CWinApp::Run() Line 832 C++
mpc-hc64.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 47 C++
mpc-hc64.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26 C++
mpc-hc64.exe!__tmainCRTStartup() Line 275 C
mpc-hc64.exe!wWinMainCRTStartup() Line 189 C
kernel32.dll!0000000002c5167e() Unknown
ntdll.dll!000007fa40c63501() Unknown

ajp2k11

2nd May 2013, 10:33

Happens to me as well. Window when playing file is same small size as when I start mpc-hc without loading a file. Selecting zoom 100% after loading a file corrects it though.

Tried 7128i on another PC and didn't get the small window. This PC has Win7 and not Win8 though.

JanWillem32

2nd May 2013, 11:01

Sorry, I forgot to link to the debug manual: http://forum.doom9.org/showthread.php?p=1553934#post1553934
Debug builds are verbose, but only with a debugger or DebugView attached.

edit: the previous debug builds require the debug runtime for DirectX to be installed, for those that find the DirectX SDK too bulky:

ajp2k11

2nd May 2013, 11:33

Sorry, I forgot to link to the debug manual: http://forum.doom9.org/showthread.php?p=1553934#post1553934
Debug builds are verbose, but only with a debugger or DebugView attached.

Running the debug version I get 'Debug assertion failed" and if I click retry to debug it crashes and if I click ignore I get a message that d3d9.dll is missing? Am I doing somthing wrong?

JanWillem32

2nd May 2013, 12:08

See my previous post. I normally link to the the debug runtime DLL for debug builds. The debug runtimes are only installed by the SDK. As the SDK is rather large for just a debug test, I added builds that can do without. Note that not using the DirectX debug runtime will mean that there are no DirectX debug messages issued. (I'm not sure if it matters in this case.)

gilic

2nd May 2013, 17:35

The black screen bug doesn't happen with the debug build ... :/

Hera

3rd May 2013, 05:42

This version seem to not small screen.

ajp2k11

3rd May 2013, 06:44

This version seem to not small screen.

No small window here either on the debug build...

derpycat

5th May 2013, 10:35

Hi I'd like to report that build 7100 AVX x86 crashes in conjunction with madvr and lav filters on my 3570k, though the previous build works fine. I open a file and the player crashes immediately (although the file keeps playing, and I get a black screen).

JanWillem32

6th May 2013, 22:53

As the previous debug builds didn't help at all, I just tried to make some window parts a bit more robust and fix some little things.
Note: I removed some resizers, so users will have to re-select a type for both the main and chroma parts.

As for AVX builds, I have no idea why it would crash on systems that support AVX. For those that would like to try to debug (doesn't use the D3d debug libraries):

Hera

7th May 2013, 03:40

Small screens :(

JanWillem32

7th May 2013, 09:47

Tyestor

7th May 2013, 10:51

Starting any file (specifically .mkv) with LAV Filters (0.56.2) + madVR (0.86.1) crashes MPC-HC x86 AVX r7100.

This is what the MPC-HC bug report gave me: http://pastebin.com/F7LC6AMV - Previous build works fine.

Here's a screenshot of the crash: http://i.imgur.com/tR8Fuke.png

Audio still plays and you can skip to any part of the video without additional issues, just a black screen. Filters list shows that everything that is supposed to be loaded is loaded.

edit: happens with sse2 as well lol.

ajp2k11

7th May 2013, 19:21

As the previous debug builds didn't help at all, I just tried to make some window parts a bit more robust and fix some little things.
Note: I removed some resizers, so users will have to re-select a type for both the main and chroma parts.
x64: http://www.mediafire.com/download.php?sl0n7fp824r8jo3
x86 SSE2: http://www.mediafire.com/download.php?q6ooam48tdonnla

As for AVX builds, I have no idea why it would crash on systems that support AVX. For those that would like to try to debug (doesn't use the D3d debug libraries):
x86 AVX debug: http://www.mediafire.com/download.php?o91bbnp4c479u02
PDB: http://www.mediafire.com/download.php?hj1pe0pxix241pi

No small screen for me with this one...

ajp2k11

7th May 2013, 19:23

I can try an alternative method for the renderer's internal windows. I'm starting to wonder if some of the recent code changes in the trunk introduced this bug, though. I didn't edit much of the window handling code recently.
x64: http://www.mediafire.com/download.php?7yrcknpxxr8bqkc
x86 SSE2: http://www.mediafire.com/download.php?070vvhvv9g31900

No small screen for me with this one either. Seems a bit snappier when going to and from fullscreen but I'm not sure...

JanWillem32

7th May 2013, 22:54

I just upgraded the temp builds to temp2. (I'm not merging any revisions from the trunk until I squashed the latest few bugs.)
The window handling methods are the same as in the previous version, but I refined the code a bit and I added some better thread-safety for the subtitle sections. The standard things I would like to know are:
-Are the window and video sizes and positions appropriate in all cases with these builds?
-D3D fullscreen mode was not a problem in these cases, but how well does the player switch between the D3D fullscreen mode, the bordered windowed mode and the fullscreen borderless windowed mode? (Note that proper Alt-+Tab switching functionality requires additional code, it isn't supported for now.)
-Is the problem with black video in fullscreen borderless windowed mode solved?
-Are the problems with the stack overflows solved?

Hera

8th May 2013, 04:38

Small Screen might be due to 32f and/or dirther 3
on initial file open

JanWillem32

8th May 2013, 06:47

Note: a known weakness of these builds is that they will not start a video if minimized. The alternative window method I added for the first temp builds can't deal with the minimized condition at all. I don't have a solution for this issue right now.

Hera, the ditherer is initialized as part of the final pass and constant frame interpolator, which are in one of the last initialization stages. The surface type is bound to some early initialization passes, but all surfaces are initialized the same way. Only the 8-bit option that sets the renderer to performance mode is different: when set to nearest neighbor it uses the EVR mixer for resizing (experimental feature), and when performance mode is active the initial (chroma up-sampling, color conversion), intermediate (color conversion on subtitles and OSD) and final (frame interpolation, color management, dithering) passes are disabled.
The code that handles the window resizing and video size is mostly in the the parts that handle the window without a renderer on it. Another part bit is in the shared code for all internal video renderers+renderer sockets. In the renderer itself is only the standard routine to query for the window size, compare to the old size and then do a reset. The next part of the renderer code compares the video window rectangle and can renew transforms for resizing and positioning.

euphemon

8th May 2013, 20:10

gilic

9th May 2013, 11:48

I have still the start in fullscreen bug. What I gathered so far is:
- only with EVR-CP
- it's either dependent from resolution and/or aspect ratio (it is not happening with low res + odd aspect ratio files, but with 720p 16:9 and upwards files)

Maybe this change Skip low resolution for autochange fullscreen monitor mode (https://github.com/mpc-hc/mpc-hc/commit/7c772bbaaf88d494d5bd8df9a432dd498ac622b7) has some unwanted effects with your recent versions?

generalmx

10th May 2013, 09:22

I was in the process of updating my multimedia setup, which normally uses your AVX builds, as well as madVR, and ran into the Stack Overflow (code c00000fd) problems myself. So I threw mpc-hc.exe into WinDbg and here's some extra info for you...

Version 1.6.7.7132 x86 AVX (from main thread)
- With ffdshow installed, it always crashes in ffdshow.ax, even if none of the filters are used, or they're blocked. Call stack:

00 57d37350 0a6510e0 00000009 ffdshow!DllGetClassObject+0x9147
01 000007f8 00000000 0e06a2bc ffdshow!DllUnregisterServer+0x4446a
02 00000000 0e06a2bc 00000000 ffdshow+0x17a00

Also note that dxva2.dll is the last module successfully loaded before stack overflow, and that, with ffdshow installed, madVR's debugger is NOT called.

Uninstalling ffdshow has the stack overflow (same code) happen instead in madvr.ax. Call stack:

0cdc0c00 00000000 0cdc0c00 madVR!DllMain+0x482d7
0e9afb5c 745c8543 0cdc0cc0 madVR+0x2ec98
0cdc0cc0 0e9afba0 76f9ac69 madVR+0x1005b
0cdc0cc0 c4a61cd8 00000000 KERNEL32!BaseThreadInitThunk+0xe
4a410050 0cdc0cc0 ffffffff ntdll!__RtlUserThreadStart+0x72
4a410050 0cdc0cc0 00000000 ntdll!_RtlUserThreadStart+0x1b

Also note that dcomp.dll is the last module successfully loaded before stack overflow.

None of these problems occur with AVX debug temp3 without DirectX debug runtime. Note this version seems to mess up subtitles (Anime, tried a few different ones), so I had to install xy-vsfilter and let that take over, and all is well.

Attached is the bugreport.txt that madVR's debugger generated.

JanWillem32

10th May 2013, 13:28

derpycat

10th May 2013, 14:51

gilic

11th May 2013, 00:21

Fix confirmed, thank you!

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

Skibicki

11th May 2013, 21:54

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

JanWillem32

11th May 2013, 23:38

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

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

generalmx

12th May 2013, 00:06

I solved the issue. It was nasty, as it didn't happen in debug builds.
I added another resizer. Those using one of the Lanczos resizers will have to re-select the option. I'll look for a few mere resizers soon. I'm open to suggestions, as long as the filter kernel is described somewhere.
The links are on the first page.

gilic, the problem was buried in the EVR mixer controls. I simplified the code a bit to make it more manageable.

generalmx, debug builds are too slow to decently render anything. The subtitle renderer is the one of the slowest parts, so I'm not suprised.

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

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

gilic

12th May 2013, 00:10

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

Hera

12th May 2013, 06:45

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

khagaroth

12th May 2013, 10:30

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

JEEB

12th May 2013, 12:01

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

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

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

gilic

12th May 2013, 12:09

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

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

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

JEEB

12th May 2013, 12:21

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

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

gilic

12th May 2013, 12:53

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

JanWillem32

13th May 2013, 02:28

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

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

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

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

JEEB

13th May 2013, 07:34

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

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

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

JanWillem32

13th May 2013, 09:17

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

generalmx

13th May 2013, 18:28

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

XRyche

19th May 2013, 02:26

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

JanWillem32

20th May 2013, 09:28

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

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

XRyche, are the errors just stack overflows again?

gilic

20th May 2013, 12:33

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

JanWillem32

22nd May 2013, 21:20

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

derpycat

23rd May 2013, 17:34

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

JanWillem32

23rd May 2013, 21:10

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

derpycat

23rd May 2013, 21:56

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

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

JanWillem32

23rd May 2013, 22:16

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

derpycat

23rd May 2013, 22:40

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

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

Gaius

24th May 2013, 04:42

derpycat

24th May 2013, 09:11

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

fagoatse

24th May 2013, 11:46

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

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

Tyestor

24th May 2013, 15:51

Subtitles are borked.

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

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

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

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

PetitDragon

25th May 2013, 11:38

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

I would report some problems here:

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

Thanks again for your hard work.

gilic

25th May 2013, 12:05

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

PetitDragon

25th May 2013, 15:56

Thanks for the news.

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

gilic

25th May 2013, 16:26

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

JanWillem32

25th May 2013, 18:05

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

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

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

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

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

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

derpycat

25th May 2013, 18:25

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

janos666

28th May 2013, 23:32

fagoatse

29th May 2013, 07:57

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

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

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

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

JanWillem32

29th May 2013, 21:35

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

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

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

PetitDragon

31st May 2013, 05:31

@JanWillem32 or other experts

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

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

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

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

Thanks in advance for help.

janos666

1st June 2013, 00:03

Where did you get this D3Dcompiler_46.dll file?

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

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

JanWillem32

1st June 2013, 08:06

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

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

PetitDragon

1st June 2013, 09:42

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

gilic

1st June 2013, 14:48

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

JanWillem32

1st June 2013, 22:20

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

berga.d

5th June 2013, 15:46

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

derpycat

18th June 2013, 19:18

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

Casshern

26th June 2013, 00:22

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

nghiabeo20

26th June 2013, 04:26

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

nevcairiel

26th June 2013, 07:55

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

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

fagoatse

26th June 2013, 09:18

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

Well, except for some renderer settings.

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

Casshern

26th June 2013, 11:28

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

kasper93

26th June 2013, 22:27

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

JanWillem32

26th June 2013, 22:51

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

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

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

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

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

nghiabeo20

28th June 2013, 04:52

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

JanWillem32

28th June 2013, 09:08

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

Scyna

22nd July 2013, 20:35

Any new avx builds I can test out?

berga.d

23rd July 2013, 08:50

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

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

derpycat

25th July 2013, 13:46

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

:thanks:

Skibicki

28th July 2013, 23:05

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

Working
SSE2 tester dfr7190

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

JanWillem32

21st December 2013, 15:20

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

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

XRyche

21st December 2013, 18:44

Hera

23rd December 2013, 07:43

Oh the optimized builds are back, yay

fagoatse

24th December 2013, 13:25

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

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

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

Hera

25th December 2013, 22:15

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

JanWillem32

28th December 2013, 23:45

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

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

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

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

fagoatse

29th December 2013, 14:42

XRyche

29th December 2013, 15:30

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

Enjoy the time off with your parents.

JanWillem32

29th December 2013, 15:52

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

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

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

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

Hera

4th January 2014, 01:50

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

ryrynz

4th January 2014, 06:03

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

dmiranda

17th February 2014, 14:47

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

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

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

JanWillem32

20th February 2014, 01:22

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

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

XRyche

23rd February 2014, 23:49

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

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

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

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

JanWillem32

24th February 2014, 10:50

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

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

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

XRyche

2nd March 2014, 07:00

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

Aleksoid1978

5th March 2014, 05:11

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

Maybe you can help to fix this.

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

JanWillem32

6th March 2014, 10:41

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

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

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

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

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

XRyche

8th March 2014, 15:12

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

JanWillem32

8th March 2014, 19:22

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

XRyche

9th March 2014, 19:59

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

JanWillem32

9th March 2014, 20:52

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

Casshern

6th April 2014, 10:41

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

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

JanWillem32

6th April 2014, 12:35

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

Casshern

8th April 2014, 01:37

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

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

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

ryrynz

8th April 2014, 02:40

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

Hera

8th April 2014, 19:36

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

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

vBm

8th April 2014, 19:56

Widdershins

26th July 2014, 17:04

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

ryrynz

27th July 2014, 04:26

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

JanWillem32

17th August 2014, 04:44

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

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

Tacio

2nd September 2014, 05:15

Hera

30th September 2014, 14:55

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

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

EDIT: No AVX / AVX2 builds?

Tacio

30th September 2014, 20:14

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

Hera

12th October 2014, 00:29

FYI,

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

v0lt

26th October 2014, 06:41

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

JanWillem32

10th January 2015, 12:44

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

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

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

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

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

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

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

v0lt

10th January 2015, 20:07

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

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

JanWillem32

10th January 2015, 21:59

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

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

Dark Eiri

11th January 2015, 03:04

JanWillem32

11th January 2015, 05:44

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

Dark Eiri

11th January 2015, 06:45

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

Thank you! Flawlessly working now :D
The Catmull-Rom resizer is so great, I wonder why MPC-HC doesn't have it on the main branch.

ryrynz

11th January 2015, 07:55

Thank you! Flawlessly working now :D
The Catmull-Rom resizer is so great, I wonder why MPC-HC doesn't have it on the main branch.

Wouldn't the extra resizers be the easiest thing to take across to HC?

Dark Eiri

11th January 2015, 08:04

Wouldn't the extra resizers be the easiest thing to take across to HC?

They're already on BE, btw. Also the overlay top right "close" button on BE is something I would love to see on HC as well, but I don't think it will be ported =/

v0lt

11th January 2015, 10:49

@JanWillem32
Windows XP, VMR-9 Renderless (it's not my system)
http://i.imgur.com/lGJ5BaN.png

JanWillem32

11th January 2015, 12:22

That's odd. I thought D3DCompiler_46.dll was the last compatible with Windows XP. Did anyone else using XP had this issue with any of the last 6 builds?
Anyway, I updated the files I linked to earlier again. Those that are still using XP and were having this problem can download the files and try again.

Hera

11th January 2015, 20:07

Welcome back!

You can try this version again. I added some better compatibility with several types. Note that results with EVR and VMR-9 may differ. If this one still outputs black screens, we can try to debug this issue with DXVAchecker and such.

I think, in the LAV thread, I was told that it was NVIDIA driver bug... I will test soon.

EDIT: Can't reproduce with newer drivers... so..

Aleksoid1978

12th January 2015, 07:19

Hi JanWillem32.

Can you help implement FilpEx mode support for MPC-HC/MPC-BE EVR Custom ??
My knowledge are zero :)

JanWillem32

12th January 2015, 08:27

Hera, nice to hear from you again and thank you for reporting back with the good news.

Aleksoid1978, also nice to hear from you again. When it comes to renderer stuff I'm very fussy. I despised working on the original renderer. I would classify it as the second-worst renderer I've ever worked on (with the worst one being the subtitle renderer).
When I decided to dump the renderer, I imported a new renderer I wrote earlier. During that phase the program didn't compile for over a week. It took a lot of work to get the renderer at the quality level it is now.
I'm not even going to try porting back any features to the old renderer. I will take no less than the full replacement of the VideoRenderers sub-project, the SubPic sub-project, the OSD renderer, and of course minor changes to the parts of the code that uses the interfaces and lists of user settings I altered. Naturally, for any patches on these parts implemented by others I should evaluate porting them back if they're useful.
This will come at the cost of the DirectX 7 renderers, as I could not be bothered to update these. EVR Sync is also disabled in my version of the video renderer section, but I don't mind porting the synchronization parts back from the original (properly working version) Ar-Jar wrote if anyone can convince me that that synchronization/scheduler mode is useful. Note that I implemented two frame-time schedulers already. However, I don't think adding another one based on the old Present() call delay would be useful at all.

When it comes to Discard, Flip and FilpEx presentation modes the original renderer is totally incompatible, by the way. These require IDirect3DDevice9Ex::ResetEx() and full renew mechanisms for the renderer, and proper resource management for that to work. Even worse, the original renderer hardly used any IDirect3DDevice9Ex functionality at all. That makes DWM scheduling for Windows Vista in windowed mode with Aero enabled, FlipEx mode scheduling for Windows 7 and newer in windowed mode with Aero enabled, and Discard or Flip mode scheduling for Windows Vista and newer in fullscreen exclusive mode near impossible. (Note that the constant frame interpolator I wrote also uses these advanced features for its scheduling.)

v0lt

12th January 2015, 09:38

JanWillem32

13th January 2015, 12:56

The subtitle resizer pass integration went easier than I thought it would go. Note that the resizing shaders only activate in the renderer's quality mode with any of the standard resizer shaders activated, and with the subtitles set to "Screen" size in the subtitle options menu. In other modes the renderer reverts to the regular bilinear scaling.

Hera

17th January 2015, 23:29

Welcome back!

I think, in the LAV thread, I was told that it was NVIDIA driver bug... I will test soon.

EDIT: Can't reproduce with newer drivers... so..

OI, Upgraded GPU to GTX 970 EVGA and drivers to 347.09,

When opening, player snaps to smallest size possible (video hidden entirely) and I have to resize it to get the video to show up (something reporting video size as 0 x 0 maybe?)

* Video Black and not playing if P010 output is enabled
* If P010 disabled in LAV, plays
* MPDN works though with P010 checked

EDIT: Also newer version (not sure which one) now shows subtitles for one file that didn't have them before for some reason. Cool.
EDIT2: Granted subtitle shadow looks uneven, not centered on the letter itself..
EDIT3: Anyone got a black screen when watching video full screen (alt-enter) with dfr7370rrrri?

JanWillem32

18th January 2015, 10:40

I updated the builds in my previous post. These mostly feature updated down-scaling resizers.

Hera, I think I've solved the window resizing bugs this time. The windowed fullscreen implementation is still terrible, though.
P010 video doesn't work because the video driver seems to accept it, but fails to render on it. The renderer does not get an error from the mixer in such a case. (It's the same thing as with the Intel driver that doesn't allow mixer output on 16- or 32-bit floating-point surfaces when using the EVR mixer.) I can't fix this issue. I can disable P010 video input entirely (I've done so with AYUV before for another reason), but that really doesn't solve a driver bug.
Do you have a sample or images of the uneven subtitle shadows? I haven't encountered this bug before. (I also hardly changed the subtitle renderer, so I don't really know what to fix in this case.)

JanWillem32

22nd January 2015, 04:39

XRyche

22nd January 2015, 05:14

With the latest tester subresize exp build I'm getting a "compiling final pass pixel shader failed" unspecified error on all modes except 8 bit integer with the x64 build on the latest AMD drivers. I'll let you know about P10 input once we get past this. Let me know if you need the .dmp .

Hera

22nd January 2015, 05:54

Binge watched a series. Resolution is detected well. Alt-Enter sometimes causes black screen.

JanWillem32

22nd January 2015, 06:04

I replaced the builds again. There was a minor bug that happened when selecting some of the random dithering levels for the final pass stage that gave the compiling error.

The windowed fullscreen mode is terrible at best. The renderer can't always compensate for the problems that the invading toolbar at the bottom causes. I can try some more dirty fixes.
For now, this is what happens when the renderer's dirty fixes are disabled:
-

XRyche

22nd January 2015, 06:31

I'm still getting the "compiling final pass pixel shader failed" unspecified error on all modes except 8 bit integer. I tried different dithering settings as well. Even set to rounding it still displays the "final pass" error.

ts1

22nd January 2015, 12:33

Seek/controls bar constantly flickers on Vista
link to test video http://www.filedropper.com/test_120

Edit: If i resize player with playing video to smallest possible size I'm getting error "compiling primary resizer pixel shader failed" (default settings).

Edit2: also the same error if I just stop the video.

Edit3: Crash on old Intel GPU (ASUS eee pc, win 7, default settings). Black screen on previous build. Last known working build is from post made on 20th February 2014.

Edit4: Crash dump http://s000.tinyupload.com/index.php?file_id=17510320218749115911

JanWillem32

22nd January 2015, 20:05

I replaced the builds again. The final pass has been edited. I hope that it solves the compiling issue.

ts1, It has been a while since I last used the Vista compatibility mode. I changed some things that might solve the flickering toolbar and black screen output when using the windowed fullscreen mode.
I edited the resizer shaders to be compatible with even 1×1 pixel output sizes.
The crash report is currently awaiting approval, which can take a while. Most users of this forum upload their files externally for that reason. I'll look at it when it's approved.

JanWillem32

22nd January 2015, 20:39

ts1, I took a look at the .dmp file, but I can't do much analysis on it with a regular build. I compiled two debug builds without D3D debug (as that requires a large debug runtime download to install). These will probably give more information about these crashes. Before running these builds, add the correct (x86 or x64) D3DCompiler_47.dll (or D3DCompiler_43.dll for Windows XP) version next to them in the folder and run DebugView to get a log from the debug builds. DebugView is only small and doesn't need to be installed to run: https://technet.microsoft.com/en-us/sysinternals/bb896647.aspx .
-
Just to be sure that people don't just download these: these debug builds are unsuitable for regular usage. They are slow and very large so that they can do debugging tasks.

XRyche

22nd January 2015, 21:33

The latest resizer build did the trick. I tried 32 bit and and lvl 31 dithering initially. I'll try the other modes in a few hours. Two questions; Has the Horizontal/Vertical sharpen complex, deband and denoise for LMS rendering on floating-point surfaces shader scripts gone through any changes in the past 4 months? Has the renderer gone through any changes to make the scripts unusable?

JanWillem32

22nd January 2015, 21:45

ts1

22nd January 2015, 22:19

seems log doesn't contain any useful information but player showed 3 errors and then starts to play the video normally using another video renderer. Errors are:

assert failed
0 at line 22821 of ...\dx9allocatorpresenter.cpp

assert failed
0 at line 7456 of ...\dx9allocatorpresenter.cpp

D3DERR_OUTOFVIDEOMEMORY
CreateDeviceEx() failed initialization

log http://s000.tinyupload.com/index.php?file_id=07188663516191686993

JanWillem32

22nd January 2015, 22:56

I'm sorry but the biggest thing I really cannot fix is are out of memory errors. I can merely program error messages for those.
You can reduce the video memory footprint though:
-Under "Options", "Playback", "Output", set 4 mixer buffers (the minimum) and set the resizer to bilinear
-Under "Options", "Subtitles", set the buffer to 0
Under the regular renderer settings you probably want to use only 8-bit integer textures. The 16-bit options are probably too demanding in memory footprint.
Don't forget to also close other applications that could use video memory and you can try the D3D fullscreen option, as it takes less fullscreen buffers than the windowed presentation chain.

ts1

22nd January 2015, 23:21

With D3DFullscreen it actually does work. Didn't know that this netbooks is so low on video memory.

XRyche

23rd January 2015, 00:16

Since I standardized LMS as a basis rendering every color model (Y'CbCr, R'G'B', RGB, XYZ, LMS, L'M'S and onward transforms) in the renderer has been the same. The pixel shaders from then until now are just the same.
I did optimize some stages in the renderer and added functionality, such as resizers for bitmapped subtitles.

Okay, I understand.

I don't know if you remember or not, but on Vista 32 bit I was having issues with DVD playback with certain DVD's. That's completely solved itself since I did a clean update to 8.1 64 bit. I guess it was something messed up with Vista or more likely, something messed up with my setup specifically.

Also, just something to point out, your subtitle renderer is the only one that displays vobsubs on that certain DVD correctly.

I also forgot how pristine your resizers look :) . Especially since I can now use the chroma resizers now.

One last thing. P10 doesn't crash the player for me but setting LAV video to only output P10 (using a 10 bit encoded file) causes LAV Video to drop out and be replaced by Microsoft's decoder.

Hera

25th January 2015, 06:28

When paused MPC:HC takes up 40% CPU time? Anyone experience this?

XRyche

25th January 2015, 06:44

Yes Hera, I get the same thing. My total cpu usage hovers around 32% regardless of what the cpu usage was when the file was playing.

Hera

25th January 2015, 07:04

Yes Hera, I get the same thing. My total cpu usage hovers around 32% regardless of what the cpu usage was when the file was playing.

And I thought why were my fans spinning when idle. :p

ts1

25th January 2015, 14:46

"compiling primary resizer pixel shader failed" when trying to open the video in 800x600 resolution.
Also seek bar in d3d fullscreen mod is not refreshing.

Edit: Found the reason of crushes on asus eee pc. I don't know why, but option Alternative VSync was enabled. Without VSync it's just a black screen. In d3d fullscreen as I already said video plays normally.

foxyshadis

25th January 2015, 23:22

I updated the builds again my earlier post. A driver bug in the AMD drivers can cause crashes in when the renderer is using its library.

About the P010 video input, does any driver actually work with it? I can disable P010 input completely if it's inconvenient, but if any driver actually adds functional P010 input for the EVR mixer, we will have no way of knowing that.

The new GTX 960 is supposed to have full fixed-function 10-bit hardware decode, with P010 in and out. I'd hope that applies to EVR, but nevcairiel is the only one who has one at this point.

XRyche

26th January 2015, 01:43

The new GTX 960 is supposed to have full fixed-function 10-bit hardware decode, with P010 in and out. I'd hope that applies to EVR, but nevcairiel is the only one who has one at this point.

That's kind of surprising coming from Nvidia considering what the majority of 10 bit encodes are now. I do suppose it is forward thinking though,

Asmodian

26th January 2015, 02:07

That's kind of surprising coming from Nvidia considering what the majority of 10 bit encodes are now. I do suppose it is forward thinking though,

UHD bluray will use 10-bit HEVC so they need a hardware solution soon. This is not for the current 10-bit encodes. :)

nevcairiel

26th January 2015, 16:26

The new GTX 960 is supposed to have full fixed-function 10-bit hardware decode, with P010 in and out. I'd hope that applies to EVR, but nevcairiel is the only one who has one at this point.

I believe EVRs DirectShow front-end is just broken with 10-bit YUV formats. It doesn't do buffer and image size calculations correctly anymore once you try.

Maybe it works through DXVA, i didnt manage to test that yet, but its certainly broke for "normal" image buffers in memory.

ts1

26th January 2015, 19:00

So this crushes and black screen on a netbook is not netbook related. Turn off the Aero - black screen, then enable Alternative VSync - crush.

JanWillem32

27th January 2015, 02:24

I replaced the builds again. I've reduced the processor time requirements for the constant frame interpolator and alternative scheduler modes. However, I can't really improve much for the old Alternative VSync mode in this regard.
When the renderer starts up from paused mode it may take a part of a second to recover from slow-cycling mode though. (That's why the renderer used to be running so fast in paused mode to begin with.)

ts1, do you have more information about that error in 800×600 mode? Is it the desktop compatibility mode/remote desktop mode? Does it matter what kind of video you are opening?
I tried debugging in 800×600 mode, and it seemed mostly fine. It's just really inconvienient given the amount of screen space the debugger/compiler needs on screen to reasonably operate. Any more details on the error would be very welcome, as I can't replicate the issue.
I managed to fix the errors related to Alternative VSync modes. It required quite a lot of changes. If anything still seems wrong, please tell me. (Though I advise using the constant frame interpolator and alternative scheduler modes when possible with Desktop Composition enabled in windowed mode, as these schedulers are more modern.)

About 10-bit mixing, AYUV support and such, EVR isn't ideal. EVR features a broken, and really slow AYUV to R'G'B' converter, which always assumes 8-bit output. I suppose for the 10-bit stuff the problem is similar. I'm not sure how much the video driver contributes to the problems, though. The driver mixing functions are exported through DXVA2.dll (and are routed through the EVR mixer in EVR.dll). These can be viewed with DXVA Checker on the "Processor Device" tab. Each device will have a set of supported in- and output types. When types are not listed (and can't be emulated by the AYUV to R'G'B' converter in EVR.dll), they are not supported.

Hera

27th January 2015, 02:32

JanWillem32

27th January 2015, 03:19

Or one of the other two. I should probably get rid of the experimental tag. The subtitle resizers seem to work fine.

Hera

27th January 2015, 03:55

Or one of the other two. I should probably get rid of the experimental tag. The subtitle resizers seem to work fine.

Well I still get ~40% CPU when paused.

XRyche

27th January 2015, 04:44

I'm now getting 5-7% CPU usage when paused. I am also using the Alternative scheduler and Frame Intrapolation - Motion Adaptive, High Motion and everything works without issue and as expected.

Yes, the subtitle resizers are working fine for me as well. No issues at all.

ts1

27th January 2015, 08:21

I'm sorry I meant video with 800x600 resolution. Just google "800x600 clip download".
Seek bar in d3d fullscreen mode still not refreshing.
And yes when paused mpc-hc takes ~25% of 4 core CPU without Alternative scheduler.

Video playing fine without Aero now. Alternative VSync works too, but I never used it, it was an accident.
But now at the beginning and when toggling to/from fullscreen black screen for ~5 seconds (with or without Aero). In d3d fullscreen mode it works fine.

Edit: Black screen on SSE build.

JanWillem32

28th January 2015, 02:00

Hera, are you sure that you are using the constant frame interpolator or alternative scheduler mode? The constant frame interpolator pretty much only works properly in D3D fullscreen mode and the alternative scheduler mode works both in windowed mode with desktop composition enabled or D3D fullscreen mode. The alternative scheduler mode is only available for EVR on Windows Vista and newer.

XRyche, the constant frame interpolator options override the other scheduling modes, as you can only have one active at a time.

ts1, I just tested an 800×600 video. All modes from 50% size windowed to D3D fullscreen in stretched mode work fine. Let's try new debug builds. Maybe the log can tell us more about what the shader compiler is having trouble with.
About the seek bar in d3d fullscreen mode that isn't refreshing, it's not a bug. The OSD renderer is really simple in setup, but not that efficient. It only refreshes when it receives new commands. I'm aware that the windowed fullscreen is slow. I can't change that. The bug with the black screen on the SSE build has been solved.

debug builds:
Before running these builds, add the correct (x86 or x64) D3DCompiler_47.dll (or D3DCompiler_43.dll for Windows XP) version next to them in the folder and run DebugView to get a log from the debug builds. DebugView is only small and doesn't need to be installed to run: https://technet.microsoft.com/en-us/sysinternals/bb896647.aspx .
-
Just to be sure that people don't just download these: these debug builds are unsuitable for regular usage. They are slow and very large so that they can do debugging tasks.

regular builds (just small updates this time):
-

XRyche

28th January 2015, 02:49

XRyche, the constant frame interpolator options override the other scheduling modes, as you can only have one active at a time.

Ah , I see. So is there any benefit from the Alternative Scheduler besides, if I understand it correctly, more stable frame rates?

JanWillem32

28th January 2015, 03:03

It's actually more efficient than more precise. The constant frame interpolator and alternative scheduler modes can queue up frames for rendering, instead of rendering one frame at a time and then halting just before it's time to present that frame. Especially for the cases of high frame rates and interlaced video the renderer's bottlenecks are severely less present. Hiccups from the system (or subtitle renderer for that matter) will also be less of an issue because the renderer will allow some time (20 frames or up to .1875 s, depending on which is lower in time) for these external tasks without affecting the renderer much.

XRyche

28th January 2015, 03:18

Thanks for setting me straight :) .

ts1

28th January 2015, 06:04

Debug builds don't work properly.

errors on any video:
assert failed
0 at line 7456 of ...\dx9allocatorpresenter.cpp

could not open D3D9.dll

Edit:
Just tried it on another pc and 800x600 video works there. Maybe it's something related to Vista.
Maybe you can fix this glitch when, after pause and some delay it shows another frame? It's the only glitch, not counting seek bar, in a d3d fullscreen mode now. In windowed mode with Alternative scheduler it shows players logo instead of this frame. If I drag the player then it shows the frame.

JanWillem32

28th January 2015, 16:28

I just replaced the debug builds to not require the D3D9 debug runtime. (It's not something I normally set in debug builds, hence the error.)
The presentation method for Windows Vista with Desktop composition enabled is indeed slow to adapt to changes. It's a system-wide problem that was solved in Windows 7 by adding a new presentation method.
I still can't replicate any issues with playing back an 800×600 resolution video, even in Windows Vista compatibility mode.

ts1

28th January 2015, 17:09

Results: http://s000.tinyupload.com/index.php?file_id=27907279717710161431

JanWillem32

28th January 2015, 17:27

Which of the 16 resizers cause this problem, and how much are you resizing (window size, and video area on the window)?

ts1

28th January 2015, 17:41

All except first 3 and B-spline4-8. Not resizing, windowed, default settings.

JanWillem32

28th January 2015, 17:56

When not resizing the renderer will not compile the resizer shaders and just skip the resizing pass or use nearest neighbor sampling to make a copy. What is the window size and video area indicated by the stats screen when you play back the sample (with one one of the resizers that seems to work)?

ts1

28th January 2015, 18:01

Tried with the bilinear, stats screen says display size is 376x301, but window size seems like 800x600. And this error appears at the very beginning. I'm not doing anything with the player.

Edit:
376x301 is in monitor EDID section.
window size, video area and video size shows 800x600

JanWillem32

28th January 2015, 18:30

The display size stating 376x301 is expressed in mm, not in pixels. A 1308x981 video area on a 1280x1024 window is possible if you zoom in a bit (the sides will be clipped off though).
I suspect it's the down-sizing kernel that's giving problems. Would you disable the "Auto-zoom" function on the "Options", "Playback" tab? It might be the opening size that's giving problems. (Auto-zoom is applied some time after opening a video.)

ts1

28th January 2015, 18:40

No, without auto-zoom it's the same video area size in the full screen. With auto-zoom it works tho on second try, just after the error, if I press play button. Without auto-zoom it doesn't work at all.

Edit: And it works if I first open the video with some different resolution and then 800x600 video.

JanWillem32

28th January 2015, 18:52

So, the error only happens when rendering video on the small (310×200) video size (the size the player starts with when no video is playing)? Then it's something with the down-sampling kernel.

ts1

28th January 2015, 19:04

hah it works if I make player a little bit smaller or larger (disabled auto-zoom), only doesn't work in size at which player starts.

Edit: figured out why video area was 1308x981. Zoom1 was chosen in video frame menu, switched to touch window from inside and now it's correct.

JanWillem32

28th January 2015, 19:54

I've attempted to fix the resizer. I hope it works.
-

ts1

28th January 2015, 20:13

It works now.

While testing noticed that in stats screen green line is very unstable with Alternative scheduler (GPU NV 660).

JanWillem32

28th January 2015, 20:52

The green line is the recorded sample time versus the presentation time (middle bar). Note that it can very imprecise; when pulldown is applied on a video for example some frames will last twice as long as others, making large spikes in the graph.
When presenting in a window you also have to deal with the secondary present to the screen from the desktop. That's why the D3D fullscreen mode is more stable.

XRyche

28th January 2015, 22:59

With your latest "regular builds (just small updates this time)" x64 the following upscaling chroma fix for AMD/Intel are giving "compiling initial pass pixel shader failed" : B-spline4, Catmull-Rom spline6, and B-spline8. Lanczos4 doesn't appear to be displaying colours. All the image resizers appear to be working as they should. I honestly don't know if it started with this build or before. I've hardly only ever used Lanczos 2 or 3 and untill recently never the chroma upscaling fix resizers.

JanWillem32

29th January 2015, 00:49

I replaced the release-type builds in my earlier post and I deleted the debug builds.
XRyche, thank you for noticing these bugs. This stuff must have been broken for a while now, as I haven't edited these routines recently at all.

XRyche

29th January 2015, 00:58

Oh, this wasn't the debug build, I made sure of that. Should I go ahead and d/l the build from here again : http://forum.doom9.org/showthread.php?p=1707384#post1707384 or do I already have it?

JanWillem32

29th January 2015, 01:30

You can download the new builds with using the old links. I just update the files if only minor changes have been made to the builds.

ts1

29th January 2015, 08:10

The presentation method for Windows Vista with Desktop composition enabled is indeed slow to adapt to changes.

It's slow with or without Desktop composition. And it was ok before the fix of the black screen with Desktop composition disabled and crash with VSync enabled.

JanWillem32

29th January 2015, 12:14

One of the reasons the initialization for the monitor section is slow can be read from the log you posted earlier:00000120 0.15050118 [816] Video renderer attempting to use the generic Ex mode method to read the display refresh rate
00000121 0.26801983 [816] Video renderer GetTimingReport() failed the first try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000122 0.26801983 [816] , the renderer is giving the driver half a second and will try again
00000123 0.87145257 [816] Video renderer GetTimingReport() failed the second try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000124 0.87145257 [816] , the renderer is giving the driver half a second and will try again
00000125 1.47645974 [816] Video renderer GetTimingReport() failed the third try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000126 1.47645974 [816] , the renderer is giving the driver half a second and will try again
00000127 2.08050847 [816] Video renderer GetTimingReport() failed the fourth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000128 2.08050847 [816] , the renderer is giving the driver half a second and will try again
00000129 2.68555593 [816] Video renderer GetTimingReport() failed the fifth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000130 2.68555593 [816] , the renderer is giving the driver half a second and will try again
00000131 3.29060459 [816] Video renderer GetTimingReport() failed the sixth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000132 3.29060459 [816] , the renderer is giving the driver half a second and will try again
00000133 3.89564085 [816] Video renderer GetTimingReport() failed the seventh try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000134 3.89564085 [816] , the renderer is giving the driver half a second and will try again
00000135 4.50069332 [816] Video renderer GetTimingReport() failed the eighth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000136 4.50069332 [816] , the renderer is giving the driver half a second and will try again
00000137 5.10676622 [816] Video renderer GetTimingReport() failed the eighth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field.
00000138 5.10676622 [816] , the renderer is giving the driver half a second and will try again
00000139 5.10684347 [816] Video renderer GetTimingReport() failed the ninth try with error 0xc0262589: An operation failed because a DDC/CI message had an invalid value in its command field. It seems that your monitor isn't responding to DDC/CI calls. Are you sure it's not only at initialization time but also at minor resets because of resizing the window? (Note that I can lower the amount of time given in between GetTimingReport() calls for cases like this. That might help eitherway.)

ts1

29th January 2015, 12:36

It's always when trying to resize the window or enabling/disabling VSync or switching the bit depth of the surface, enable/disable of the Alternative scheduler is fine tho. The same is on Win 7 at least with disabled DWM.

JanWillem32

29th January 2015, 13:29

Resets are detected every .5 second, and the Alternative VSync runs its own thread that needs to be shut down for every resize or other reset condition. These things may take a while. I don't see anything really problematic at the moment. Do the resets take more than two seconds for you?

ts1

29th January 2015, 15:02

Yes, 5 seconds, no matter netbook or i5 and NV 660.

JanWillem32

30th January 2015, 01:21

I replaced the builds in my earlier post. I made the timeout after failures from GetTimingReport() much shorter to solve the long (re-)initialization time. Unfortunately, I don't have a replacement for this timing report functionality. I'll have to look up some other methods.

ts1

30th January 2015, 07:14

Yeah better now. It takes about 2 seconds now.

XRyche

30th January 2015, 12:00

JanWillem32, did you fix the AMD/Intel Chroma bug in the latest build already? I hope you did or I've got gnomes in my PC.

JanWillem32

30th January 2015, 18:28

I just double-checked it, and all 4:2:0 and all 4:2:2 passes seem to work fine.

ts1, I might be able to lower it a bit more. I'll work on it later.

XRyche

30th January 2015, 19:01

I just double-checked it, and all 4:2:0 and all 4:2:2 passes seem to work fine.

Meaning that it was a problem on my end and not with the renderer.

JanWillem32

31st January 2015, 13:21

I replaced the builds in my earlier post. I added a source code link and fixed a bug with the general Lanczos resizers.

XRyche

31st January 2015, 15:13

The Lanczos4 image resizer is failing in the new build. All others appear to be working.

v0lt

31st January 2015, 16:34

The latest builds strong jerk when the window is resized.

JanWillem32

31st January 2015, 17:19

I replaced the builds in my earlier post.
XRyche, I thought I tested all resizers I edited. Oh well, it was just one typo. Thank you for reporting.

I also reverted the refresh rate calculation function I edited. The edited version was prone to fail and output an infinite refresh rate.

v0lt, it should be partially fixed now. I'll see if I can further optimize the re-initalization speed.

XRyche

31st January 2015, 18:38

All the resizers are pristine and working as they should again. Thanks for fixing it so fast.

Hera

31st January 2015, 18:41

I reset the player's settings and tried again (x64 Jan 31 2015 build),
~ 0 CPU when playing
~ 40 CPU when paused

EDIT: AH!
Alternative scheduler is disabled on the default settings. Base on your previous post, shouldn't the default settings have it enabled?

JanWillem32

31st January 2015, 19:33

As the alternative scheduler was an experimental item, I made it opt-in instead of the default. In a later stage I might eliminate the option and just make it default-enabled.

Hera

31st January 2015, 19:55

As the alternative scheduler was an experimental item, I made it opt-in instead of the default. In a later stage I might eliminate the option and just make it default-enabled.

Yeah... just had my mouse pointer jerky... closing IE11 helped...:confused:

JanWillem32

31st January 2015, 20:49

v0lt

31st January 2015, 21:00

I did some tests to bicubic interpolation in MPC-BE. One pass mode works well, but two pass mode has a strong distortion when A = -1.0.
Your builds give similar results as MPC-BE with two-pass interpolation.
If you're interested, here's the test results - https://yadi.sk/d/KN4d6JzPeNVyK (1pass VS 2pass VS madVR).

This is obtained for Intel. I was told that on other cards, this problem is missing. :confused:

Hera

1st February 2015, 00:00

The alternative scheduler forces the desktop composition to compose at always the full display refresh rate (the only way to do reliable scheduling). Other applications can slow down the system if they have to compose at higher rates than they normally do.

That sounds like a major tradeoff.

Anyway, I will crank up dithering and whatnot with alternative scheduler and watch some shows and get back if I see any other issues :)

JanWillem32

1st February 2015, 00:24

v0lt, It indeed does seem like it's only on Intel graphic adapters. My old ATi HD4890 doesn't give such artifacts as in the sample picture for two-pass Bicubic A=-1 resizing. The kernel for the cubic filters can be written in three forms however. Here are the two other forms, maybe these will work.
Note 1: these builds feature new window handling code to remedy the jerky resizing you mentioned earlier. It might work, but it's probably still unfinished.
Note 2: do not down-size with the bicubic A=-1 filter. I didn't check the down-sizing kernel with these methods yet.
Variant B is less efficient. I'm not sure if I'd want to make it default. So, I'm hoping that the code in variant A will work for all cases.

Hera, it's how the system handles on-screen windows with high output frame rates. It's usually sufficient to minimize or cover up a whole window to prevent it from rendering (and save some processing time on the CPU and GPU). Enabling D3D fullscreen exclusive mode also frees up extra resources because the desktop doesn't have to render for a monitor anymore. Another factor is memory and video memory. If either is low because of many open programs Windows may lag as well because of that.

v0lt

1st February 2015, 07:20

JanWillem32, I see a problem in many modes except B-spline. On Bicubic -1.0 distortions are most noticeable.
x86 SSE2 varant A: http://i.imgur.com/Ief3PLys.png (http://i.imgur.com/Ief3PLy.png)
x86 SSE2 varant B: http://i.imgur.com/1oRrpqFs.png (http://i.imgur.com/1oRrpqF.png)

ts1

1st February 2015, 12:20

Difference in size between nearest neighbor/bilinear and all other resizers http://s000.tinyupload.com/index.php?file_id=00943912200448698260 (not this variant A/B builds)

JanWillem32

1st February 2015, 15:29

v0lt, that's too bad. I assume the artifacts are only less visible on the B-spline types because these are rather blurry. Let's try another type of fix.

ts1, that is actually normal. The nearest neighbor and bilinear resizers are implemented using StretchRect() instead of a pixel-shading pass. The vertices for StretchRect() have to be rounded to the nearest integer numbers, but the vertices for a shader pass are real numbers (with the limits of the single precision floating point format). There should never be more than one pixel worth of rounding difference.

v0lt

1st February 2015, 15:54

x86 SSE2 variant C: http://i.imgur.com/6habbpws.png (http://i.imgur.com/6habbpw.png)

madshi

1st February 2015, 16:03

@JanWillem32, double check to make sure your HLSL code is addressing the center of each pixel. I've seen these kind of artifacts in my shaders when my addressing accidently addressed the pixel borders instead of the center. Just a thought, though, could be something completely different...

JanWillem32

1st February 2015, 16:33

This situation sure is weird. On other graphics adapters you get a rift from the top-right to the bottom-left corner if you disable the half-pixel vertex offsets (variant C). (For AMD/ATi drivers you can enable "Alternative Pixel Centers" to counter this effect.) The bottom-right figure in the sample video is supposed to still look relatively normal.
Let's try software vertex processing. I'm not sure that this will make a difference, as all vertices in the renderer are pre-processed anyway.

madshi, did these problems also only happen on Intel graphic adapters for you, too?

v0lt

1st February 2015, 17:09

x86 SSE2 variant D: http://i.imgur.com/8Tvjjgqs.png (http://i.imgur.com/8Tvjjgq.png)
Again, this problem has only two pass interpolation. For example, a single-pass Perlin "Smootherstep" works well.

madshi

1st February 2015, 18:04

I think I had something like this with an AMD GPU, but not with NVidia. I don't remember if I tested with Intel at that time, it was a long time ago. Anyway, as far as I remember, the problem in my case was caused by my HLSL code not properly addressing the center of each source pixel when calling tex2D. I think I addressed the pixel border instead, which resulted in the GPU driver sometimes flipping to the left/top pixel and sometimes to the bottom/right pixel, when using point filtering.

Are you using point sampling, too? Try linear filtering, just as a test to see whether that "fixes" the issue. If it does, then incorrect pixel addressing is the likely cause of the problem.

v0lt

1st February 2015, 19:37

JanWillem32

1st February 2015, 19:40

I can't replicate the issue myself, but I can certainly try to change the offsets in this case. It could be that I mistranslated the resizers from their original DirectX 10 format. (DirectX 10+ vertex formats are different than the types used in earlier versions of the API.)

ts1

1st February 2015, 19:52

Why is that B-spline4 sharper than B-spline6 and even sharper than B-spline8? Shouldn't it be the other way around? And I can't see the difference between Catmull-rom spline4-8 at all. I can see the difference for example between Lanczos2-4.

JanWillem32

1st February 2015, 20:35

B-splines blur a lot, and they blur progressively more over the more samples you feed the kernel. Catmull-Rom splines sharpen slightly more over the more samples you feed the kernel (you can see the difference with the black and white sample posted earlier, for example).
Note that the player also allows plain .BMP files for rendering samples. I've used that function a lot in the past to evaluate resizers and such.

Shiandow

1st February 2015, 20:48

I have converted the bw18x18_rgb.avi (https://yadi.sk/i/g7to4JZid2yqx) (0,255) to grey18x18_rgb.avi (https://yadi.sk/i/W0pQ-H0WePjXx) (64,191) and got the correct result!
http://i.imgur.com/tdbKw6Ws.png (http://i.imgur.com/tdbKw6W.png) :-)

Ah, that seems to be it, for some reason the intermediate result is clamped to values between 0 and 1 which makes the process asymmetric. I can reproduce similar images by doing this manually.

v0lt

2nd February 2015, 16:26

x86 SSE2 variant E: http://i.imgur.com/qi1Ymyus.png (http://i.imgur.com/qi1Ymyu.png)

Ah, that seems to be it, for some reason the intermediate result is clamped to values between 0 and 1 which makes the process asymmetric. I can reproduce similar images by doing this manually.
I also think that this is due to rounding. I see a black screen when I choose float texture on Intel. So I can only select 8-bit textures, it is also used for intermediate results two-pass interpolation.

JanWillem32

2nd February 2015, 18:55

Too bad variant E isn't working either. I'll try some more. Note that 16- and 32-bit textures do work on Intel graphics adapters when using VMR-9 instead of EVR.
About the asymmetry when using 8-bit integer intermediate storage, could AMD and Nvidia possibly be cheating with the intermediate storage type? I've been able to replicate the original asymmetric image from the resizer using the DirectX 9 reference device. (I'll happily share a debug build with those that have access to the D3D debug runtime. Just forgive that it's only working for the 8-bit integer surfaces option and is really slow to initialize.) I'll look forward to the results for testing with the 16- and 32-bit surfaces options. If nothing really seems wrong with the original resizers, I'll just revert the code used for the variant types. I don't mind a minor truncation issue when using the performance mode, as long as the quality mode doesn't suffer from it.

v0lt

2nd February 2015, 19:34

MPC-BE + VMR-9 (renderless):
X8R8G8B8 - ok (bad two-pass interpolation)
A16B16G16R16F - ok (good two-pass interpolation!)
A32B32G32R32F - don't work

mpc-hc SSE2 tester dfr7370rrrrri.7z + VMR-9 (renderless): black screen

JanWillem32

3rd February 2015, 00:10

I replaced the builds and source code in my earlier post.
VMR-9 should work again. (It must have been broken for ages...) Resizing the window while media is loaded should be a bit less jerky than it used to be, but I might be able to optimize it some more later on.

I'll accept the resizing artifacts in the performance mode. We can't set anything better than mere 8-bit integer surfaces for that mode. As long as all quality modes are free of artifacts, I'm fine with this situation.

v0lt

3rd February 2015, 04:09

mpc-hc SSE2 tester dfr7370rrrrri.7z (on February 3) + VMR-9 (renderless):
X8R8G8B8 - ok (bad two-pass interpolation)
A16B16G16R16F - ok (good two-pass interpolation)
A16B16G16R16 - ok (good two-pass interpolation)
A32B32G32R32F - ok (good two-pass interpolation)

I see very contrasting figures on full screen.

JanWillem32

3rd February 2015, 12:03

For "I see very contrasting figures on full screen" what do you mean exactly? For instance; I made basic color correction the default. Images will not look the same in performance mode and quality mode because of that. If you disable the option in the "Renderer Settings", "Color Management" menu, it will revert to a generic BT.709 R'G'B' output. For AMD cards in D3D fullscreen mode with the 10-bit output option enabled colors can be way off. The images will look extremely banded and colorful like a candy store. Just reset the driver and try again if that happens.

ts1

3rd February 2015, 15:26

VMR-9 doesn't work correctly for me. When video shows after 2 seconds of black screen player hangs forever.

JanWillem32

3rd February 2015, 17:24

ts1, those things can happen. Let's try a debug build again. (As usual, do not use these builds as regular types and don't forget to add D3DCompiler_47.dll or D3DCompiler_43.dll.) If a warning occurs, just click on continue, but please do note down what the message box says in addition to the normal log.

ts1

3rd February 2015, 17:39

ASSERT Failed
m_pGeneralVertexBuffer
At line 685 of vmr9allocatorpresenter.cpp

log: http://s000.tinyupload.com/index.php?file_id=67282764943006020139

fagoatse

3rd February 2015, 18:34

v0lt

3rd February 2015, 18:54

For "I see very contrasting figures on full screen" what do you mean exactly?
I do not know whether it is bad or good. I only noticed the difference.
MPC-BE VMR9 Bicubic -1,0: http://i.imgur.com/J3S2Jxi.png
MPC-HC-test VMR-9 float32 Bicubic -1,0: http://i.imgur.com/KCk1abH.png

JanWillem32

3rd February 2015, 23:25

ts1, let's try another debug build. The previous one unfortunately triggered on a useless condition.

fagoatse, the Windows desktop compositor is limited to 8-bit surfaces the last time I checked. Unless something has changed in that regard, there's no influence on the renderer. (D3D fullscreen mode bypasses the desktop compositor, by the way. It is therefore much less restricted to output color depth and frame timing limitations.)

v0lt, that difference is because I implemented rendering in an absolute, linear color system for the renderer. It's a good thing. Look up "gamma correct rendering" for more resources about the basics of the subject, and the XYZ, xyY and LMS color spaces for more advanced information about color theory.

XRyche

4th February 2015, 00:20

JanWillem32, you only had to recently fix the image resizers and not the chroma upsamplers, right? Well the Y'Cb'Cr shaders appear to be working as they should. Even leaving everything at their default original values (sharpening clamps @ 2, detection limits @ 32, and Noisethreshold @ .015625) . Those values use to make everything look like it had a thin curtain draped over it. Now they are actually debanding and denoiseing specific areas in the image and not the whole. Correcting the Image scalers should effect the Y'Cb'Cr shaders like that, should they? Only the chroma up samplers should have an effect on the Y'Cb'Cr' shaders since, to my understanding, chroma is upsampled before the Y'Cb'Cr shaders are even initiated.
I tried them on a media file I know for a fact was heavily denoised and debanded during encoding (to the point of losing some detail, in fact) and the shaders didn't appear to have to do any apparent debanding or denoising at all. Maybe I'm just seeing the difference between using your chroma upsamplers and having to use ffdshows chroma upsamplers.
I haven't a clue, but everything is working great now. In fact, it looks better than I have ever been able to get it to look. I wonder how long the image scalers were knackered for? Thanks for the hard work.

ts1

4th February 2015, 12:11

No any errors now but player still hangs. In EVR when video shows after 2 seconds because of that GetTimingReport() problem, video plays faster for a short period to catch up and VMR-9 just hangs instead (worked fine 2 times, noticed with the last debug build). And did you notice that it calls GetTimingReport() 2 times at 310x200 and played video resolutions. Also I assume that madvr uses this function too (in windowed mode stat screen says "windowed mode (old path)"), but everything works fine there. Btw, crash with madvr in this builds.

JanWillem32

4th February 2015, 23:20

XRyche, all resizers had an update to deal with various issues and to increase efficiency. I'm glad you seem to like it.

ts1, do you have a new debug log, or does it get stuck at the same point in the previous log? The GetTimingReport() issue took a bit of work, but was not too hard to prevent it from failing multiple times (e.g. when resizing). The madVR/Haali renderer issue was a trivial alignment issue, and has been fixed.

ts1

4th February 2015, 23:35

Seems that everything is works now.
Some minor bugs left. Step is bugged with Alternative scheduler, the video sometimes plays for a short period.
Frame disappears after the pause with Alternative scheduler on Vista.

JanWillem32

4th February 2015, 23:48

It's a bit odd that it seems to have fixed the issues VMR-9 r., as I didn't edit it much. I have no idea what was causing the problem. Oh well, as long as it's fixed.
I'll fix frame stepping next. It might be a bit tricky to get it right with the constant frame interpolator, but the alternative scheduler should be capable of it.
The disappearing frame issue is caused by the DWM scheduler of the system. I can't fix that.

ts1

5th February 2015, 00:04

You fixed the GetTimingReport() to prevent it from failing multiple times and it was the cause of desync at the beginning. Apparently VMR-9 is not good at handling desyncs.

XRyche

5th February 2015, 09:28

I have run into a problem. For some reason I can't get your MPC-HC to recognize xy-vsfilter in it's external filters. Weird thing is that it does recognize XySubFilter which is useless for your version of MPC-HC. I'm actually perfectly fine using the internal subtitle renderer but the media player shouldn't have a problem with xy-vsfilter should it?

JanWillem32

5th February 2015, 12:25

I replaced the builds and source code in my earlier post.

ts1, I shaved off a bit more of that timing functions' maximum time to try the automatic mode. (You can also disable it completely by setting something else than 1 for Refresh Rate Adjustment in the "Options", "Output" menu.)
Frame stepping is bugged in the EVR mixer. It actually starts to play, sends the frame step message, and then pauses. The renderer can't compensate for that unfortunately and the alternative scheduler is fast to react to the 'play' message, so it will often handle multiple frames when frame stepping under these conditions.

XRyche, I'll look at xy-vsfilter later. It should indeed not be such a problem.

ts1

6th February 2015, 12:38

If I set something else than 1 for Refresh Rate Adjustment, then it changes frame rate of the playback with Alternative scheduler and D3D Fs + Alternative scheduler.
And DebugView shows memory leak on shutdown:

10.72630787 [3452] EVR: ReleaseServicePointers()
10.72678661 [3452] EVR: Worker thread stopped
10.72700119 [3452] EVR: InitServicePointers()
10.72711945 [3452] EVR: ReleaseServicePointers()
10.81614780 [3452] Detected memory leaks!
10.81620216 [3452] Dumping objects ->
10.81625938 [3452] c:\mpc-hc-rf\src\mpc-hc\mpcpngimage.cpp(104) :
10.81630611 [3452] {1767}
10.81635475 [3452] normal block at 0x00328608, 52 bytes long.
10.81641579 [3452] Data: < t > B4 EB 74 02 00 00 00 00 00 00 00 00 00 00 00 00
10.81646442 [3452] Object dump complete.
Also, regarding frame disappearing after the pause, it only happens after the second pause and onwards, on 1st pause it's always ok.

JanWillem32

6th February 2015, 21:02

ts1, that memory leak is not from my code, but the trunk MPC-HC. I haven't been editing that part of the code.
On a more positive note, I changed some things around and now frame stepping should be more accurate in all modes. I also edited the options and options menu.

XRyche, I just tested xy-vsfilter and I had no issues. Note that the filter enumerates on the "External Filters" tab as DirectVobSubFilter and DirectVobSubFilter (auto-loading version), and you have to add it there before it will activate.

Important note: the automatic refresh rate detection option with the old default setting of "1" will disable the new option.
Tick the new box on the "Options", "Output" tab if you want to remain using the automatic refresh rate detection option. A reset of the renderer settings will also activate the automatic refresh rate detection mode.

kasper93

7th February 2015, 00:04

ts1, that memory leak is not from my code, but the trunk MPC-HC. I haven't been editing that part of the code.

Not the trunk... It has been fixed 8 months ago. Additionaly it was just logo image which was not freed on exit. But still not big deal, because it was only on exit.

XRyche

7th February 2015, 10:26

XRyche, I just tested xy-vsfilter and I had no issues. Note that the filter enumerates on the "External Filters" tab as DirectVobSubFilter and DirectVobSubFilter (auto-loading version), and you have to add it there before it will activate.

Ah, sorry I bothered you for such an obvious thing. I was looking for xy-vsfilter or vsfilter.

ts1

7th February 2015, 14:59

Framestepping is working correctly now, but there are some issues with the slider (time). It moves 2 times slower and doesn't move if the video has been stopped.

JanWillem32

8th February 2015, 16:49

kasper93, the base build I'm using is just old. I should update.

ts1, can you describe it better? Do you mean that during frame stepping the slider doesn't move correctly?
A minor bug with the stop state in combination with EVR CP is known; it may get stuck at the first frame until you re-activate the mixer with a seek or something similar. Did you mean that specific bug?

ts1

8th February 2015, 17:06

Yes during frame stepping and yes that specific bug.

ts1

8th February 2015, 18:09

I think I was wrong it's a different bug cause it happens with VMR 9 and EVR too, and slider still won't move after seek or resize for example, when playback was stopped. And VMR 9 r. hangs after several frame steps, but only if frame stepping used in 1st 5 seconds of playback, nothing useful in DebugView's log (I still have Debug build). Sliders movement speed during frame stepping is correct with EVR and seems correct with VMR 9 r. but not with EVR-CP.

Hera

8th February 2015, 18:14

ts1

8th February 2015, 18:25

Hera, same (and in D3D Fs mode too) but didn't experienced crashes.

Does Frame Interpolator forces Alternative scheduler? Because frame disappears after the pause with Frame Interpolator but without Alternative scheduler.

XRyche

8th February 2015, 21:02

Is non-basic frame interpolator causing artifacts (randomly appearing pure-white pixels around 'sharp' edges) and crashes from time to time (like when resizing) to anyone?
EDIT: Harder to see in video with lots of noise such as film grain - much easier in animation. Just making sure it is not my GPU.

Actually, the "clipping" (randomly appearing pure-white pixels around 'sharp' edges) is what JanWillem32 called it, was happening to me a while back. It was during the initial CEICAM2 shader testing. JanWillem32 actually fixed that for me and it never happened with the XLRCAM shaders. Although the crashing issue never happened with me.

I haven't updated to the latest build that was posted on 2/06/15. I'm still using the 2/02/15 build.

JanWillem32

9th February 2015, 01:26

ts1, I might have solved the stop bug (by adding a seek when stopping). I haven't been able to replicate this bug anymore, so that's a good start.
When the video is in stopped mode the player should not allow any other point on the seek bar than the start. That's normal. Seeking is only available in running or paused modes.
Frame stepping is off for interlaced sources for what I've seen (the mixer will only frame step for every two steps). I can't fix this bug, as it's the mixer's doing. I could not replicate other frame stepping issues. Could you describe exactly how you get the frame stepping and the seek bar to not run at the same speed?
The bug with VMR-9 hanging when frame stepping in the first few seconds is due to the mixer not responding to an information request. I can't fix this bug. (VMR-9 r. actually doesn't have any specific frame-stepping code, it's all inside the mixer.)
As a small side-note, frame-stepping backwards will often take longer than forwards, due to how the decoding works. It might take a second to complete.
The constant frame interpolator will use features of the Alternative scheduler if available.

Hera, interpolation artifacts can happen with complicated filters like the constant frame interpolator. I'll take a look if anything seems out of place later.
I haven't been able to replicate any crashes. In which scenario do you have the crashes (What you are uing in terms of settings, type of video, any subtitles, input frame rate, display refresh rate, and so on.)
We might have to try a new debug build to analyze these crashes.

Hera

9th February 2015, 04:26

32-bit Floating Point Surfaces
Alternative Schedule
9 Dithering
Motion Adaptive, Medium
DXVA Native using LAV filters
Windows 8.1 64-bit / NV 970

Got a crash when resizing window by dragging it to the top with the mouse OR Winkey + UP.
Second crash on exit, not sure if related.

Will see if happens with new build....

Also, when toggling interpolation, video stops then fast forwards trying to catch up.
Also, subtitles are also subject to interpolation from what I can tell - I get white pixel noise around subtitles.
Also, is it me or are subtitles now rendered to the size of the video and not desktop?

ts1

9th February 2015, 07:20

Nevermind, slider still doesn't move after the stop but it's the same in the trunk build.

Could you describe exactly how you get the frame stepping and the seek bar to not run at the same speed?
On a short (3-10s) video I used frame stepping from the beginning, video already ended and slider was right in the middle.

XRyche

9th February 2015, 21:28

Nevermind, slider still doesn't move after the stop but it's the same in the trunk build.

On a short (3-10s) video I used frame stepping from the beginning, video already ended and slider was right in the middle.

This isn't happening to me on the latest 64 bit build. It was an issue back when was I was using Vista 32 bit though.

JanWillem32

10th February 2015, 10:06

Hera, I still haven't been able to replicate any crashes related to the constant frame interpolator. I've added another debug build to try to debug this issue.
When toggling the constant frame interpolator on, multiple shaders have to be compiled. That takes some time. The renderer will try to catch up with the global timer to synchronize again after that.
Subtitles are indeed blended before frame interpolation passes are executed. I still haven't thought out a way to move the frame interpolation passes to another stage.
Subtitles can be renderered at video area size or full window size, see the "Options", Subtitles" tab for the option.

ts1, I've replicated the slow frame stepping issue. It's not caused by the renderer code, but by the external mixer counting the frame numbers up to a too low amount. I can't fix this issue. Luckily, it only affects the seek bar, and nothing playback related.

x86 SSE2 debug: http://www.mediafire.com/download/4690xb2p7nhvevd/mpc-hc_SSE2_tester_dfr7370rrrrri_debug.7z

ts1

10th February 2015, 18:46

Too many resets during window resize. Resize is slow because of this. Is it intentional?

JanWillem32

10th February 2015, 19:02

The resets are actually quite limited. I set a maximum of twice per second. The default was checking every frame for changed settings, window size and some other environment changes.

ts1

10th February 2015, 19:39

Is it Alternative scheduler's limitation? Can it be done without resets, so that resize would be smooth as in the trunk mpc-hc?

JanWillem32

11th February 2015, 07:35

The renderer in the trunk build is a pile of garbage. Even in this regard it does everything wrong. It doesn't set up a presentation queue, but rater a copy-to-desktop swap chain at the the monitor resolution it first initializes at. (You can move the player window over to another monitor with a higher resolution and see how buggy such a setup is.) I've always simply used correctly window-sized presentation swap chains that actually allow proper queuing. This does mean that you have to reset window size-dependent stuff with every resize, but that's just the way it is. DirectX 9 is slightly problematic in this regard as well, as it can't reset as fast as DirectX 10+ due to API limitations.
In many other cases I've also chosen to use the optimal efficiency during rendering, even if these optimizations require resets of some parts of the renderer.

I found a resizing bug that could cause crashes. This is probably the one Hera described earlier. I also optimized (re-)initialization for the renderer.

regular builds (just small updates this time):
x64: http://www.mediafire.com/download/0s9zceobckg496t/mpc-hc64_tester_dfr7370rrrrri.7z
x86 SSE2: http://www.mediafire.com/download/j7nv8jir4ahfg85/mpc-hc_SSE2_tester_dfr7370rrrrri.7z
x86 SSE: http://www.mediafire.com/download/5p2rdk7ll6ng3ve/mpc-hc_SSE_tester_dfr7370rrrrri.7z
source code: http://www.mediafire.com/download/x6xvnc5ty79exr3/mpc-hc_tester_dfr7370rrrrri_source_code.7z

ts1

11th February 2015, 10:43

Noise with Frame Interpolator that has been mentioned earlier http://imgur.com/mZ84Yrw

Overall it works pretty well, only those bugs with the mixer are annoying.

v0lt

14th February 2015, 14:29

@JanWillem32
Why EVR-custom can not use float texture on Intel graphics cards? Is it possible to fix it?
The problem occurs in MPC-HC and MPC-BE.

JanWillem32

14th February 2015, 19:48

ts1, these seem like reasonable interpolation artifacts. They result from the movement direction estimation faulting in a certain area and cause the pixel interpolation to be off.
I do agree that the mixer bugs are annoying. A custom mixer however would come at the cost of the maximum efficiency of the mixer pipeline in some stages. There is no ideal solution for handling the mixers.

v0lt, Intel chose a fixed-function unit to do mixing for EVR. This unit does not support anything but 8-bit R'G'B' outputs. VMR-9 r. does work with 16- and 32-bit floating-point textures (but it needs some special settings to actually return floating-point quality from the mixer).

XRyche

15th February 2015, 00:08

What is the lowest NoiseThreshold value for general debanding, not denoising for your Vertical/Horizontal pass sharpen complex, deband and denoising shaders? The NoiseThreshold value of .015625 is pretty close to perfect for my denoising needs but it's way too aggressive for general debanding. Just a suggested value is good enough for me. I'll work from your suggestion to find the value that best suits my individual tastes. I really don't want to mess with the SharpenLimits or the Detection Values.

JanWillem32

15th February 2015, 06:19

XRyche

15th February 2015, 15:54

Banding, static, encoder and grainy noise are all just noise to the analyzing step of that particular shader. It doesn't "see" any difference when debanding and denoising. For the "NoiseThreshold" value I personally use .0078125 . Note that you can set the values of the four stages for "NoiseThreshold" in the body of that shader to different amounts. The inner (upper) value is the most important for denoising, and somewhat for debanding, and the outer (lower) value is mostly important for debanding, and not so much for denoising.

Could you give me an exert from the script of the locations of the four stages and the upper and lower values? I think i might have an idea of where they are but I'm not confident at all. Like I've said before " I know just enough to be dangerous but not enough to be competent."

JanWillem32

15th February 2015, 18:30

I optimized these shaders and have given them multi-stage controls over the noise thresholds. Note that I can still expand the search area beyond the current 9 horizontal and vertical pixels if you wish (though I doubt the effect would gain much from that).
Use the renderer option "Disable Initial Color Mixing Stages" and set up these shaders as follows:
1- R'G'B' to Y'CbCr for LMS rendering
2- if required (on Intel/AMD graphics adapters), an up-sampling shader for 4:2:0 to 4:2:2
3- if required (on Intel/AMD graphics adapters), an up-sampling shader for 4:2:2 to 4:4:4
4- horizontal pass sharpen complex, deband and denoise for LMS rendering
5- vertical pass sharpen complex, deband and denoise, and color conversion to LMS for LMS rendering// (C) 2015 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.

// R'G'B' to Y'CbCr for LMS rendering
// This shader should be run as the very first pixel shader in the chain.
// 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.

#ifndef Ml// external compiler
#define Ml 0
#define Mi 0
#define Mr 0
#endif
#if Ml
#define tex2D(s, t) tex2Dlod(s, float4(t, 0., 0.))
#endif
sampler s0 : register(s0);
static const float3x3 mty = float3x3(
#if Mi == 0
.2126, -1063./9278., .5, .7152, -1788./4639., -1788./3937., .0722, .5, -361./7874.// BT.709 (+BT.2020) R'G'B' to Y'CbCr
#elif Mi == 1
.299, -299./1772., .5, .587, -587./1772., -587./1402., .114, .5, -57./701.// BT.601 (+BT.2020) R'G'B' to Y'CbCr
#else
.212, -106./913., .5, .701, -701./1576., -701./1576., .087, .5, -87./1576.// SMPTE 240M R'G'B' to Y'CbCr
#endif
)
#if Mr
*32767./65535.// convert to alternative limited ranges, first part
#endif
;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 s1 = tex2D(s0, tex).rgb;// original pixel
s1 = s1.r*mty[0]+s1.g*mty[1]+s1.b*mty[2];// convert to Y'CbCr
#if Mr
s1 += float2(16384./65535., 32767./65535.).xyy;// convert to alternative limited ranges, second part
#endif
return s1.rgbb;
}// (C) 2015 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.

// horizontal pass sharpen complex, deband and denoise for LMS rendering
// This shader should be run as a Y'CbCr-stage pixel shader.
// This shader requires compiling with ps_3_0, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.

// fractions, either decimal or not, are allowed
#define SharpenLimitLuma 2// valid interval [0, 10], luma-specific sharpening limit, 0 is disabled, lower numbers will allow more sharpening on contours
#define SharpenLimitChroma 2// valid interval [0, 10], chroma-specific sharpening limit, 0 is disabled, lower numbers will allow more sharpening on contours
#define LumaDetectionFactor 64// valid interval (1, 250], luma-specific detection factor, if set to the lowest amount no contours can be detected, higher numbers will shift the detection on color difference intervals of debanding to noise detection limit to mimimum sharpening to maximum sharpening toward more sharpening
#define ChromaDetectionFactor 64// valid interval (1, 250], chroma-specific detection factor, if set to the lowest amount no contours can be detected, higher numbers will shift the detection on color difference intervals of debanding to noise detection limit to mimimum sharpening to maximum sharpening toward more sharpening
// valid intervals [0, 1), banding treshold, higher numbers mean stronger deband and denoise
#define NoiseThreshold1 .015625// innermost threshold, mostly affects denoising
#define NoiseThreshold2 .015625
#define NoiseThreshold3 .015625
#define NoiseThreshold4 .015625// outermost threshold, mostly affects debanding area

#ifndef Ml// external compiler
#define Mr 0
#endif
sampler s0 : register(s0);
float2 c1 : register(c1);
#define sp(a) tex2Dlod(s0, float4(tex+c1*float2(a, 0), 0, 0)).rgb
static const float3 slimits = float3(-SharpenLimitLuma, -SharpenLimitChroma, -SharpenLimitChroma);
static const float3 dfactors = float3(LumaDetectionFactor, ChromaDetectionFactor, ChromaDetectionFactor)*(32768./32767.*float(Mr)+1.);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 n, p, s1 = sp(0);// original pixel
{
float3 s2 = sp(-1);
float3 af = 1.;// accumulated amount of colors from the samples
float3 ac = s1;// accumulate color
float3 cd = abs(s1-s2);// color difference
float3 rcd = max(slimits, 1.-dfactors*cd);// factor for both base and multiplicand is 1.0, the output will be in the interval (-inf, 1]
// invert interval on sharpening
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s2*rcd;
[branch] if(!any(cd >= NoiseThreshold1*(1.-32768./65535.*float(Mr)))) {// continue if all channels are below the noise threshold
float3 s3 = sp(-2);
cd = abs(s1-s3);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s3*rcd;
[branch] if(!any(cd >= NoiseThreshold2*(1.-32768./65535.*float(Mr)))) {
float3 s4 = sp(-3);
cd = abs(s1-s4);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s4*rcd;
[branch] if(!any(cd >= NoiseThreshold3*(1.-32768./65535.*float(Mr)))) {
float3 s5 = sp(-4);
cd = abs(s1-s5);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s5*rcd;
[branch] if(!any(cd >= NoiseThreshold4*(1.-32768./65535.*float(Mr)))) {
float3 s6 = sp(-5);
cd = abs(s1-s6);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s6*rcd;
}
}
}
}
n = ac/af;
}
{
float3 s2 = sp(1);
float3 af = 1.;// accumulated amount of colors from the samples
float3 ac = s1;// accumulate color
float3 cd = abs(s1-s2);// color difference
float3 rcd = max(slimits, 1.-dfactors*cd);// factor for both base and multiplicand is 1.0, the output will be in the interval (-inf, 1]
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s2*rcd;
[branch] if(!any(cd >= NoiseThreshold1*(1.-32768./65535.*float(Mr)))) {// continue if all channels are below the noise threshold
float3 s3 = sp(2);
cd = abs(s1-s3);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s3*rcd;
[branch] if(!any(cd >= NoiseThreshold2*(1.-32768./65535.*float(Mr)))) {
float3 s4 = sp(3);
cd = abs(s1-s4);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s4*rcd;
[branch] if(!any(cd >= NoiseThreshold3*(1.-32768./65535.*float(Mr)))) {
float3 s5 = sp(4);
cd = abs(s1-s5);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s5*rcd;
[branch] if(!any(cd >= NoiseThreshold4*(1.-32768./65535.*float(Mr)))) {
float3 s6 = sp(5);
cd = abs(s1-s6);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s6*rcd;
}
}
}
}
p = ac/af;
}
return ((n+p)*.5).rgbb;
}

JanWillem32

15th February 2015, 18:30

// (C) 2015 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.

// vertical pass sharpen complex, deband and denoise, and color conversion to LMS for LMS rendering
// This shader should be run as a Y'CbCr-stage pixel shader.
// This shader requires compiling with ps_3_0, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.

// fractions, either decimal or not, are allowed
#define SharpenLimitLuma 2// valid interval [0, 10], luma-specific sharpening limit, 0 is disabled, lower numbers will allow more sharpening on contours
#define SharpenLimitChroma 2// valid interval [0, 10], chroma-specific sharpening limit, 0 is disabled, lower numbers will allow more sharpening on contours
#define LumaDetectionFactor 64// valid interval (1, 250], luma-specific detection factor, if set to the lowest amount no contours can be detected, higher numbers will shift the detection on color difference intervals of debanding to noise detection limit to mimimum sharpening to maximum sharpening toward more sharpening
#define ChromaDetectionFactor 64// valid interval (1, 250], chroma-specific detection factor, if set to the lowest amount no contours can be detected, higher numbers will shift the detection on color difference intervals of debanding to noise detection limit to mimimum sharpening to maximum sharpening toward more sharpening
// valid intervals [0, 1), banding treshold, higher numbers mean stronger deband and denoise
#define NoiseThreshold1 .015625// innermost threshold, mostly affects denoising
#define NoiseThreshold2 .015625
#define NoiseThreshold3 .015625
#define NoiseThreshold4 .015625// outermost threshold, mostly affects debanding area

#ifndef Ml// external compiler
#define Mr 0
#define Mp 0
#define Mi 0
#endif
sampler s0 : register(s0);
float2 c1 : register(c1);
#define sp(a) tex2Dlod(s0, float4(tex+c1*float2(0, a), 0, 0)).rgb
static const float3 slimits = float3(-SharpenLimitLuma, -SharpenLimitChroma, -SharpenLimitChroma);
static const float3 dfactors = float3(LumaDetectionFactor, ChromaDetectionFactor, ChromaDetectionFactor)*(32768./32767.*float(Mr)+1.);
static const float3x3 mat = transpose(float3x3(
#if Mp == 0
722868859153469683239595115393861./2255010826531620584211453297294600., 2585192674261804536498018473512337./4059019487756917051580615935130280., 431657167547167713128315634772483./10147548719392292628951539837825700., 12180008436477856247752895389891./75167027551054019473715109909820., 307102197566215335489903665465341./405901948775691705158061593513028., 82569264131239864825730732355689./1014754871939229262895153983782570., 53058419719444384066923671296./3075014763452209887561072678129., 111365697442061984458791034130./1025004921150736629187024226043., 2687859251406579550117775904443./3075014763452209887561072678129.// BT.709 (+BT.2020) RGB to Kuo, Zeise & Lai-modified Hunt–Pointer–Estévez LMS
#elif Mp == 1
782910914364235953227073443841197./2505869460647788817876743483379180., 47437201892727083793508359035427793./75176083819433664536302304501375400., 4251554495779502145981742150711697./75176083819433664536302304501375400., 124459316400474051550350235432343./751760838194336645363023045013754., 5551656166817314597571817932574949./7517608381943366453630230450137540., 240453017040437113518303387746387./2505869460647788817876743483379180., 190503071007861562472684780870./11390315730217221899439743106269., 3484707111371743136520220253336./34170947190651665698319229318807., 30114730866256337874380954722861./34170947190651665698319229318807.// BT.470-2 System B,G/EBU 3213 (PAL/SECAM) (+BT.2020) RGB to Kuo, Zeise & Lai-modified Hunt–Pointer–Estévez LMS
#elif Mp == 2
4849241781348846485632006241./10503846560761984531342857600., 34978470582276588065997919961./73526925925333891719400003200., 35966897450120142609203434./574429108791671029057812525., 1160596510009705046375091833./5251923280380992265671428800., 24013221393818167547899894193./36763462962666945859700001600., 72282281230950671674601009./574429108791671029057812525., -76116568237764117836011./65649041004762403320892860., 25082445529946839408599149./459543287033336823246250020., 108748414370263583165625737./114885821758334205811562505.// BT.470-2 System M RGB to Kuo, Zeise & Lai-modified Hunt–Pointer–Estévez LMS
#else
4582795022958559125948622834369921./13693077790023334631838222431764800., 465527727195754310063646435959647./746895152183090979918448496278080., 431705826356959866042061203601013./10269808342517500973878666823823600., 77217992358463681223124506539751./456435926334111154394607414392160., 56048129428711216246386203396963./74689515218309097991844849627808., 82578571800427591248026245959679./1026980834251750097387866682382360., 42047021865948932675414158432./2334047350572159312245151550869., 1103514589028385241176926280029./9336189402288637248980606203476., 2688162241932152092367341096573./3112063134096212416326868734492.// SMPTE 170M/SMPTE 240M/SMPTE C (NTSC) (+BT.2020) RGB to Kuo, Zeise & Lai-modified Hunt–Pointer–Estévez LMS
#endif
)
#if Mr
*32767./65535.// convert to limited ranges, first part
#endif
);
static const float2x3 mtr = float2x3(
#if Mi == 0
0., -1674679./8940000., 1.8556, 1.5748, -4185031./8940000., 0.// BT.709 (+BT.2020) Y'CbCr to R'G'B'
#elif Mi == 1
0., -25251./73375., 1.772, 1.402, -209599./293500., 0.// BT.601 (+BT.2020) Y'CbCr to R'G'B'
#else
0., -79431./350500., 1.826, 1.576, -41764./87625., 0.// SMPTE 240M Y'CbCr to R'G'B'
#endif
)
#if Mr
*65535./32767.// restore to full range, first part
#endif
;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 n, p, s1 = sp(0);// original pixel
{
float3 s2 = sp(-1);
float3 af = 1.;// accumulated amount of colors from the samples
float3 ac = s1;// accumulate color
float3 cd = abs(s1-s2);// color difference
float3 rcd = max(slimits, 1.-dfactors*cd);// factor for both base and multiplicand is 1.0, the output will be in the interval (-inf, 1]
// invert interval on sharpening
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s2*rcd;
[branch] if(!any(cd >= NoiseThreshold1*(1.-32768./65535.*float(Mr)))) {// continue if all channels are below the noise threshold
float3 s3 = sp(-2);
cd = abs(s1-s3);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s3*rcd;
[branch] if(!any(cd >= NoiseThreshold2*(1.-32768./65535.*float(Mr)))) {
float3 s4 = sp(-3);
cd = abs(s1-s4);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s4*rcd;
[branch] if(!any(cd >= NoiseThreshold3*(1.-32768./65535.*float(Mr)))) {
float3 s5 = sp(-4);
cd = abs(s1-s5);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s5*rcd;
[branch] if(!any(cd >= NoiseThreshold4*(1.-32768./65535.*float(Mr)))) {
float3 s6 = sp(-5);
cd = abs(s1-s6);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s6*rcd;
}
}
}
}
n = ac/af;
}
{
float3 s2 = sp(1);
float3 af = 1.;// accumulated amount of colors from the samples
float3 ac = s1;// accumulate color
float3 cd = abs(s1-s2);// color difference
float3 rcd = max(slimits, 1.-dfactors*cd);// factor for both base and multiplicand is 1.0, the output will be in the interval (-inf, 1]
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s2*rcd;
[branch] if(!any(cd >= NoiseThreshold1*(1.-32768./65535.*float(Mr)))) {// continue if all channels are below the noise threshold
float3 s3 = sp(2);
cd = abs(s1-s3);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s3*rcd;
[branch] if(!any(cd >= NoiseThreshold2*(1.-32768./65535.*float(Mr)))) {
float3 s4 = sp(3);
cd = abs(s1-s4);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s4*rcd;
[branch] if(!any(cd >= NoiseThreshold3*(1.-32768./65535.*float(Mr)))) {
float3 s5 = sp(4);
cd = abs(s1-s5);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s5*rcd;
[branch] if(!any(cd >= NoiseThreshold4*(1.-32768./65535.*float(Mr)))) {
float3 s6 = sp(5);
cd = abs(s1-s6);
rcd = max(slimits, 1.-dfactors*cd);
if(rcd.x < 0) rcd.x = SharpenLimitLuma-abs(rcd.x);
if(rcd.y < 0) rcd.y = SharpenLimitChroma-abs(rcd.y);
if(rcd.z < 0) rcd.z = SharpenLimitChroma-abs(rcd.z);
af += abs(rcd);
ac += s6*rcd;
}
}
}
}
p = ac/af;
}
s1 = (n+p)*.5;
#if Mr
s1 -= float2(16384./65535., 4294737923./8589672450.).xyy;// restore to full range, second part
s1 = s1.r*65535./32767.+s1.g*mtr[0]+s1.b*mtr[1];// restore Y' to full range, convert to R'G'B'
#else
s1 = s1.r+s1.g*mtr[0]+s1.b*mtr[1];// convert to R'G'B'
#endif
s1 = sign(s1)*pow(abs(s1), 2.4);// to linear RGB, negative input compatible
s1 = s1.r*mat[0]+s1.g*mat[1]+s1.b*mat[2];// convert to Kuo, Zeise & Lai-modified Hunt–Pointer–Estévez LMS
#if Mr
s1 += 16384./65535.;// convert to limited ranges, second part
#endif
return s1.rgbb;
}

XRyche

15th February 2015, 20:52

I'm going to assume that your integrated Chroma Upsampling Fix for Intel/AMD on this renderer is sufficient and someone would need the additional upsampling shaders for another renderer.

I'm just curious, but what made you change the LumaDetectionFactors?

Oh, they work like a charm. Much, much better than the previous shader suite. They do the same thing for the most part, but are easier to control and understand for your average person that doesn't know too much about HLSL and/or video in general. Thank you very much.

JanWillem32

15th February 2015, 21:29

I'm going to assume that your integrated Chroma Upsampling Fix for Intel/AMD on this renderer is sufficient and someone would need the additional upsampling shaders for another renderer.If you disable the renderer's initial mixing stages, the renderer's chroma up-sampling and color conversion steps will be disabled. You have to replace them with custom shaders.I'm just curious, but what made you change the LumaDetectionFactors?The original value was for the [16384./65535., 49151/65535.] interval data, but the new ones are for [0, 1] interval data (with automatic adaptation if required). That's why the new values are double the original value.Oh, they work like a charm. Much, much better than the previous shader suite. They do the same thing for the most part, but are easier to control and understand for your average person that doesn't know too much about HLSL and/or video in general. Thank you very much.I try my best. If you need anything else, please ask away. Minor modifications of old shaders are easy. Only brand new effects can take a while.

XRyche

15th February 2015, 22:22

If you disable the renderer's initial mixing stages, the renderer's chroma up-sampling and color conversion steps will be disabled. You have to replace them with custom shaders.

That explains a lot for me. Ever since I switched to AMD from Nvidia I haven't seen a significant change. This is why. I thought I was just a victim of the placebo effect.

The only chroma upsampling shaders I have are from your "Video shader pack 1.4" which dosen't have any of the more recent upsampling shaders you use in your renderer. Could I ask you to make those available. If that's too much of a daunting task just the Lanzcos shaders would be sufficient.

The original value was for the [16384./65535., 49151/65535.] interval data, but the new ones are for [0, 1] interval data (with automatic adaptation if required). That's why the new values are double the original value.I try my best. If you need anything else, please ask away. Minor modifications of old shaders are easy. Only brand new effects can take a while.

I was just curious as to why. There wasn't any motive behind wanting to know except for curiosity :) .

JanWillem32

16th February 2015, 16:35

http://www.mediafire.com/download/m7td27lofk6dyi1/YCbCr-type_sharpen_complex_test_3.7z
Just a reminder; these are renderer-specific shaders for the quality mode. This package includes the three shaders listed above for "sharpen complex, deband and denoise for LMS rendering" and also all current chroma up-sampling shaders.
The readme.txt file contains information about how to chain shaders for different renderer conditions.
The chroma up-sampling shaders are literally copies from the internal shaders. I didn't test them separately, so please inform me if anything is wrong with them.

XRyche

16th February 2015, 17:24

Thank You. I'll test these when I get home and let you know. I did find the Y'Cb'Cr test 2 after i wrote the previous post. I used the chroma upsampling shaders last nite. They appeared to work fine and I could see the difference. I like my chroma more defined and sharp though that's why I asked for the Lanczos variants.

XRyche

17th February 2015, 00:17

foxyshadis

18th February 2015, 11:55

Jan, I have a question about shader chains. Is it possible to do your favorite processing like deband, resize, etc, then upsample the temporal resolution to the monitor rate, then apply a bit of noise to every frame? I think this is possible in MPDN, but I'd like to know if it can be done in MPC-HC as well. This way the illusion of constant movement can trick the eye into ignoring those too-smooth areas in low-bitrate encodes, or where denoising was applied too heavily.

I remember there was a discussion about changing frame rates in the shaders, but I can't remember what the result was.

JanWillem32

18th February 2015, 19:19

Changing frame rates in shaders isn't possible. The host renderer calls Present()/PresentEx() for every renderered frame to present to the back buffer. Hence it's the host renderer that needs to set up frame rate changes. I implemented the constant frame interpolator a while ago. It always changes the video frame rate to the display refresh rate through either basic (spline fit) or adaptive (motion vectorization and transformation) interpolation methods. Because of the complexity of changing frame rates and the extra textures and transforms this function uses, I'm not planning custom shader support for these stages. (Note that the fourth adaptive interpolation shader is the most complex shader I've ever used.)
Adding various types of (dithering) noise is implemented as well. Static ordered dithering won't change patterns for each frame, but the random ordered and random dither types will.
The options are available in the "View", "Renderer Settings", "Frame Interpolator (PS 3.0)" and "Dithering Levels" menus.

Anima123

19th February 2015, 06:24

I am new user here with this tester build. Can someone enlighten me why the video looks 'greyed out', is there some kind of guide or how-to for the basic/advanced configurations?

For an example, I don't know how to trigger on the frame interpolotor.

burfadel

19th February 2015, 07:00

http://www.mediafire.com/download/m7td27lofk6dyi1/YCbCr-type_sharpen_complex_test_3.7z
please inform me if anything is wrong with them.

When using with MPC-HC (renaming them to .hlsl), they don't work properly when using with madVR. It doesn't matter what the settings are in madVR, the picture ends up being very dark and it looks like the levels are off. If the renderer is changed to EVR (for example), and the video reloaded to use the different renderer, it plays correctly.

This is with trying both the single and mutli-pass methods. All other shaders I use work fine with madVR. I did remove those from the shader list, and that did not help.

I'm using madVR v0.87.14, LAVFilters 0.64.0 (the one that comes with the latest MPC-HC nightly), and MPC-HC nightly 1.7.8.61. Windows 8.1 x64, R9-280X video card, Catalyst 14.12.

ts1

19th February 2015, 07:19

Anima123
Make sure you use Enhanced Video Rendere (Custom presenter). Then in the View -> Renderer Settings -> Presentation enable Alternative Scheduler and choose 16/32-bit floating point surface and then you can use frame interpolator, dithering, color management from the View -> Renderer Settings.

JanWillem32

19th February 2015, 09:06

Anima123, I certainly advise using the quality mode with the 16- or 32-bit options (try 16-bit integer first, it usually works). The performance mode (the default) is indeed not the nicest looking. After some color correction or color management (available as renderer options) things should look a lot better.

burfadel, these are renderer-specific shaders. I probably should have stated that inside the readme of that package, but I did make it clear in my earlier post. I included the color conversion steps of the internal renderer shaders. The ones used by madVR are different, hence the incompatibility.

foxyshadis

19th February 2015, 10:08

Changing frame rates in shaders isn't possible. .... I'm not planning custom shader support for these stages.

Thanks, I won't worry about it then. The dither setting was too weak for the effect I was looking for, but if it's a pain in the ass, it's no big deal.

burfadel

19th February 2015, 11:57

burfadel, these are renderer-specific shaders. I probably should have stated that inside the readme of that package, but I did make it clear in my earlier post. I included the color conversion steps of the internal renderer shaders. The ones used by madVR are different, hence the incompatibility.

Ah okay, my mistake :D.

Is it possible to make a version compatible with madVR, seeing as it is a commonly used and favoured renderer by many?

JanWillem32

19th February 2015, 16:24

foxyshadis, I don't mind adding stronger random dither, or if you want, another type of dither. How much stronger do you need it compared to the current types?

burfadel, I'll take a look at it. The lack of compiler macros will mean manual switching for HD and SD types though.

JanWillem32

19th February 2015, 20:11

Today I finished probably the most part of the new constant frame interpolator. Its methods are pretty much the same as the old version, but the stage has changed to pre-resize, making it less interfering with subtitles, stats screen and OSD.
As per usual, please test and report if anything seems to be off regarding this version.

regular builds (major updates this time):
-

Anima123

19th February 2015, 23:38

I tried your interpolator (not the latest version) last night, it was acceptable when the scenes are continuous, with big scene changes, however, the effect was not so pleasant. In wonder if the algorithm can detect scene change and choose other way to handle the case?

JanWillem32

19th February 2015, 23:48

Which of the three modes were you using? The basic version will have lightening/darkening artifacts when colors change. The adaptive modes will fall back to linear interpolation if the surrounding image drastically changes.

Anima123

20th February 2015, 03:53

I am trying your new build, with correct settings, it works well so far.

Still, even with adaptive mode, in case of scene changes, some noticeable artifacts can be annoying.

Edit: I tried to using the interpolator with VMR 9 renderless, it always crash when trying to get into fullscreen.

Hera

21st February 2015, 07:18

I like this new build so far.

XRyche

21st February 2015, 22:22

foxyshadis, I don't mind adding stronger random dither, or if you want, another type of dither. How much stronger do you need it compared to the current types?

I actually would like to try out some stronger random dithering and/or another type of dithering as well. Since I have a 6 bit TN LCD monitor it might be an improvement.

On an unrelated topic, does the integrated colour management still use CIECAM2 or did you update it to XLRCAM?

Hera

22nd February 2015, 05:15

Still, sometimes, getting black screen on ALT-ENTER

v0lt

22nd February 2015, 09:44

v0lt, Intel chose a fixed-function unit to do mixing for EVR. This unit does not support anything but 8-bit R'G'B' outputs.I use 8-bit for EVR buffers and custom type for shader surfaces. This is only for EVR-custom and Intel.
https://sourceforge.net/p/mpcbe/code/157/

VMR-9 r. does work with 16- and 32-bit floating-point textures (but it needs some special settings to actually return floating-point quality from the mixer).
Which settings do you mean?

JanWillem32

24th February 2015, 23:12

Anima123, I'll take a look at VMR-9 r. again, thank you for notifying me.

Hera, I'll revise the window handling code. Maybe it will work out. It's a bit difficult to get the correct window on top with how the main window handler is organized for windowed fullscreen. D3D fullscreen doesn't have such problems due to a different window order.

v0lt, you're probably right about this patch. It's just a bit dishonest to force 8-bit output textures on the mixer while the user selected a quality option though. I'll have to think about this issue some more, especially since future video adapter drivers could possibly fix this issue. (VMR-9 doesn't have this issue for instance, so EVR shouldn't either with maybe some other settings in the driver.)

XRyche, I've been using XLRCAM exclusively for a while now. It works without much problems and solves some issues I had with CIECAM02.
Here are some extra random noise generators based on XLRCAM (will be included in future builds).

foxyshadis, If you didn't like the type of noise of the built-in dithering (instead of just wanting a stronger effect from it), these might be interesting for you as well.

The two shaders are too long to post here, so I've uploaded them in archived form this time.
-

XRyche

25th February 2015, 01:17

I'm still getting weird colour distortions With the new XLRCAM shaders when used in conjunction with Little CMS and using the shaders colour controls . Here's a screen shot : https://www.mediafire.com/?2c28ewtb9u580r6 . You can see the heavy distortions on the light panels in the background.

foxyshadis

25th February 2015, 11:33

Boy, you sure weren't kidding when you said stronger, now it's drowning in grain. It's interesting though, and it's fast as hell, so I'll play with the strength and find something I like.

There's a weird 15x15 artifact though, where vertical and horizontal correlations seem to create blocks out of the noise. It's very obvious in motion.
https://dl.dropboxusercontent.com/u/54412753/doom9/15x15grain.png

This is on HD 4600 (with Optimus, but I don't think that's used), with default settings on a white background.

ts1

26th February 2015, 09:32

Resize of the player is slow with Adaptive Frame Intepolator, but it's ~2 times faster on 64-bit built.

JanWillem32

27th February 2015, 22:02

v0lt, sorry I didn't answer your post completely last time. The settings needed for VMR-9 are for its mixer output textures. You should never use the texture allocator provided by the mixer, but just use your own methods, else it always allocates 8-bit R'G'B' textures.

XRyche, which shader are you using and whith what settings? Are the artifacts only on blue pixels?

foxyshadis, the internal renderer ditherer can also be made stronger, it just alters monitor-type R'G'B' instead of L'M'S', the correlates for red–green and yellow–blue, and the achromatic response. Whichever you prefer can be made to suit your needs. Don't forget to try both noise modes offered by the two new shaders.
I can't really see that 15x15 specific artifact though. It could be artifacts in the WTW of that white video. It could also be just a too low run count (though I was pretty sure 3 was enough when I last tested it).
To change the run count, alter the "3" in the shader's line: "do {rd(w) rd(z) rd(y) rd(x)} while(++i < 3);// randomize, a low run count will make patterned noise" . That might solve that problem.

ts1, there's a good chance that the external pixel shader compiler (which is used to compile a large set of shaders for the constant frame interpolator) is more optimized on x64, hence the re-initialization speed difference. The difference for debug modes for when testing subtitles is even more dramatic, by the way.

XRyche

27th February 2015, 23:38

XRyche, which shader are you using and whith what settings? Are the artifacts only on blue pixels?

I'm using the latest XLRCAM shaders you posted with everything left as is except two settings. I've set "NoiseMode" to 0 and set all 3 primaries in ScaleLinearLight to 1.26. Any value of 1.25 or less doesn't create that effect. I know the value is rather high but it still shouldn't be producing these results, should it?

As far as what colour pixels the artifacts are manifesting with, they are indeed only blue. Here's another screenshot where the artifacts are even more prevalent : http://www.mediafire.com/view/gl423rn4wbbx2p2/Untitled2.png . It's very apparent on the descending compound screen on the upper-right of Sting and the lower-right of him on the curtains.

JanWillem32

28th February 2015, 17:11

I've revised the color scaling controls for the linear L'M'S' stage and added a gamma control: - . These might be what you're looking for. I decreased the likelihood of any black (or dark color) clipping artifacts. White (or light color) clipping is still present on all controls, except the gamma controls.

XRyche

28th February 2015, 19:03

That worked as far as eliminating the dark artifacts. The colour scaling controls for L'M'S' seem a bit subdued compared to what they were. Everything seems, for lack of a better word, "whiter". The colour gamma controls are interesting. Very "touchy" but I might like them as long as I don't abuse them. Thanks for optimizing the colour controls for me.

JanWillem32

1st March 2015, 23:42

I just replaced the mpc-hc tester dfr7370rs6i builds to (possibly) solve the fullscreen bug reported by Hera and a bug that could pause the visuals on EVR-CP. These packages contain the new shaders as well (but with updated comments).

XRyche

3rd March 2015, 23:32

The Lanczos 2 and 3 chroma upsampling shaders are failing with the new build. Those two appear to be the only ones.

JanWillem32

4th March 2015, 00:34

Thank you for notifying me.
I replaced the builds linked in my previous post. Also, as these four shaders were in the "YCbCr-type sharpen complex test 3" package, I replaced that one as well. http://www.mediafire.com/download/m7td27lofk6dyi1/YCbCr-type_sharpen_complex_test_3.7z

XRyche

4th March 2015, 01:11

They still won't work. I'm getting this error "error X3014: incorrect number of arguments to numeric-type constructor" when I try to compile them in the shader editor.

JanWillem32

4th March 2015, 02:30

You're right indeed (for Lanczos3, not Lanczos2). I replaced the four files again.

XRyche

4th March 2015, 04:56

My Bad :P . I just checked Lanczos3 and ass-u-me d Lanczos2 was still off. Everything is working as it should, for me anyways, again.

ts1

4th March 2015, 22:36

Black screen with dvr-ms files. After trying to reopen the file appears error "failed to register the renderer utility window class".
http://www.filedropper.com/jewelsofcaribbean

JanWillem32

6th March 2015, 18:59

ts1, that's a sample of a type I've never encountered before. Sadly, the player or one of the filters can't close with any renderer it at all it seems. (This isn't a renderer bug.) The trunk build has been patched to handle these types of files correctly, so this issue will be fixed later on.
Nonetheless, the black screen bug is a renderer bug, which I fixed now.
I replaced the builds listed in my earlier post again.

XRyche

7th March 2015, 19:03

With the new build I get massive tearing when playing DVD's In all instances (FS, D3DFS, and windowed) with the frame interpolator regardless of what type of interpolation. When going from windowed to FS the tearing stops. When started in FS and going to windowed the tearing stops.When going from windowed to D3DFS the tearing persists until I go back into windowed mode then it stops. When going directly into D3DFS the tearing persists until I drop into windowed mode .

JanWillem32

7th March 2015, 22:51

TOM_SK

7th March 2015, 23:38

How to enable the 'Frame Interpolator' function? The settings are greyed out on my system, I don't understand how to enable the Frame Interpolator feature. Thank you.

http://i.imgur.com/Fsx333x.jpg

Hera

8th March 2015, 06:48

How to enable the 'Frame Interpolator' function? The settings are greyed out on my system, I don't understand how to enable the Frame Interpolator feature. Thank you.

I think you need to enable 32-bit / 16-bit surfaces under "Presentation" first

ts1

8th March 2015, 09:41

Should Frame Interpolator change the AVR frame rate? Because it's always the same for me no matter enabled or disabled F.I.
Edit: FrameR Lock always = video's fps and not monitor refresh rate.
Edit2: open this (http://files.futureleap.com/avatar_60.mkv) video, disable Alternative Scheduler, open stats screen, pause, wait for 10-15 secs, resume - there is always a lag, sometimes player hangs (only with 32-bit surfaces it seems, disabled F.I.).

JanWillem32

9th March 2015, 15:14

ts1, the video frame rate detection and frame rate lock is indeed used for detecting the video FPS. Note that most videos have really bad time stamps (counting in whole milliseconds), so it's not easy to detect the correct frame rate sometimes. The playback fps is always the monitor refresh rate, even if an image has to be displayed for multiple times in a row to match video fps to the display refresh rate. The frame interpolator just doesn't present frames multiple times to match the refresh rate, but generates interpolated frames to present on every display refresh.
I can replicate issues with that video sample. It has rather bad time stamps, and rendering 1280×720 60 fps on the 32-bit surfaces mode is way too heavy for the video memory throughput on my PC. I can't fix the lag, as it's a general performance issue, but I can maybe prevent it from getting stuck. I'll experiment a bit. Thank you for a good testing sample. I'm always looking for problematic files to test the renderer with.

XRyche

9th March 2015, 23:02

I can't replicate the issue, but I can change the mixer frame processing code I altered in the last build. Does this tester version have the same issues? http://www.mediafire.com/download/i6cjn5tfcdrb1d0/mpc-hc_tester_SSE2_for_DVD_plus_frame_interpolation.7z
If the problem persists with this build, I'll have to try to replicate this issue. For that case I have a few questions. Are you sure it's tearing, and not wrong frame ordering? Does it happen with all DVD samples? Does it happen if you select a single video file from a DVD (instead of the open DVD functionality)? If it's on a particular sample, can I have a (reduced) copy?

It doesn't happen with the tester build at all. The only difference is I'm not using any of your custom shaders and my usual build is 64 bit.

I have found something weird though. When I open the .vob file through "quick open" it plays perfectly fine. When I open the disc through "Open DVD/BD" that's when I get the tearing and/or incorrect frame order. This is with my usual 64 bit build. If you still want a sample I'll pm you.

Hera

10th March 2015, 02:01

If you move the mouse from outside left / right corner to the video itself - the mouse pointer will be remain a horizontal resize symbol on the video itself.
Hover on the left / right edge (as if you want to resize horizontally) while video is playing and the move the cursor into the video itself - sometimes the cursor doesn't change

This thing,
<--->

From the bottom (where the seek bar is) sometimes it remains a hand icon

Very minor visual annoyance

JanWillem32

10th March 2015, 12:52

XRyche, if the changes work it's fine I'll implement them this way from now on. I'll write some more code and then I will issue new builds.

Hera, thank you for reporting. I've replicated the issue and I think I already fixed it, too.

JanWillem32

12th March 2015, 22:08

I replaced the builds to include the latest two small fixes. No major changes were made.
x64: http://www.mediafire.com/download/nraypm00z80jik8/mpc-hc64_tester_dfr7370rs6i.7z
x86 SSE2: http://www.mediafire.com/download/23y54r7fz4f9a8a/mpc-hc_SSE2_tester_dfr7370rs6i.7z
x86 SSE: http://www.mediafire.com/download/rhu5ls6itubchca/mpc-hc_SSE_tester_dfr7370rs6i.7z

XRyche

14th March 2015, 03:01

Unfortunately, with the x64 build I'm still getting the tearing/incorrect frame order bug when using frame interpolation when playing DVD's. Here's a screenshot of the issue : http://www.mediafire.com/view/l26tuap9v0agbdu/Untitled6.png . The tearing/incorrect frame order is , of course, much worse while in motion but this should give you some idea of what I am seeing.

ts1

14th March 2015, 10:23

Edit: it works, I didn't know wtv was disabled in LAV Splitter.

JanWillem32

14th March 2015, 16:13

XRyche, is this problem only with the latest version and only with the x64 type? Do you have a (reduced) sample that I can use to try to replicate this issue?

XRyche

15th March 2015, 04:33

XRyche, is this problem only with the latest version and only with the x64 type? Do you have a (reduced) sample that I can use to try to replicate this issue?

Sample PM'd .

CruNcher

15th July 2015, 20:20

@JanWillem32

There is currently some major issue with the EVR Custom Renderer on Nvidias 353.30 WDDM 1.1 (WIN7)

I disabled lav filter P0 render mode as there is no direct window 10 bit support yet in your branch it seems and connection fails totally with P0 and lav filter for 4K Main 10 H.265 video playback currently.

changing from window to fullscreen or maximized window works but when trying to change from maximized window to fullscreen i get a black screen or it shows only the last image rendered audio plays but no video is visible anymore changing back to maximized or window continues normaly

Doesn't happen with MPC-BE nor MPC-HC

tested these so far (same issue)

mpc-hc64 tester dfr7370rrri
mpc-hc64 tester dfr7370rs6i

JanWillem32

16th July 2015, 15:17

I'll take a look at it later on. I'm currently on vacation.

dmiranda

1st August 2015, 05:56

I'll take a look at it later on. I'm currently on vacation.

Enjoy you break, JanWillem. After a bit of tweaking, I am running your "mpc-hc SSE2 tester dfr7370rs6i", and it is an amazing experience - even on XP and two old quadro cards. You rock bro. Thanks.

XRyche

1st August 2015, 21:47

Hi JanWillem32, long time. I don't know if you remember or not, but I was having issues with your renderer playing DVDs. I was getting a repeat frame/tearing issue. Well it turns out, after updating to Windows 10 up from Windows 8.1 the issue is completely gone.

I must confess I've been using madVR these last few months because of Nnedi3 mostly. Since I've been having issues with being able to use Nnedi3 since updating to Windows 10 I'm back to using your player regularly unless the Nnedi3 issue with madVR can be remedied.

I just wanted to thank you for still having it available.

Hera

10th August 2015, 04:47

The seek bar is very small at 200% DPI. Anyone have a solution?
Specs in Sig

XRyche

14th August 2015, 00:45

Hera

14th August 2015, 03:53

Use 100% DPI lol. Seriously, I'd be surprised if anything could be done. I mean JanWillem32 has done some rather miraculous things with this renderer, but it's still EVR when you get right down to it.

I have to get up close to the monitor and squint a bit to see things at 100%.
4K monitor @ 100% DPI = 4 times smaller and harder to read UI than an old school 1080p monitor of the same size

There are some problems with the renderer going black when going full screen as well, but that is less important.

XRyche

14th August 2015, 05:14

Is it just a momentary issue of going black or does it stay black screen? If it's just a momentary black screen before the image is shown, he actually cut the time it took to transition quite a bit.

Hera

15th August 2015, 03:52

Is it just a momentary issue of going black or does it stay black screen? If it's just a momentary black screen before the image is shown, he actually cut the time it took to transition quite a bit.

When it happens I have to restart.

XRyche

15th August 2015, 13:12

When it happens I have to restart.

That actually used to happen to me occasionally. It hasn't happened since I upgraded from Windows 8.1 to Windows 10 though. I have consistently been using JanWillem32's renderer since I upgraded, so about 2 weeks now, without any black screen issues. Switching to Windows 10 actually cleared up another issue that I already previously posted about.

JanWillem32

17th September 2015, 19:37

I replaced the builds to include the latest small fixes. No major changes were made.
I changed the OSD hiding timer, the fullscreen non-exclusive mode handling and fixed the name truncation issue for dim color LUT files. You can delete old dim profiles in the "C:\ProgramData\Media Player Classic" folder.
-

For the reported problems:
Does the lav filter P010 output mode still not work lately? It's possible it's purely a driver issue: I can disable the 10-bit types in such a case.
The black screen issue is partially solved. It does still go black if the window is maximized and goes fullscreen, but it shouldn't happen anymore when switching from the non-fullscreen mode. I'll have to try some other stuff to fix the issue. (I'm not even sure it's the renderer itself causing the issue, it could be a fault in the main window.)
For the DPI issues, I don't have a real solution. I'm not much of a GUI programmer (I only edited the forms for the new options and changed the GUI in the OSD a bit).

JanWillem32

18th September 2015, 18:22

I replaced the builds to include a fix for the fullscreen non-exclusive mode handling when the window is maximized and added AVX builds on request.
x64 AVX: http://www.mediafire.com/download/edof94d5x79xf2b/mpc-hc64_AVX_tester_dfr7370rs7i.7z
x64: http://www.mediafire.com/download/hh463nihd52s55z/mpc-hc64_tester_dfr7370rs7i.7z
x86 AVX: http://www.mediafire.com/download/h5s0ubpxqnb3fma/mpc-hc_AVX_tester_dfr7370rs7i.7z
x86 SSE2: http://www.mediafire.com/download/0x9x4e38ce0you4/mpc-hc_SSE2_tester_dfr7370rs7i.7z
x86 SSE: http://www.mediafire.com/download/fwfbpif9q5z9ooy/mpc-hc_SSE_tester_dfr7370rs7i.7z

XRyche

24th September 2015, 23:12

There is a slight 2 to 4 second pause when trying to close the player with the new x64 AVX build. There was no pause whatsoever with the previous x64 build.

Hera

25th September 2015, 00:21

There is a slight 2 to 4 second pause when trying to close the player with the new x64 AVX build. There was no pause whatsoever with the previous x64 build.

WFM - Specs in the sig

JanWillem32

25th September 2015, 12:50

It's the OSD I think. Disabling it should solve the problem. I also think I already solved the issue in the next build. (It will just not display "Stop" on closing the player anymore.)

XRyche

25th September 2015, 22:41

(It will just not display "Stop" on closing the player anymore.)

Well I guess that will fix it :D .

JanWillem32

30th September 2015, 02:56

I made the player close faster when the OSD is enabled.
I fixed the audio switcher and enhanced its capabilities to down-sample audio to 44100 Hz.
I fixed a frame rate detection issue for 60 and 60/1.001 fps sources.
x64 AVX: http://www.mediafire.com/download/te5h1ewvl3149k0/mpc-hc64_AVX_tester_dfr7370rs8i.7z
x64: http://www.mediafire.com/download/wd4g14gopjco1sk/mpc-hc64_tester_dfr7370rs8i.7z
x86 AVX: http://www.mediafire.com/download/2biyz3ofqonc0lq/mpc-hc_AVX_tester_dfr7370rs8i.7z
x86 SSE2: http://www.mediafire.com/download/n543546o36cd6j4/mpc-hc_SSE2_tester_dfr7370rs8i.7z
x86 SSE: http://www.mediafire.com/download/dt9qcx8htfhfdd8/mpc-hc_SSE_tester_dfr7370rs8i.7z

CruNcher

30th September 2015, 18:26

@Jan

The maximized/fullscreen blackscreen playback problem seems fixed though im testing on Nvidia 355.84 now

The switch responsiveness of the GUI (Renderer) is still so so it takes pretty long to react (delay, latency) when switchting render modes (window,maximized,fullscreen redraw) compared to MPC-HC/BE.

Strange

mpc-hc64 tester dfr7370rs8i.7z

no executable here therfore the .pdb ;) ?

and the tendency to brake out and endup in a jitter explosion is still high in fullscreen even with pretty warmed up caches :(

Im not sure maybe it's the OSD And Graph Rendering threads that are mainly responsible

http://i2.sendpic.org/t/2A/2AbSp1wtjZCYTFjxFmSbEsSkcun.jpg (http://sendpic.org/view/2/i/gtVFtsvhxmcyqu31qviatS6Buxj.png)

MPC-HC BE very stable OSD/Graph and Overlay System with no detectable interfernces in the main render thread

http://i1.sendpic.org/t/c6/c6u1Lrz1kIZIqDlkLdQOy1rKj6w.jpg (http://sendpic.org/view/1/i/tv8rrKX4Tba3P8elwhYPmriy2SI.png)

JanWillem32

4th October 2015, 00:36

Thank you for noticing these issues.
I replaced the x64 package (link remains unchanged).
My renderer is indeed slow to respond to changes in fullscreen/windowed resizing. It's just how it's built.
Have you tried the alternative scheduler option to solve the jitter issue? (View->Renderer Settings->Presentation). (Constant frame interpolation could work as well, by the way.) I'm thinking of making that option the default.
Does this issue remain in the D3D fullscreen exclusive mode? Is this issue only present in my more recent builds?
Also, I see that the OSD in my version of the renderer doesn't show the monitor's name. Do my previous builds do the same?

JanWillem32

5th October 2015, 14:01

I improved performance under high CPU usages by better multi-threading in EVR CP.
I fixed some minor performance issues with the alternative scheduler.
I changed the monitor EDID detection method. It might work now in cases where it didn't before.
I added the monitor brand to the OSD. (In some cases the type string didn't contain it.)
x64 AVX: http://www.mediafire.com/download/60lk5jal8njsprc/mpc-hc64_AVX_tester_dfr7370rs9i.7z
x64: http://www.mediafire.com/download/i066bop14te0110/mpc-hc64_tester_dfr7370rs9i.7z
x86 AVX: http://www.mediafire.com/download/w1crgoci5dh9big/mpc-hc_AVX_tester_dfr7370rs9i.7z
x86 SSE2: http://www.mediafire.com/download/jq6hlif0xg5h9ye/mpc-hc_SSE2_tester_dfr7370rs9i.7z
x86 SSE: http://www.mediafire.com/download/z0dvndi7aaffoy0/mpc-hc_SSE_tester_dfr7370rs9i.7z

CruNcher

5th October 2015, 20:07

It looks better and i tested further though sometimes the behaviour of the options logic is behind me sometimes i see A.Schdl in the OSD sometimes i dont but its active in the Dialog options

Though when A.Schdl was active (OSD visible) the results where pretty catastrophicall totally unstable playback results it stuttered it froze it jittered

Another thing is how the renderer reacts when Aero is turned off in non exclusive Fullscreen this happens i tried alternative V-sync still the same without Aero totally unplayable, not as bad as the A.Schdl results but still playback gets locked to a 18 fps sync.

http://i2.sendpic.org/t/dE/dEhRpQyxZf7UdJMrQDSsgtk9hIy.jpg (http://sendpic.org/view/2/i/tcvsrxIT0Z8x9BgALWwY8iDkh9d.png)

Though Nvidia changed so many Stuff in their Drivers when it comes to V-sync because of Adaptive Sync and most and for all G-sync of course and now comes VR additionally

One example where the A.Schdl OSD display is disturbing when Aero is off in the options and A.Schdl enabled it doesn't show it in the OSD so i guess A.Schdl works only with Aero enabled and if why are the options on click then not correctly grayed out in their relation to each other ?

MPC-BE

Aero ON
http://i1.sendpic.org/t/ig/igxpHmQxbHe7KoTIlxEmPqN8DBO.jpg (http://sendpic.org/view/1/i/vckDgql6i1tgKjpWq2LrRciaJxW.png)

Aero OFF
http://i2.sendpic.org/t/nX/nXPvGCUKNFDQYT2Q5mt1tjCIl9B.jpg (http://sendpic.org/view/2/i/tYlk6ZGD4YcEZrssByziLck8Gup.png)

Is it maybe the overhead of your renderer that it brakes totally apart here in such a utilization scenario ?

JanWillem32

5th October 2015, 23:34

How's the performance without the alternative scheduler enabled in the latest build? It should be much improved. On hardware like yours it should easily run such media even with high settings and a few heavy shaders enabled.
The alternative scheduler indeed uses the Desktop Composer to schedule frames. (It's more accurate and allows extra queuing of rendering images from the subtitle renderer, but costs some resources.)
Does the stats screen still not show the monitor EDID info in the latest version?

CruNcher

6th October 2015, 00:02

it's much better the spike that exploded before is still happening but much lower though alternative scheduling is no option here it's to unstable and yes still no Edid info shown

XRyche

6th October 2015, 01:06

I always figured the spike and the time it took to recover was just "par for the course" or just one of the downsides of using D3D FS. It was always there as long as I have used the experimental builds. Speed has drastically improved for me. It takes very little time, one or two seconds, if that for the frame-rate to recover even when using frame interpolation and the alternative scheduler. I suppose it is an Nvidia problem because when I had my old 9800GT I remember that the scheduler was unstable for me as well. I just figured my card was too old and slow. The Alternative scheduler on my R7 265 works perfectly fine though. I am getting EDID info on the stat screen and the branding of my monitor as well.

JanWillem32

6th October 2015, 01:08

Does the OSD work with this build? I tried some case-insensitive searches this time, maybe that will help.

CruNcher

6th October 2015, 04:04

As soon as i enable the Display Stats with this build the video surface gets lost in black and i see only the osd and hear the audio

http://i1.sendpic.org/t/ZD/ZDgkovUahpNCYGqhpP4clz16wi.jpg (http://sendpic.org/view/1/i/1CYmrWd0ueQJPViEKFKScERWYIT.png)

JanWillem32

6th October 2015, 07:36

Let's try a debug build, then. If it breaks at any point note down the line and press continue. Debug printouts can be received by DebugView: https://technet.microsoft.com/en-us/library/bb896647.aspx?f=255&MSPPError=-2147217396. (Just run it in capture mode at the same time as a debug build and you will get messages.)

CruNcher

6th October 2015, 11:00

It brakes immediately @ 6538 dx9allocatorpresenter.cpp then Warning Dialog "could not open D3D9.dll,OK" and continues playback after finding the right graph though i can't trigger the OSD it wont appear it seems it can't load EVR because it expects d3d9.dll in the main dir, then lets give it that ;)

Funny i can't debug it it wont open d3d9.dll that Debug Version want's to fool around with me :D

Sorry i have no idea might be the Visual Studio version used that has Security issues in the NT6 UAC Model even in Elevated mode it wont load the d3d9.dll not even from the main dir

tried to elevate debugview and mpc-hc no success, no idea how to get d3d9.dll working from the outside it seems to totally reject it with that Debug Version.

Hmm last logical guess it will only accept the Debug Version of the d3d9.dll (DirectX SDK)

JanWillem32

6th October 2015, 13:16

How silly of me. It's actually expecting the debug dll of d3d9.dll: d3d9d.dll. I'm Sorry for the inconvenience. Here's another debug build:

CruNcher

6th October 2015, 13:41

0 At line 22226 of dx9allocatorpresenter.cpp

[4792] FGM: Connecting 'Enhanced Video Renderer (custom presenter)'
[4792] --> CFGFilterVideoRenderer::Create on thread: 1772

Performance is obviously bad really bad in Debug Mode (this is how enabling A.Schdl feels in non dbg) ;)

[4792] EVR: SyncOffset: -0.212434 SampleFrame: 1178.000000 ClockFrame: 1183.310847
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.201694 SampleFrame: 1179.000000 ClockFrame: 1184.042351
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.211727 SampleFrame: 1180.000000 ClockFrame: 1185.293164
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.241138 SampleFrame: 1181.000000 ClockFrame: 1187.028453
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.254138 SampleFrame: 1182.000000 ClockFrame: 1188.353439
[4792] EVR: Normal frame
[4792] EVR: sync offset deviated much too low
[4792] EVR: SyncOffset: -0.243349 SampleFrame: 1183.000000 ClockFrame: 1189.083731
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.251400 SampleFrame: 1184.000000 ClockFrame: 1190.284997
[4792] EVR: Normal frame
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] EVR: Dropped frame
[4792] EVR: SyncOffset: -0.263428 SampleFrame: 1185.000000 ClockFrame: 1191.585700
[4792] EVR: Normal frame
[4792] EVR: OnClockPause() hnsSystemTime = 1596860107917
[4792] EVR: sync offset deviated much too low
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverEndFlush
[4792] EVR: OnClockRestart() hnsSystemTime = 1596861297917
[4792] EVR: OnClockPause() hnsSystemTime = 1596861297917
[4792] EVR: OnClockStop() hnsSystemTime = 1596861647917
[4792] EVR: MFVP_MESSAGE_ENDSTREAMING
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverNewSegment
[4792] EVR: MFVP_MESSAGE_FLUSH
[4792] EVR: Flush done!
[4792] CAudioSwitcherFilter::DeliverEndFlush
[4792] OSD DisplayMessage: Stop, duration: 3000
[4792] OSD Draw Message: Stop
[4792] Video renderer is eight frame times behind, expect heavy frame dropping
[4792] OSD ClearMessageInternal

OSD though shows up Video also

JanWillem32

6th October 2015, 14:14

I replaced the build, and the download link remains the same. It should work this time around.

CruNcher

6th October 2015, 15:16

if you mean the edid recognition that is still not working like it does in MPC-BE or do i need to enable it in some option first in the GUI that this shows up in the OSD ?
btw i prefer to test the 64 bit builds exclusively because of the hevc decoding speedup.

Pretty crazy to see Cyberlink getting totally beaten by MPC-BE x64 in playback Performance on the Hard 10 Bit 4K Bitstreams @ the Multithreading CPU Edge

Tough with the test renderer no chance yet to reach that playback stability + OSD outside of d3d fullscreen and even then it still shows issues

and no OSD render stalls like with the normal MPC-HE

http://forum.doom9.org/showpost.php?p=1741297&postcount=2211

They did a really great job on MPC-BE

JanWillem32

6th October 2015, 15:42

Does it still break at the same line? There is no option to enable this feature.
Note that debug builds are not there to have any decent performance. As such, debug builds are unsuitable for regular usage.
x64 build with extra verbosity (ReadRegistryDisplayEDID() entries): http://www.mediafire.com/download/b7jho02qcqlxkii/mpc-hc64_debug_tester_dfr7370rs9i.7z

CruNcher

6th October 2015, 15:52

Works now :)

Bur see what suddenly happened when changing window modes back and forth with this build

http://i1.sendpic.org/t/nY/nYi67f8R1YwFFNKYWWf6tlH7gKa.jpg (http://sendpic.org/view/1/i/kffxgRhHwNuMM4T6CrmQo5pbYoD.png)

JanWillem32

6th October 2015, 16:10

OK, I'll remove that debug assertion. It doesn't mean much. Glad to hear that the OSD functionalty is fixed. I'll keep the function as it is now.

CruNcher

6th October 2015, 18:58

Some further tests im doing currently on the playback efficiency side

http://forum.doom9.org/showpost.php?p=1741843&postcount=830

XRyche

7th October 2015, 03:25

JanWillem32, the newest regular AVX 64 build drops audio out when you switch from D3DFS to FS or visa versa randomly when using Frame interpolation. It doesn't happen every time, it just happens randomly for no apparent reason. Switching between D3D FS and windowed mode doesn't seem to have this issue.

JanWillem32

7th October 2015, 08:42

XRyche, that's probably because I fixed the starvation clock. The starvation clock sends a message to the main thread to seek ahead if the renderer is more than a second behind. In your case the reset is taking longer than a second and that is probably making the audio switcher/renderer upset. Manually pausing before a reset should fix this issue.
I can experiment with automatic pausing and resuming after the reset for such a case.

JanWillem32

7th October 2015, 10:42

Here are some intermediate builds with such an auto-pause feature. I'm not sure that people will actually like this feature though.

XRyche

8th October 2015, 00:31

The auto-pause feature works quite well and isn't as disruptive as I thought it would be. For some reason I thought it was going to pause playback automatically but you would have to unpause it manually. The pause isn't that long at all so it isn't that intrusive, at least to me it isn't. Thank you.

JanWillem32

8th October 2015, 20:07

ts1

8th October 2015, 21:18

Only CPU usage on Vista.
And it takes long till start of playback on last builds.

JanWillem32

8th October 2015, 22:02

I'll do some testing in Vista emulation mode later on. Does the stats screen show error values for GPU usage or no line for GPU usage at all?
Does the player start any faster if you deselect the "Automatic Refresh Rate Detection" option in View->Options->Output? I know that some monitors don't report their refresh rate very well with this function (and then (re-)initialization becomes very slow).
It could also be the automatic pausing functionality. Are you using a non-default zooming option or something similar?

XRyche

9th October 2015, 04:53

I received a feature request to add system and video resources to the stats screen. This wasn't that easy, but I think it works fine now. Note that the CPU and GPU percentages are estimates. e.g. both statistics can surpass 100% load when doing heavy tasks.
Note that I'm interested if the GPU resource function works on Windows Vista. If not, I'll edit the code to only allow this feature on Windows 7 and onward.
x64 AVX: http://www.mediafire.com/download/wwkalp293q99thd/mpc-hc64_AVX_tester_im.7z
x64: http://www.mediafire.com/download/ka9773wwgiei3v9/mpc-hc64_tester_im.7z
x86 AVX: http://www.mediafire.com/download/fcdfqjdcd941cr5/mpc-hc_AVX_tester_im.7z
x86 SSE2: http://www.mediafire.com/download/hbxae9muw0312p4/mpc-hc_SSE2_tester_im.7z

I know I'm not on XP but everything works like it should on my end. Frame Interpolation really makes those shadercores spike though. I checked the stats via MSI Afterburner which displays most the stats, including individual cpu core and shared cpu stats as well. MSI Afterburner lets me look at the stats up to 4 mins after MPC was closed. Your stats and MSI Afterburner stats are pretty close as far as i can tell. Not an exact match but you did say your stats are estimates.

ts1

9th October 2015, 14:25

No line for GPU usage at all.
Without "Automatic Refresh Rate Detection" almost instantly on Win 10. But still 2-3 seconds on Vista (was ~5). Need debug build.

JanWillem32

10th October 2015, 06:38

Then this call just doesn't work on Vista. I can live with that.
Here's an x86 SSE2 debug build: ...
If it breaks at any point note down the line and press continue. Debug printouts can be received by DebugView: https://technet.microsoft.com/en-us/library/bb896647.aspx?f=255&MSPPError=-2147217396. (Just run it in capture mode at the same time as a debug build and you will get messages.)
I still wonder why these last few builds are slow to start on your system. I didn't change much in the initialization sequences. Does the same slow startup happen when trying VMR-9?

ts1

10th October 2015, 08:34

For EVR:

00000230 0.47601447 [3492] EVR: Trying mixer input type: NV12
00000231 2.32427502 [3492] FGM: Inserting 0 0 0000002000000000 '{00A95963-3BE5-48C0-AD9F-3356D67EA09D}' -->
00000232 2.32430625 [3492] Success

For VMR9:

00000202 0.17028834 [3808] Video renderer device created or reset, window size: 310?200
00000203 2.13441420 [3808] FGM: Inserting 0 0 0000002000000000 '{00A95963-3BE5-48C0-AD9F-3356D67EA09D}' -->
00000204 2.13444591 [3808] Success

This is on 1080p video. For 480p video delay is ~0.5 sec here. On Win 10 it's ~0.15 for 1080p and ~0.05 for 480p.

And on VMR9 10bit 4:4:4 video works only with Display stats enabled on both OS's. Without:
http://i1.sendpic.org/t/gC/gC3A0KWOsuaDjGR4HGk7lXPPw10.jpg (http://sendpic.org/view/1/i/7qe2cTqxz6tF19je5cAyPP9kcxv.jpg)

JanWillem32

10th October 2015, 08:53

Are you using any automatic resizing options? (The most common one is under View->Options->Playback->Auto Zoom.) These features reset the renderer before playback.
It's odd that initializing the mixer parts would take that long. I haven't edited much mixer code in a long time. Are you sure it's only in the last few builds?
I can replicate the issue with the 10bit 4:4:4 video. I'm not sure what is happening there. I'll do some testing next week.

ts1

10th October 2015, 09:06

Yes, it is Auto Zoom. It's fast without it.

ts1

10th October 2015, 09:46

Seems like Auto Zoom + Lanczos3/4 = delay
On Win 10 as well.

JanWillem32

10th October 2015, 10:48

That does explain things a bit. The Lanczos shaders are somewhat slow to compile. If automatic re-sizing is enabled the resizing shaders have to be compiled twice. (It's once for the initial small window, and then again for the larger window.)
Still, are you sure it's a problem of the last few builds?

ts1

10th October 2015, 11:18

No, I switched to lanczos3 recently.

JanWillem32

14th October 2015, 21:23

I have been debugging a bit and I would like to verify if the VMR9 (renderless) with default settings + X8R8G8B8 (a.k.a. RGB32) input bug reported by ts1 happens with all vendors and drivers. I suspect it's a driver bug. I can verify that the bug is there with my AMD HD7970. If you own an Nvidia or Intel GPU, please test VMR9 (renderless) with default settings with a sample with nothing but X8R8G8B8 (a.k.a. RGB32) temporarily enabled in the filter output of your decoder of choice (both ffdshow tryouts and LAV filters support this on their video output configuration tabs). If the bug is there in multiple configurations I'll have to deal with a bug in the VMR-9, and try to find a solution for it.

JanWillem32

15th October 2015, 21:15

I've renewed the intermediate tester builds.
The VMR-9 bug reported by ts1 is solved (in a very odd way, but it works).
I've written a new dithering method. It's not yet integrated, but volunteers can test it.
To test it, enable the renderer in a sort of debug mode:
- enable 32-bit floating-point surfaces
- disable intital color mixing shaders
- under color management, enable color passtrough mode
- disable the internal ditherer (set levels to 0)
- disable pre-resize shaders
- enable the "block-based error diffusion dithering" shader post-resize as the only shader
- set the zoom factor to 100%
The renderer wil then render nothing more than that shader in its pipeline. (Forgive the lack of chroma up-sampling.)
If there is enough interest in this method after users have tested this dithering method, I can install this shader as an internal option for the renderer.

XRyche

16th October 2015, 00:49

It looks better on my old circa 2007 TN monitor than the coloured dithering. I can't even pick out any dithering pattern at all and I was sitting right at my monitor. At higher levels of colour dithering i can start seeing the dithering pattern. Considering it's a 6 bit TN monitor I think this does make a difference.

I would really like to know what others think as well. I've been known to fall prey to the "placebo effect" before. Honestly though, I don't think I'm just seeing an improvement because I want to. Thanks for making this available for testing JanWillem32.

I did disable frame interpolation as well.

ts1

18th October 2015, 10:48

Do you plan to upgrade to 1.7? 1.6 unfortunately doesn't support stdin.

JanWillem32

19th October 2015, 17:40

ts1, I'll have to discuss some things with the MPC-HC staff.
If I were to merge the renderer fixes onto the latest version of the code I could work miracles. However, it will come at the cost of VMR-7 r. and EVR Sync. If people are willing to accept that, I can finally merge the renderer fixes into the main branch.

new shaders (note that the 5×5 version will not work in the current build, but will in the next):// (C) 2015 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.

// 5×5 block-based error diffusion dithering
// This shader can be run as a screen space pixel shader.
// This shader requires compiling with ps_2_b, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader will dither down an image using block-based error diffusion.

#define sa(A, B, C) float3 A = tex2D(s0, tex+float2(B, C)*c1).rgb;
#define Quantization 255.

sampler s0 : register(s0);
float2 c0 : register(c0);
float2 c1 : register(c1);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float2 n = frac(tex*c0*.2);
tex -= (n*5.-.5)*c1;

// original pixels
sa(s1, 0., 0.) sa(s2, 1., 0.) sa(s3, 2., 0.) sa(s4, 3., 0.) sa(s5, 4., 0.)
sa(s16, 0., 1.) sa(s17, 1., 1.) sa(s18, 2., 1.) sa(s19, 3., 1.) sa(s6, 4., 1.)
sa(s15, 0., 2.) sa(s24, 1., 2.) sa(s25, 2., 2.) sa(s20, 3., 2.) sa(s7, 4., 2.)
sa(s14, 0., 3.) sa(s23, 1., 3.) sa(s22, 2., 3.) sa(s21, 3., 3.) sa(s8, 4., 3.)
sa(s13, 0., 4.) sa(s12, 1., 4.) sa(s11, 2., 4.) sa(s10, 3., 4.) sa(s9, 4., 4.)

float3 f1 = frac(s1*Quantization);
float3 f2 = frac(s2*Quantization);
float3 f3 = frac(s3*Quantization);
float3 f4 = frac(s4*Quantization);
float3 f5 = frac(s5*Quantization);
float3 f6 = frac(s6*Quantization);
float3 f7 = frac(s7*Quantization);
float3 f8 = frac(s8*Quantization);
float3 f9 = frac(s9*Quantization);
float3 f10 = frac(s10*Quantization);
float3 f11 = frac(s11*Quantization);
float3 f12 = frac(s12*Quantization);
float3 f13 = frac(s13*Quantization);
float3 f14 = frac(s14*Quantization);
float3 f15 = frac(s15*Quantization);
float3 f16 = frac(s16*Quantization);
float3 f17 = frac(s17*Quantization);
float3 f18 = frac(s18*Quantization);
float3 f19 = frac(s19*Quantization);
float3 f20 = frac(s20*Quantization);
float3 f21 = frac(s21*Quantization);
float3 f22 = frac(s22*Quantization);
float3 f23 = frac(s23*Quantization);
float3 f24 = frac(s24*Quantization);
float3 f25 = frac(s25*Quantization);

float3 current;
float3 mf1 = -f1;
float3 uf1 = 1.-f1;
[flatten] if(f1.r > .5) f1.r = uf1.r;
else f1.r = mf1.r;
[flatten] if(f1.g > .5) f1.g = uf1.g;
else f1.g = mf1.g;
[flatten] if(f1.b > .5) f1.b = uf1.b;
else f1.b = mf1.b;
s1 += f1/Quantization;
current = -f1;

float3 cu2 = current+f2;
float3 mf2 = -f2;
float3 uf2 = 1.-f2;
[flatten] if(cu2.r > .5) f2.r = uf2.r;
else f2.r = mf2.r;
[flatten] if(cu2.g > .5) f2.g = uf2.g;
else f2.g = mf2.g;
[flatten] if(cu2.b > .5) f2.b = uf2.b;
else f2.b = mf2.b;
s2 += f2/Quantization;
current -= f2;

float3 cu3 = current+f3;
float3 mf3 = -f3;
float3 uf3 = 1.-f3;
[flatten] if(cu3.r > .5) f3.r = uf3.r;
else f3.r = mf3.r;
[flatten] if(cu3.g > .5) f3.g = uf3.g;
else f3.g = mf3.g;
[flatten] if(cu3.b > .5) f3.b = uf3.b;
else f3.b = mf3.b;
s3 += f3/Quantization;
current -= f3;

float3 cu4 = current+f4;
float3 mf4 = -f4;
float3 uf4 = 1.-f4;
[flatten] if(cu4.r > .5) f4.r = uf4.r;
else f4.r = mf4.r;
[flatten] if(cu4.g > .5) f4.g = uf4.g;
else f4.g = mf4.g;
[flatten] if(cu4.b > .5) f4.b = uf4.b;
else f4.b = mf4.b;
s4 += f4/Quantization;
current -= f4;

float3 cu5 = current+f5;
float3 mf5 = -f5;
float3 uf5 = 1.-f5;
[flatten] if(cu5.r > .5) f5.r = uf5.r;
else f5.r = mf5.r;
[flatten] if(cu5.g > .5) f5.g = uf5.g;
else f5.g = mf5.g;
[flatten] if(cu5.b > .5) f5.b = uf5.b;
else f5.b = mf5.b;
s5 += f5/Quantization;
current -= f5;

float3 cu6 = current+f6;
float3 mf6 = -f6;
float3 uf6 = 1.-f6;
[flatten] if(cu6.r > .5) f6.r = uf6.r;
else f6.r = mf6.r;
[flatten] if(cu6.g > .5) f6.g = uf6.g;
else f6.g = mf6.g;
[flatten] if(cu6.b > .5) f6.b = uf6.b;
else f6.b = mf6.b;
s6 += f6/Quantization;
current -= f6;

float3 cu7 = current+f7;
float3 mf7 = -f7;
float3 uf7 = 1.-f7;
[flatten] if(cu7.r > .5) f7.r = uf7.r;
else f7.r = mf7.r;
[flatten] if(cu7.g > .5) f7.g = uf7.g;
else f7.g = mf7.g;
[flatten] if(cu7.b > .5) f7.b = uf7.b;
else f7.b = mf7.b;
s7 += f7/Quantization;
current -= f7;

float3 cu8 = current+f8;
float3 mf8 = -f8;
float3 uf8 = 1.-f8;
[flatten] if(cu8.r > .5) f8.r = uf8.r;
else f8.r = mf8.r;
[flatten] if(cu8.g > .5) f8.g = uf8.g;
else f8.g = mf8.g;
[flatten] if(cu8.b > .5) f8.b = uf8.b;
else f8.b = mf8.b;
s8 += f8/Quantization;
current -= f8;

float3 cu9 = current+f9;
float3 mf9 = -f9;
float3 uf9 = 1.-f9;
[flatten] if(cu9.r > .5) f9.r = uf9.r;
else f9.r = mf9.r;
[flatten] if(cu9.g > .5) f9.g = uf9.g;
else f9.g = mf9.g;
[flatten] if(cu9.b > .5) f9.b = uf9.b;
else f9.b = mf9.b;
s9 += f9/Quantization;
current -= f9;

float3 cu10 = current+f10;
float3 mf10 = -f10;
float3 uf10 = 1.-f10;
[flatten] if(cu10.r > .5) f10.r = uf10.r;
else f10.r = mf10.r;
[flatten] if(cu10.g > .5) f10.g = uf10.g;
else f10.g = mf10.g;
[flatten] if(cu10.b > .5) f10.b = uf10.b;
else f10.b = mf10.b;
s10 += f10/Quantization;
current -= f10;

float3 cu11 = current+f11;
float3 mf11 = -f11;
float3 uf11 = 1.-f11;
[flatten] if(cu11.r > .5) f11.r = uf11.r;
else f11.r = mf11.r;
[flatten] if(cu11.g > .5) f11.g = uf11.g;
else f11.g = mf11.g;
[flatten] if(cu11.b > .5) f11.b = uf11.b;
else f11.b = mf11.b;
s11 += f11/Quantization;
current -= f11;

float3 cu12 = current+f12;
float3 mf12 = -f12;
float3 uf12 = 1.-f12;
[flatten] if(cu12.r > .5) f12.r = uf12.r;
else f12.r = mf12.r;
[flatten] if(cu12.g > .5) f12.g = uf12.g;
else f12.g = mf12.g;
[flatten] if(cu12.b > .5) f12.b = uf12.b;
else f12.b = mf12.b;
s12 += f12/Quantization;
current -= f12;

float3 cu13 = current+f13;
float3 mf13 = -f13;
float3 uf13 = 1.-f13;
[flatten] if(cu13.r > .5) f13.r = uf13.r;
else f13.r = mf13.r;
[flatten] if(cu13.g > .5) f13.g = uf13.g;
else f13.g = mf13.g;
[flatten] if(cu13.b > .5) f13.b = uf13.b;
else f13.b = mf13.b;
s13 += f13/Quantization;
current -= f13;

float3 cu14 = current+f14;
float3 mf14 = -f14;
float3 uf14 = 1.-f14;
[flatten] if(cu14.r > .5) f14.r = uf14.r;
else f14.r = mf14.r;
[flatten] if(cu14.g > .5) f14.g = uf14.g;
else f14.g = mf14.g;
[flatten] if(cu14.b > .5) f14.b = uf14.b;
else f14.b = mf14.b;
s14 += f14/Quantization;
current -= f14;

float3 cu15 = current+f15;
float3 mf15 = -f15;
float3 uf15 = 1.-f15;
[flatten] if(cu15.r > .5) f15.r = uf15.r;
else f15.r = mf15.r;
[flatten] if(cu15.g > .5) f15.g = uf15.g;
else f15.g = mf15.g;
[flatten] if(cu15.b > .5) f15.b = uf15.b;
else f15.b = mf15.b;
s15 += f15/Quantization;
current -= f15;

float3 cu16 = current+f16;
float3 mf16 = -f16;
float3 uf16 = 1.-f16;
[flatten] if(cu16.r > .5) f16.r = uf16.r;
else f16.r = mf16.r;
[flatten] if(cu16.g > .5) f16.g = uf16.g;
else f16.g = mf16.g;
[flatten] if(cu16.b > .5) f16.b = uf16.b;
else f16.b = mf16.b;
s16 += f16/Quantization;
current -= f16;

float3 cu17 = current+f17;
float3 mf17 = -f17;
float3 uf17 = 1.-f17;
[flatten] if(cu17.r > .5) f17.r = uf17.r;
else f17.r = mf17.r;
[flatten] if(cu17.g > .5) f17.g = uf17.g;
else f17.g = mf17.g;
[flatten] if(cu17.b > .5) f17.b = uf17.b;
else f17.b = mf17.b;
s17 += f17/Quantization;
current -= f17;

float3 cu18 = current+f18;
float3 mf18 = -f18;
float3 uf18 = 1.-f18;
[flatten] if(cu18.r > .5) f18.r = uf18.r;
else f18.r = mf18.r;
[flatten] if(cu18.g > .5) f18.g = uf18.g;
else f18.g = mf18.g;
[flatten] if(cu18.b > .5) f18.b = uf18.b;
else f18.b = mf18.b;
s18 += f18/Quantization;
current -= f18;

float3 cu19 = current+f19;
float3 mf19 = -f19;
float3 uf19 = 1.-f19;
[flatten] if(cu19.r > .5) f19.r = uf19.r;
else f19.r = mf19.r;
[flatten] if(cu19.g > .5) f19.g = uf19.g;
else f19.g = mf19.g;
[flatten] if(cu19.b > .5) f19.b = uf19.b;
else f19.b = mf19.b;
s19 += f19/Quantization;
current -= f19;

float3 cu20 = current+f20;
float3 mf20 = -f20;
float3 uf20 = 1.-f20;
[flatten] if(cu20.r > .5) f20.r = uf20.r;
else f20.r = mf20.r;
[flatten] if(cu20.g > .5) f20.g = uf20.g;
else f20.g = mf20.g;
[flatten] if(cu20.b > .5) f20.b = uf20.b;
else f20.b = mf20.b;
s20 += f20/Quantization;
current -= f20;

float3 cu21 = current+f21;
float3 mf21 = -f21;
float3 uf21 = 1.-f21;
[flatten] if(cu21.r > .5) f21.r = uf21.r;
else f21.r = mf21.r;
[flatten] if(cu21.g > .5) f21.g = uf21.g;
else f21.g = mf21.g;
[flatten] if(cu21.b > .5) f21.b = uf21.b;
else f21.b = mf21.b;
s21 += f21/Quantization;
current -= f21;

float3 cu22 = current+f22;
float3 mf22 = -f22;
float3 uf22 = 1.-f22;
[flatten] if(cu22.r > .5) f22.r = uf22.r;
else f22.r = mf22.r;
[flatten] if(cu22.g > .5) f22.g = uf22.g;
else f22.g = mf22.g;
[flatten] if(cu22.b > .5) f22.b = uf22.b;
else f22.b = mf22.b;
s22 += f22/Quantization;
current -= f22;

float3 cu23 = current+f23;
float3 mf23 = -f23;
float3 uf23 = 1.-f23;
[flatten] if(cu23.r > .5) f23.r = uf23.r;
else f23.r = mf23.r;
[flatten] if(cu23.g > .5) f23.g = uf23.g;
else f23.g = mf23.g;
[flatten] if(cu23.b > .5) f23.b = uf23.b;
else f23.b = mf23.b;
s23 += f23/Quantization;
current -= f23;

float3 cu24 = current+f24;
float3 mf24 = -f24;
float3 uf24 = 1.-f24;
[flatten] if(cu24.r > .5) f24.r = uf24.r;
else f24.r = mf24.r;
[flatten] if(cu24.g > .5) f24.g = uf24.g;
else f24.g = mf24.g;
[flatten] if(cu24.b > .5) f24.b = uf24.b;
else f24.b = mf24.b;
s24 += f24/Quantization;
current -= f24;

float3 cu25 = current+f25;
float3 mf25 = -f25;
float3 uf25 = 1.-f25;
[flatten] if(cu25.r > .5) f25.r = uf25.r;
else f25.r = mf25.r;
[flatten] if(cu25.g > .5) f25.g = uf25.g;
else f25.g = mf25.g;
[flatten] if(cu25.b > .5) f25.b = uf25.b;
else f25.b = mf25.b;
s25 += f25/Quantization;
//current -= f25;

[flatten] if(n.y > .8) {
[flatten] if(n.x > .8) return s9.rgbb;
else [flatten] if(n.x > .6) return s10.rgbb;
else [flatten] if(n.x > .4) return s11.rgbb;
else [flatten] if(n.x > .2) return s12.rgbb;
else return s13.rgbb;}
else [flatten] if(n.y > .6) {
[flatten] if(n.x > .8) return s8.rgbb;
else [flatten] if(n.x > .6) return s21.rgbb;
else [flatten] if(n.x > .4) return s22.rgbb;
else [flatten] if(n.x > .2) return s23.rgbb;
else return s14.rgbb;}
else [flatten] if(n.y > .4) {
[flatten] if(n.x > .8) return s7.rgbb;
else [flatten] if(n.x > .6) return s20.rgbb;
else [flatten] if(n.x > .4) return s25.rgbb;
else [flatten] if(n.x > .2) return s24.rgbb;
else return s15.rgbb;}
else [flatten] if(n.y > .2) {
[flatten] if(n.x > .8) return s6.rgbb;
else [flatten] if(n.x > .6) return s19.rgbb;
else [flatten] if(n.x > .4) return s18.rgbb;
else [flatten] if(n.x > .2) return s17.rgbb;
else return s16.rgbb;}
else {
[flatten] if(n.x > .8) return s5.rgbb;
else [flatten] if(n.x > .6) return s4.rgbb;
else [flatten] if(n.x > .4) return s3.rgbb;
else [flatten] if(n.x > .2) return s2.rgbb;
else return s1.rgbb;}
}

JanWillem32

19th October 2015, 17:42

// (C) 2015 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.

// 4×4 block-based error diffusion dithering
// This shader can be run as a screen space pixel shader.
// This shader requires compiling with ps_2_a, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader will dither down an image using block-based error diffusion.

#define sa(A, B, C) float3 A = tex2D(s0, tex+float2(B, C)*c1).rgb;
#define Quantization 255.

sampler s0 : register(s0);
float2 c0 : register(c0);
float2 c1 : register(c1);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float2 n = frac(tex*c0*.25);
tex -= (n*4.-.5)*c1;

// original pixels
sa(s1, 0., 0.) sa(s2, 1., 0.) sa(s3, 2., 0.) sa(s4, 3., 0.)
sa(s12, 0., 1.) sa(s13, 1., 1.) sa(s14, 2., 1.) sa(s5, 3., 1.)
sa(s11, 0., 2.) sa(s16, 1., 2.) sa(s15, 2., 2.) sa(s6, 3., 2.)
sa(s10, 0., 3.) sa(s9, 1., 3.) sa(s8, 2., 3.) sa(s7, 3., 3.)

float3 f1 = frac(s1*Quantization);
float3 f2 = frac(s2*Quantization);
float3 f3 = frac(s3*Quantization);
float3 f4 = frac(s4*Quantization);
float3 f5 = frac(s5*Quantization);
float3 f6 = frac(s6*Quantization);
float3 f7 = frac(s7*Quantization);
float3 f8 = frac(s8*Quantization);
float3 f9 = frac(s9*Quantization);
float3 f10 = frac(s10*Quantization);
float3 f11 = frac(s11*Quantization);
float3 f12 = frac(s12*Quantization);
float3 f13 = frac(s13*Quantization);
float3 f14 = frac(s14*Quantization);
float3 f15 = frac(s15*Quantization);
float3 f16 = frac(s16*Quantization);

float3 current;
float3 mf1 = -f1;
float3 uf1 = 1.-f1;
[flatten] if(f1.r > .5) f1.r = uf1.r;
else f1.r = mf1.r;
[flatten] if(f1.g > .5) f1.g = uf1.g;
else f1.g = mf1.g;
[flatten] if(f1.b > .5) f1.b = uf1.b;
else f1.b = mf1.b;
s1 += f1/Quantization;
current = -f1;

float3 cu2 = current+f2;
float3 mf2 = -f2;
float3 uf2 = 1.-f2;
[flatten] if(cu2.r > .5) f2.r = uf2.r;
else f2.r = mf2.r;
[flatten] if(cu2.g > .5) f2.g = uf2.g;
else f2.g = mf2.g;
[flatten] if(cu2.b > .5) f2.b = uf2.b;
else f2.b = mf2.b;
s2 += f2/Quantization;
current -= f2;

float3 cu3 = current+f3;
float3 mf3 = -f3;
float3 uf3 = 1.-f3;
[flatten] if(cu3.r > .5) f3.r = uf3.r;
else f3.r = mf3.r;
[flatten] if(cu3.g > .5) f3.g = uf3.g;
else f3.g = mf3.g;
[flatten] if(cu3.b > .5) f3.b = uf3.b;
else f3.b = mf3.b;
s3 += f3/Quantization;
current -= f3;

float3 cu4 = current+f4;
float3 mf4 = -f4;
float3 uf4 = 1.-f4;
[flatten] if(cu4.r > .5) f4.r = uf4.r;
else f4.r = mf4.r;
[flatten] if(cu4.g > .5) f4.g = uf4.g;
else f4.g = mf4.g;
[flatten] if(cu4.b > .5) f4.b = uf4.b;
else f4.b = mf4.b;
s4 += f4/Quantization;
current -= f4;

float3 cu5 = current+f5;
float3 mf5 = -f5;
float3 uf5 = 1.-f5;
[flatten] if(cu5.r > .5) f5.r = uf5.r;
else f5.r = mf5.r;
[flatten] if(cu5.g > .5) f5.g = uf5.g;
else f5.g = mf5.g;
[flatten] if(cu5.b > .5) f5.b = uf5.b;
else f5.b = mf5.b;
s5 += f5/Quantization;
current -= f5;

float3 cu6 = current+f6;
float3 mf6 = -f6;
float3 uf6 = 1.-f6;
[flatten] if(cu6.r > .5) f6.r = uf6.r;
else f6.r = mf6.r;
[flatten] if(cu6.g > .5) f6.g = uf6.g;
else f6.g = mf6.g;
[flatten] if(cu6.b > .5) f6.b = uf6.b;
else f6.b = mf6.b;
s6 += f6/Quantization;
current -= f6;

float3 cu7 = current+f7;
float3 mf7 = -f7;
float3 uf7 = 1.-f7;
[flatten] if(cu7.r > .5) f7.r = uf7.r;
else f7.r = mf7.r;
[flatten] if(cu7.g > .5) f7.g = uf7.g;
else f7.g = mf7.g;
[flatten] if(cu7.b > .5) f7.b = uf7.b;
else f7.b = mf7.b;
s7 += f7/Quantization;
current -= f7;

float3 cu8 = current+f8;
float3 mf8 = -f8;
float3 uf8 = 1.-f8;
[flatten] if(cu8.r > .5) f8.r = uf8.r;
else f8.r = mf8.r;
[flatten] if(cu8.g > .5) f8.g = uf8.g;
else f8.g = mf8.g;
[flatten] if(cu8.b > .5) f8.b = uf8.b;
else f8.b = mf8.b;
s8 += f8/Quantization;
current -= f8;

float3 cu9 = current+f9;
float3 mf9 = -f9;
float3 uf9 = 1.-f9;
[flatten] if(cu9.r > .5) f9.r = uf9.r;
else f9.r = mf9.r;
[flatten] if(cu9.g > .5) f9.g = uf9.g;
else f9.g = mf9.g;
[flatten] if(cu9.b > .5) f9.b = uf9.b;
else f9.b = mf9.b;
s9 += f9/Quantization;
current -= f9;

float3 cu10 = current+f10;
float3 mf10 = -f10;
float3 uf10 = 1.-f10;
[flatten] if(cu10.r > .5) f10.r = uf10.r;
else f10.r = mf10.r;
[flatten] if(cu10.g > .5) f10.g = uf10.g;
else f10.g = mf10.g;
[flatten] if(cu10.b > .5) f10.b = uf10.b;
else f10.b = mf10.b;
s10 += f10/Quantization;
current -= f10;

float3 cu11 = current+f11;
float3 mf11 = -f11;
float3 uf11 = 1.-f11;
[flatten] if(cu11.r > .5) f11.r = uf11.r;
else f11.r = mf11.r;
[flatten] if(cu11.g > .5) f11.g = uf11.g;
else f11.g = mf11.g;
[flatten] if(cu11.b > .5) f11.b = uf11.b;
else f11.b = mf11.b;
s11 += f11/Quantization;
current -= f11;

float3 cu12 = current+f12;
float3 mf12 = -f12;
float3 uf12 = 1.-f12;
[flatten] if(cu12.r > .5) f12.r = uf12.r;
else f12.r = mf12.r;
[flatten] if(cu12.g > .5) f12.g = uf12.g;
else f12.g = mf12.g;
[flatten] if(cu12.b > .5) f12.b = uf12.b;
else f12.b = mf12.b;
s12 += f12/Quantization;
current -= f12;

float3 cu13 = current+f13;
float3 mf13 = -f13;
float3 uf13 = 1.-f13;
[flatten] if(cu13.r > .5) f13.r = uf13.r;
else f13.r = mf13.r;
[flatten] if(cu13.g > .5) f13.g = uf13.g;
else f13.g = mf13.g;
[flatten] if(cu13.b > .5) f13.b = uf13.b;
else f13.b = mf13.b;
s13 += f13/Quantization;
current -= f13;

float3 cu14 = current+f14;
float3 mf14 = -f14;
float3 uf14 = 1.-f14;
[flatten] if(cu14.r > .5) f14.r = uf14.r;
else f14.r = mf14.r;
[flatten] if(cu14.g > .5) f14.g = uf14.g;
else f14.g = mf14.g;
[flatten] if(cu14.b > .5) f14.b = uf14.b;
else f14.b = mf14.b;
s14 += f14/Quantization;
current -= f14;

float3 cu15 = current+f15;
float3 mf15 = -f15;
float3 uf15 = 1.-f15;
[flatten] if(cu15.r > .5) f15.r = uf15.r;
else f15.r = mf15.r;
[flatten] if(cu15.g > .5) f15.g = uf15.g;
else f15.g = mf15.g;
[flatten] if(cu15.b > .5) f15.b = uf15.b;
else f15.b = mf15.b;
s15 += f15/Quantization;
current -= f15;

float3 cu16 = current+f16;
float3 mf16 = -f16;
float3 uf16 = 1.-f16;
[flatten] if(cu16.r > .5) f16.r = uf16.r;
else f16.r = mf16.r;
[flatten] if(cu16.g > .5) f16.g = uf16.g;
else f16.g = mf16.g;
[flatten] if(cu16.b > .5) f16.b = uf16.b;
else f16.b = mf16.b;
s16 += f16/Quantization;
//current -= f16;

[flatten] if(n.y > .75) {
[flatten] if(n.x > .75) return s7.rgbb;
else [flatten] if(n.x > .5) return s8.rgbb;
else [flatten] if(n.x > .25) return s9.rgbb;
else return s10.rgbb;}
else [flatten] if(n.y > .5) {
[flatten] if(n.x > .75) return s6.rgbb;
else [flatten] if(n.x > .5) return s15.rgbb;
else [flatten] if(n.x > .25) return s16.rgbb;
else return s11.rgbb;}
else [flatten] if(n.y > .25) {
[flatten] if(n.x > .75) return s5.rgbb;
else [flatten] if(n.x > .5) return s14.rgbb;
else [flatten] if(n.x > .25) return s13.rgbb;
else return s12.rgbb;}
else {
[flatten] if(n.x > .75) return s4.rgbb;
else [flatten] if(n.x > .5) return s3.rgbb;
else [flatten] if(n.x > .25) return s2.rgbb;
else return s1.rgbb;}
}// (C) 2015 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.

// 3×3 block-based error diffusion dithering
// This shader can be run as a screen space pixel shader.
// This shader requires compiling with ps_2_a, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader will dither down an image using block-based error diffusion.

#define sa(A, B, C) float3 A = tex2D(s0, tex+float2(B, C)*c1).rgb;
#define Quantization 255.

sampler s0 : register(s0);
float2 c0 : register(c0);
float2 c1 : register(c1);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float2 n = frac(tex*c0/3.);
tex -= (n*3.-.5)*c1;

// original pixels
sa(s1, 0., 0.) sa(s2, 1., 0.) sa(s3, 2., 0.)
sa(s8, 0., 1.) sa(s9, 1., 1.) sa(s4, 2., 1.)
sa(s7, 0., 2.) sa(s6, 1., 2.) sa(s5, 2., 2.)

float3 f1 = frac(s1*Quantization);
float3 f2 = frac(s2*Quantization);
float3 f3 = frac(s3*Quantization);
float3 f4 = frac(s4*Quantization);
float3 f5 = frac(s5*Quantization);
float3 f6 = frac(s6*Quantization);
float3 f7 = frac(s7*Quantization);
float3 f8 = frac(s8*Quantization);
float3 f9 = frac(s9*Quantization);

float3 current;
float3 mf1 = -f1;
float3 uf1 = 1.-f1;
[flatten] if(f1.r > .5) f1.r = uf1.r;
else f1.r = mf1.r;
[flatten] if(f1.g > .5) f1.g = uf1.g;
else f1.g = mf1.g;
[flatten] if(f1.b > .5) f1.b = uf1.b;
else f1.b = mf1.b;
s1 += f1/Quantization;
current = -f1;

float3 cu2 = current+f2;
float3 mf2 = -f2;
float3 uf2 = 1.-f2;
[flatten] if(cu2.r > .5) f2.r = uf2.r;
else f2.r = mf2.r;
[flatten] if(cu2.g > .5) f2.g = uf2.g;
else f2.g = mf2.g;
[flatten] if(cu2.b > .5) f2.b = uf2.b;
else f2.b = mf2.b;
s2 += f2/Quantization;
current -= f2;

float3 cu3 = current+f3;
float3 mf3 = -f3;
float3 uf3 = 1.-f3;
[flatten] if(cu3.r > .5) f3.r = uf3.r;
else f3.r = mf3.r;
[flatten] if(cu3.g > .5) f3.g = uf3.g;
else f3.g = mf3.g;
[flatten] if(cu3.b > .5) f3.b = uf3.b;
else f3.b = mf3.b;
s3 += f3/Quantization;
current -= f3;

float3 cu4 = current+f4;
float3 mf4 = -f4;
float3 uf4 = 1.-f4;
[flatten] if(cu4.r > .5) f4.r = uf4.r;
else f4.r = mf4.r;
[flatten] if(cu4.g > .5) f4.g = uf4.g;
else f4.g = mf4.g;
[flatten] if(cu4.b > .5) f4.b = uf4.b;
else f4.b = mf4.b;
s4 += f4/Quantization;
current -= f4;

float3 cu5 = current+f5;
float3 mf5 = -f5;
float3 uf5 = 1.-f5;
[flatten] if(cu5.r > .5) f5.r = uf5.r;
else f5.r = mf5.r;
[flatten] if(cu5.g > .5) f5.g = uf5.g;
else f5.g = mf5.g;
[flatten] if(cu5.b > .5) f5.b = uf5.b;
else f5.b = mf5.b;
s5 += f5/Quantization;
current -= f5;

float3 cu6 = current+f6;
float3 mf6 = -f6;
float3 uf6 = 1.-f6;
[flatten] if(cu6.r > .5) f6.r = uf6.r;
else f6.r = mf6.r;
[flatten] if(cu6.g > .5) f6.g = uf6.g;
else f6.g = mf6.g;
[flatten] if(cu6.b > .5) f6.b = uf6.b;
else f6.b = mf6.b;
s6 += f6/Quantization;
current -= f6;

float3 cu7 = current+f7;
float3 mf7 = -f7;
float3 uf7 = 1.-f7;
[flatten] if(cu7.r > .5) f7.r = uf7.r;
else f7.r = mf7.r;
[flatten] if(cu7.g > .5) f7.g = uf7.g;
else f7.g = mf7.g;
[flatten] if(cu7.b > .5) f7.b = uf7.b;
else f7.b = mf7.b;
s7 += f7/Quantization;
current -= f7;

float3 cu8 = current+f8;
float3 mf8 = -f8;
float3 uf8 = 1.-f8;
[flatten] if(cu8.r > .5) f8.r = uf8.r;
else f8.r = mf8.r;
[flatten] if(cu8.g > .5) f8.g = uf8.g;
else f8.g = mf8.g;
[flatten] if(cu8.b > .5) f8.b = uf8.b;
else f8.b = mf8.b;
s8 += f8/Quantization;
current -= f8;

float3 cu9 = current+f9;
float3 mf9 = -f9;
float3 uf9 = 1.-f9;
[flatten] if(cu9.r > .5) f9.r = uf9.r;
else f9.r = mf9.r;
[flatten] if(cu9.g > .5) f9.g = uf9.g;
else f9.g = mf9.g;
[flatten] if(cu9.b > .5) f9.b = uf9.b;
else f9.b = mf9.b;
s9 += f9/Quantization;
//current -= f9;

[flatten] if(n.y > 2./3.) {
[flatten] if(n.x > 2./3.) return s5.rgbb;
else [flatten] if(n.x > 1./3.) return s6.rgbb;
else return s7.rgbb;}
else [flatten] if(n.y > 1./3.) {
[flatten] if(n.x > 2./3.) return s4.rgbb;
else [flatten] if(n.x > 1./3.) return s9.rgbb;
else return s8.rgbb;}
else {
[flatten] if(n.x > 2./3.) return s3.rgbb;
else [flatten] if(n.x > 1./3.) return s2.rgbb;
else return s1.rgbb;}
}

JanWillem32

19th October 2015, 19:11

For the fans of the 8-bit mode, here's a ditherer specifically to render with 256 colors:// (C) 2015 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.

// 5×5 block-based error diffusion dithering to 256-color mode
// This shader can be run as a screen space pixel shader.
// This shader requires compiling with ps_2_b, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader will dither down an image using block-based error diffusion to 256 color mode.

#define sa(A, B, C) float3 A = tex2D(s0, tex+float2(B, C)*c1).rgb;
#define QuantizationRed 7.
#define QuantizationGreen 7.
#define QuantizationBlue 3.

static const float3 Quantization = float3(QuantizationRed, QuantizationGreen, QuantizationBlue);
sampler s0 : register(s0);
float2 c0 : register(c0);
float2 c1 : register(c1);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float2 n = frac(tex*c0*.2);
tex -= (n*5.-.5)*c1;

// original pixels
sa(s1, 0., 0.) sa(s2, 1., 0.) sa(s3, 2., 0.) sa(s4, 3., 0.) sa(s5, 4., 0.)
sa(s16, 0., 1.) sa(s17, 1., 1.) sa(s18, 2., 1.) sa(s19, 3., 1.) sa(s6, 4., 1.)
sa(s15, 0., 2.) sa(s24, 1., 2.) sa(s25, 2., 2.) sa(s20, 3., 2.) sa(s7, 4., 2.)
sa(s14, 0., 3.) sa(s23, 1., 3.) sa(s22, 2., 3.) sa(s21, 3., 3.) sa(s8, 4., 3.)
sa(s13, 0., 4.) sa(s12, 1., 4.) sa(s11, 2., 4.) sa(s10, 3., 4.) sa(s9, 4., 4.)

float3 f1 = frac(s1*Quantization);
float3 f2 = frac(s2*Quantization);
float3 f3 = frac(s3*Quantization);
float3 f4 = frac(s4*Quantization);
float3 f5 = frac(s5*Quantization);
float3 f6 = frac(s6*Quantization);
float3 f7 = frac(s7*Quantization);
float3 f8 = frac(s8*Quantization);
float3 f9 = frac(s9*Quantization);
float3 f10 = frac(s10*Quantization);
float3 f11 = frac(s11*Quantization);
float3 f12 = frac(s12*Quantization);
float3 f13 = frac(s13*Quantization);
float3 f14 = frac(s14*Quantization);
float3 f15 = frac(s15*Quantization);
float3 f16 = frac(s16*Quantization);
float3 f17 = frac(s17*Quantization);
float3 f18 = frac(s18*Quantization);
float3 f19 = frac(s19*Quantization);
float3 f20 = frac(s20*Quantization);
float3 f21 = frac(s21*Quantization);
float3 f22 = frac(s22*Quantization);
float3 f23 = frac(s23*Quantization);
float3 f24 = frac(s24*Quantization);
float3 f25 = frac(s25*Quantization);

float3 current;
float3 mf1 = -f1;
float3 uf1 = 1.-f1;
[flatten] if(f1.r > .5) f1.r = uf1.r;
else f1.r = mf1.r;
[flatten] if(f1.g > .5) f1.g = uf1.g;
else f1.g = mf1.g;
[flatten] if(f1.b > .5) f1.b = uf1.b;
else f1.b = mf1.b;
s1 += f1/Quantization;
current = -f1;

float3 cu2 = current+f2;
float3 mf2 = -f2;
float3 uf2 = 1.-f2;
[flatten] if(cu2.r > .5) f2.r = uf2.r;
else f2.r = mf2.r;
[flatten] if(cu2.g > .5) f2.g = uf2.g;
else f2.g = mf2.g;
[flatten] if(cu2.b > .5) f2.b = uf2.b;
else f2.b = mf2.b;
s2 += f2/Quantization;
current -= f2;

float3 cu3 = current+f3;
float3 mf3 = -f3;
float3 uf3 = 1.-f3;
[flatten] if(cu3.r > .5) f3.r = uf3.r;
else f3.r = mf3.r;
[flatten] if(cu3.g > .5) f3.g = uf3.g;
else f3.g = mf3.g;
[flatten] if(cu3.b > .5) f3.b = uf3.b;
else f3.b = mf3.b;
s3 += f3/Quantization;
current -= f3;

float3 cu4 = current+f4;
float3 mf4 = -f4;
float3 uf4 = 1.-f4;
[flatten] if(cu4.r > .5) f4.r = uf4.r;
else f4.r = mf4.r;
[flatten] if(cu4.g > .5) f4.g = uf4.g;
else f4.g = mf4.g;
[flatten] if(cu4.b > .5) f4.b = uf4.b;
else f4.b = mf4.b;
s4 += f4/Quantization;
current -= f4;

float3 cu5 = current+f5;
float3 mf5 = -f5;
float3 uf5 = 1.-f5;
[flatten] if(cu5.r > .5) f5.r = uf5.r;
else f5.r = mf5.r;
[flatten] if(cu5.g > .5) f5.g = uf5.g;
else f5.g = mf5.g;
[flatten] if(cu5.b > .5) f5.b = uf5.b;
else f5.b = mf5.b;
s5 += f5/Quantization;
current -= f5;

float3 cu6 = current+f6;
float3 mf6 = -f6;
float3 uf6 = 1.-f6;
[flatten] if(cu6.r > .5) f6.r = uf6.r;
else f6.r = mf6.r;
[flatten] if(cu6.g > .5) f6.g = uf6.g;
else f6.g = mf6.g;
[flatten] if(cu6.b > .5) f6.b = uf6.b;
else f6.b = mf6.b;
s6 += f6/Quantization;
current -= f6;

float3 cu7 = current+f7;
float3 mf7 = -f7;
float3 uf7 = 1.-f7;
[flatten] if(cu7.r > .5) f7.r = uf7.r;
else f7.r = mf7.r;
[flatten] if(cu7.g > .5) f7.g = uf7.g;
else f7.g = mf7.g;
[flatten] if(cu7.b > .5) f7.b = uf7.b;
else f7.b = mf7.b;
s7 += f7/Quantization;
current -= f7;

float3 cu8 = current+f8;
float3 mf8 = -f8;
float3 uf8 = 1.-f8;
[flatten] if(cu8.r > .5) f8.r = uf8.r;
else f8.r = mf8.r;
[flatten] if(cu8.g > .5) f8.g = uf8.g;
else f8.g = mf8.g;
[flatten] if(cu8.b > .5) f8.b = uf8.b;
else f8.b = mf8.b;
s8 += f8/Quantization;
current -= f8;

float3 cu9 = current+f9;
float3 mf9 = -f9;
float3 uf9 = 1.-f9;
[flatten] if(cu9.r > .5) f9.r = uf9.r;
else f9.r = mf9.r;
[flatten] if(cu9.g > .5) f9.g = uf9.g;
else f9.g = mf9.g;
[flatten] if(cu9.b > .5) f9.b = uf9.b;
else f9.b = mf9.b;
s9 += f9/Quantization;
current -= f9;

float3 cu10 = current+f10;
float3 mf10 = -f10;
float3 uf10 = 1.-f10;
[flatten] if(cu10.r > .5) f10.r = uf10.r;
else f10.r = mf10.r;
[flatten] if(cu10.g > .5) f10.g = uf10.g;
else f10.g = mf10.g;
[flatten] if(cu10.b > .5) f10.b = uf10.b;
else f10.b = mf10.b;
s10 += f10/Quantization;
current -= f10;

float3 cu11 = current+f11;
float3 mf11 = -f11;
float3 uf11 = 1.-f11;
[flatten] if(cu11.r > .5) f11.r = uf11.r;
else f11.r = mf11.r;
[flatten] if(cu11.g > .5) f11.g = uf11.g;
else f11.g = mf11.g;
[flatten] if(cu11.b > .5) f11.b = uf11.b;
else f11.b = mf11.b;
s11 += f11/Quantization;
current -= f11;

float3 cu12 = current+f12;
float3 mf12 = -f12;
float3 uf12 = 1.-f12;
[flatten] if(cu12.r > .5) f12.r = uf12.r;
else f12.r = mf12.r;
[flatten] if(cu12.g > .5) f12.g = uf12.g;
else f12.g = mf12.g;
[flatten] if(cu12.b > .5) f12.b = uf12.b;
else f12.b = mf12.b;
s12 += f12/Quantization;
current -= f12;

float3 cu13 = current+f13;
float3 mf13 = -f13;
float3 uf13 = 1.-f13;
[flatten] if(cu13.r > .5) f13.r = uf13.r;
else f13.r = mf13.r;
[flatten] if(cu13.g > .5) f13.g = uf13.g;
else f13.g = mf13.g;
[flatten] if(cu13.b > .5) f13.b = uf13.b;
else f13.b = mf13.b;
s13 += f13/Quantization;
current -= f13;

float3 cu14 = current+f14;
float3 mf14 = -f14;
float3 uf14 = 1.-f14;
[flatten] if(cu14.r > .5) f14.r = uf14.r;
else f14.r = mf14.r;
[flatten] if(cu14.g > .5) f14.g = uf14.g;
else f14.g = mf14.g;
[flatten] if(cu14.b > .5) f14.b = uf14.b;
else f14.b = mf14.b;
s14 += f14/Quantization;
current -= f14;

float3 cu15 = current+f15;
float3 mf15 = -f15;
float3 uf15 = 1.-f15;
[flatten] if(cu15.r > .5) f15.r = uf15.r;
else f15.r = mf15.r;
[flatten] if(cu15.g > .5) f15.g = uf15.g;
else f15.g = mf15.g;
[flatten] if(cu15.b > .5) f15.b = uf15.b;
else f15.b = mf15.b;
s15 += f15/Quantization;
current -= f15;

float3 cu16 = current+f16;
float3 mf16 = -f16;
float3 uf16 = 1.-f16;
[flatten] if(cu16.r > .5) f16.r = uf16.r;
else f16.r = mf16.r;
[flatten] if(cu16.g > .5) f16.g = uf16.g;
else f16.g = mf16.g;
[flatten] if(cu16.b > .5) f16.b = uf16.b;
else f16.b = mf16.b;
s16 += f16/Quantization;
current -= f16;

float3 cu17 = current+f17;
float3 mf17 = -f17;
float3 uf17 = 1.-f17;
[flatten] if(cu17.r > .5) f17.r = uf17.r;
else f17.r = mf17.r;
[flatten] if(cu17.g > .5) f17.g = uf17.g;
else f17.g = mf17.g;
[flatten] if(cu17.b > .5) f17.b = uf17.b;
else f17.b = mf17.b;
s17 += f17/Quantization;
current -= f17;

float3 cu18 = current+f18;
float3 mf18 = -f18;
float3 uf18 = 1.-f18;
[flatten] if(cu18.r > .5) f18.r = uf18.r;
else f18.r = mf18.r;
[flatten] if(cu18.g > .5) f18.g = uf18.g;
else f18.g = mf18.g;
[flatten] if(cu18.b > .5) f18.b = uf18.b;
else f18.b = mf18.b;
s18 += f18/Quantization;
current -= f18;

float3 cu19 = current+f19;
float3 mf19 = -f19;
float3 uf19 = 1.-f19;
[flatten] if(cu19.r > .5) f19.r = uf19.r;
else f19.r = mf19.r;
[flatten] if(cu19.g > .5) f19.g = uf19.g;
else f19.g = mf19.g;
[flatten] if(cu19.b > .5) f19.b = uf19.b;
else f19.b = mf19.b;
s19 += f19/Quantization;
current -= f19;

float3 cu20 = current+f20;
float3 mf20 = -f20;
float3 uf20 = 1.-f20;
[flatten] if(cu20.r > .5) f20.r = uf20.r;
else f20.r = mf20.r;
[flatten] if(cu20.g > .5) f20.g = uf20.g;
else f20.g = mf20.g;
[flatten] if(cu20.b > .5) f20.b = uf20.b;
else f20.b = mf20.b;
s20 += f20/Quantization;
current -= f20;

float3 cu21 = current+f21;
float3 mf21 = -f21;
float3 uf21 = 1.-f21;
[flatten] if(cu21.r > .5) f21.r = uf21.r;
else f21.r = mf21.r;
[flatten] if(cu21.g > .5) f21.g = uf21.g;
else f21.g = mf21.g;
[flatten] if(cu21.b > .5) f21.b = uf21.b;
else f21.b = mf21.b;
s21 += f21/Quantization;
current -= f21;

float3 cu22 = current+f22;
float3 mf22 = -f22;
float3 uf22 = 1.-f22;
[flatten] if(cu22.r > .5) f22.r = uf22.r;
else f22.r = mf22.r;
[flatten] if(cu22.g > .5) f22.g = uf22.g;
else f22.g = mf22.g;
[flatten] if(cu22.b > .5) f22.b = uf22.b;
else f22.b = mf22.b;
s22 += f22/Quantization;
current -= f22;

float3 cu23 = current+f23;
float3 mf23 = -f23;
float3 uf23 = 1.-f23;
[flatten] if(cu23.r > .5) f23.r = uf23.r;
else f23.r = mf23.r;
[flatten] if(cu23.g > .5) f23.g = uf23.g;
else f23.g = mf23.g;
[flatten] if(cu23.b > .5) f23.b = uf23.b;
else f23.b = mf23.b;
s23 += f23/Quantization;
current -= f23;

float3 cu24 = current+f24;
float3 mf24 = -f24;
float3 uf24 = 1.-f24;
[flatten] if(cu24.r > .5) f24.r = uf24.r;
else f24.r = mf24.r;
[flatten] if(cu24.g > .5) f24.g = uf24.g;
else f24.g = mf24.g;
[flatten] if(cu24.b > .5) f24.b = uf24.b;
else f24.b = mf24.b;
s24 += f24/Quantization;
current -= f24;

float3 cu25 = current+f25;
float3 mf25 = -f25;
float3 uf25 = 1.-f25;
[flatten] if(cu25.r > .5) f25.r = uf25.r;
else f25.r = mf25.r;
[flatten] if(cu25.g > .5) f25.g = uf25.g;
else f25.g = mf25.g;
[flatten] if(cu25.b > .5) f25.b = uf25.b;
else f25.b = mf25.b;
s25 += f25/Quantization;
//current -= f25;

[flatten] if(n.y > .8) {
[flatten] if(n.x > .8) return s9.rgbb;
else [flatten] if(n.x > .6) return s10.rgbb;
else [flatten] if(n.x > .4) return s11.rgbb;
else [flatten] if(n.x > .2) return s12.rgbb;
else return s13.rgbb;}
else [flatten] if(n.y > .6) {
[flatten] if(n.x > .8) return s8.rgbb;
else [flatten] if(n.x > .6) return s21.rgbb;
else [flatten] if(n.x > .4) return s22.rgbb;
else [flatten] if(n.x > .2) return s23.rgbb;
else return s14.rgbb;}
else [flatten] if(n.y > .4) {
[flatten] if(n.x > .8) return s7.rgbb;
else [flatten] if(n.x > .6) return s20.rgbb;
else [flatten] if(n.x > .4) return s25.rgbb;
else [flatten] if(n.x > .2) return s24.rgbb;
else return s15.rgbb;}
else [flatten] if(n.y > .2) {
[flatten] if(n.x > .8) return s6.rgbb;
else [flatten] if(n.x > .6) return s19.rgbb;
else [flatten] if(n.x > .4) return s18.rgbb;
else [flatten] if(n.x > .2) return s17.rgbb;
else return s16.rgbb;}
else {
[flatten] if(n.x > .8) return s5.rgbb;
else [flatten] if(n.x > .6) return s4.rgbb;
else [flatten] if(n.x > .4) return s3.rgbb;
else [flatten] if(n.x > .2) return s2.rgbb;
else return s1.rgbb;}
}

JanWillem32

19th October 2015, 19:16

I patched the problem with the pixel shader compiler not being able to compile some complicated shaders. (The two 5×5 shaders above are good examples.)
I optimized some of the (re-)initialization sequences, specifically for the internal pixel shaders.

XRyche

19th October 2015, 22:32

JanWillem32

20th October 2015, 17:44

I made new builds that can utilize the new ditherers. (On top of that these are now capable of running Y'CbCr (trough back-tracking through the mixer output video R'G'B'), LMS, display RGB and display R'G'B' shaders. For example, for the anaglyph 3D shaders getting access to the display R'G'B' stage is important.) The shaders are in the "finalpass replacement" folder of the archives.
The "Enable Color Passtrough Mode" is now separate from the other color management settings and the combination of these settings is now relevant.

XRyche

21st October 2015, 18:00

With the "substitute colour management" shader I am getting two errors when trying to compile. They are : "error X3004: undeclared identifier 'Mm' " and "error X3014: incorrect number of arguments to numeric-type constructor" .

JanWillem32

21st October 2015, 18:09

Those don't matter to the renderer's compiler which sets the M? macros correctly.

XRyche

21st October 2015, 18:19

It's telling me that it failed to compile, so I am lost.

On another note, if I want to use your XLRCAM for LMS colour management scripts I need to place them between the "Substitute colour management" and the "block diffusion dithering" scripts. Is that correct?

JanWillem32

21st October 2015, 18:35

XRyche

21st October 2015, 18:47

The pixel shader compiler user interface doesn't set macros, only the renderer does. If you feed the "substitute color management" shader to the renderer, it will work. Note that color management settings are fed through the macros, so these settings are relevant while compiling the pixel shader. The pixel shader is not automatically updated when color settings change, so if you change settings, re-compile the shader by disabling and re-enabling the post-resize pixel shader stage.

Okay, I think I understand. So every time I change , for instance, the ambient light settings in the internal colour management I need to disable and then enable the post-resize shaders.

The XLRCAM shader needs LMS input. It can work after the initial pass, before resizing, and just after resizing. It should not be placed in RGB or R'G'B' stages.
The display R'G'B' stage in between the "substitute color management" and the "block-based error diffusion dithering" shaders is pretty much only useful to the anaglyph 3D and the "3LCD panel software alignment"-type shaders.

So I chain the shaders in post-resize as follows:

- XLRCAM for LMS
- Substitute colour management
- block error diffusion

Of course disabling the internal coloured random dithering.
This would be correct?

JanWillem32

21st October 2015, 18:49

That would work fine. (Do set the "Enable Color Passtrough Mode" option and optionally one of the color management options.)

JanWillem32

21st October 2015, 18:58

I revised the "substitute color management" shader, as I forgot one line (it only really matters for the 3DLut-enabled mode):// (C) 2015 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.

// substitute color management
// This shader must 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.
// This is a renderer-specific shader.
// To use this shader, set the render options "Color Management" to "Enable Color Passtrough Mode" and "Dithering Levels" to "0 Rounding".
// After this shader one of the dithering shaders must be used.
// Simple display RGB shaders can be injected in the middle of this shader, complicated display R'G'B'-type shaders can be chained in between this shader and the dithering shader
// Don't forget to force re-compiling of this shader when changing renderer color settings.

#if Mc == 1
sampler LUT3Drg : register(s2);
sampler LUT3Db : register(s3);
static const float LUT3Dsize = Ms, unitlength = LUT3Dsize*.875-1., unitlength3 = pow(unitlength, 3);// to allow more chromatic changes to be encoded, the XYZ channels as stored in the LUT are extended by one eighth past the interval [0, 1]
#endif
static const float3x3 mat = transpose(float3x3(
#if Mc == 2
763198626475360358257813253./147994540717374853866816250., -6373975142277374689886058001./1479945407173748538668162500., 221934284697519645976087971./1479945407173748538668162500., -605343464019237999732424841./518184319406495060865758750., 12063681187144308402184664197./5181843194064950608657587500., -828403352886977796202828287./5181843194064950608657587500., 27361298410291889828212027./523137322083995952425108750., -1196635193693957989329923759./5231373220839959524251087500., 6154395430430998615298890989./5231373220839959524251087500.// convert to SMPTE C (NTSC) display RGB
#elif Mc == 3
5889610677243193337436144851./1005872293755806060844662500., -50563246336667155788637763367./10058722937558060608446625000., 1725862501793283022722939857./10058722937558060608446625000., -156299752813513892312443129./118586087319713310233175625., 2972168594434151167364839293./1185860873197133102331756250., -223310193101879141908651753./1185860873197133102331756250., 41217384068187972753550441./995689156108134584983951250., -1937830199233462093713839397./9956891561081345849839512500., 11482547919632928216017847487./9956891561081345849839512500.// convert to EBU 3213 (PAL/SECAM) display RGB
#elif Mc == 1
118340000000./61951306817., -68897700000./61951306817., 12509006817./61951306817., 22981000000./61951306817., 38970700000./61951306817., -393183./61951306817., 0., 0., 1.// convert to XYZ, but keep the white point adaptation that was applied in the initial pass
#else
#ifdef Mm
Mm// convert to display RGB
#else
1., 0., 0., 0., 1., 0., 0., 0., 1.// do no conversion in external pixel shader compilers
#endif
#endif
)
#if Mr
*65535./32767.// restore to full range, first part
#endif
);

sampler s0;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 s1 = tex2D(s0, tex).rgb;// output default pass-trough
s1 = s1.r*mat[0]+s1.g*mat[1]+s1.b*mat[2];// convert to XYZ or display RGB
#if Mr
s1 -= 16384./32767.;// restore to full range, second part
#endif
// simple display RGB shaders can be injected here

s1 = max(0., s1);// discard negative RGB/XYZ values
#if Mc != 1
#ifdef Mg// do no conversion in external pixel shader compilers
s1 = pow(s1, 100./(float(Mg)+100.));// apply non-linear gamma correction
#endif
#endif
#if Mc == 1
float3 dcolor = pow(s1, 1./3.);// apply cube root gamma correction on the XYZ channels
float3 n = dcolor*unitlength;// to allow more chromatic changes to be encoded, the XYZ channels as stored in the LUT are extended by one eighth past the interval [0, 1]
float3 ntrunc = n-frac(n);
float3 ntrunc2 = ntrunc*ntrunc;
float3 lweight = (s1*unitlength3-ntrunc2*ntrunc)/(3.*(ntrunc2+ntrunc)+1.);// do the interpolation in linear space, optimization of (s1-pow(ntrunc/unitlength, 3))/(pow((ntrunc+1.)/unitlength, 3)-pow(ntrunc/unitlength, 3))
dcolor = (ntrunc+lweight)/(LUT3Dsize-1.);
s1 = dcolor*(LUT3Dsize-1.)/LUT3Dsize+.5/LUT3Dsize;// make the sampling position line up with an exact voxel coordinate
s1 = float3(tex3D(LUT3Drg, s1).rg, tex3D(LUT3Db, s1).r);// sample from the LUT3D
#elif Mc == 2 || Mc == 3
s1 = s1.r*float3(21827./85000., -16744./112965., 112./255.)+s1.g*float3(42851./85000., -32872./112965., -65744./178755.)+s1.b*float3(4161./42500., 112./255., -4256./59585.)+(float2(32., 1.)/510.).xyy;// BT.601 R'G'B' to Y'CbCr and compress ranges
s1 = s1.r+float3(0., -25251./73375., 1.772)*s1.g+float3(1.402, -209599./293500., 0.)*s1.b;// BT.601 Y'CbCr to R'G'B'
#elif Mc == 4
s1 = s1.r*float3(77599./425000., -119056./1182945., 112./255.)+s1.g*float3(32631./53125., -133504./394315., -133504./334645.)+s1.b*float3(26353./425000., 112./255., -40432./1003935.)+(float2(32., 1.)/510.).xyy;// BT.709 R'G'B' to Y'CbCr and compress ranges
s1 = s1.r+float3(0., -1674679./8940000., 1.8556)*s1.g+float3(1.5748, -4185031./8940000., 0.)*s1.b;// BT.709 Y'CbCr to R'G'B'
#endif
#if Mr
s1 = s1*32767/65535.+16384/65535.;// convert to limited range
#endif
return s1.rgbb;
}

XRyche

21st October 2015, 19:20

That would work fine. (Do set the "Enable Color Passtrough Mode" option and optionally one of the color management options.)

Done. Thank you for explaining it in detail.

I revised the "substitute color management" shader, as I forgot one line (it only really matters for the 3DLut-enabled mode):// (C) 2015 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.

// substitute color management
// This shader must 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.
// This is a renderer-specific shader.
// To use this shader, set the render options "Color Management" to "Enable Color Passtrough Mode" and "Dithering Levels" to "0 Rounding".
// After this shader one of the dithering shaders must be used.
// Simple display RGB shaders can be injected in the middle of this shader, complicated display R'G'B'-type shaders can be chained in between this shader and the dithering shader
// Don't forget to force re-compiling of this shader when changing renderer color settings.

#if Mc == 1
sampler LUT3Drg : register(s2);
sampler LUT3Db : register(s3);
static const float LUT3Dsize = Ms, unitlength = LUT3Dsize*.875-1., unitlength3 = pow(unitlength, 3);// to allow more chromatic changes to be encoded, the XYZ channels as stored in the LUT are extended by one eighth past the interval [0, 1]
#endif
static const float3x3 mat = transpose(float3x3(
#if Mc == 2
763198626475360358257813253./147994540717374853866816250., -6373975142277374689886058001./1479945407173748538668162500., 221934284697519645976087971./1479945407173748538668162500., -605343464019237999732424841./518184319406495060865758750., 12063681187144308402184664197./5181843194064950608657587500., -828403352886977796202828287./5181843194064950608657587500., 27361298410291889828212027./523137322083995952425108750., -1196635193693957989329923759./5231373220839959524251087500., 6154395430430998615298890989./5231373220839959524251087500.// convert to SMPTE C (NTSC) display RGB
#elif Mc == 3
5889610677243193337436144851./1005872293755806060844662500., -50563246336667155788637763367./10058722937558060608446625000., 1725862501793283022722939857./10058722937558060608446625000., -156299752813513892312443129./118586087319713310233175625., 2972168594434151167364839293./1185860873197133102331756250., -223310193101879141908651753./1185860873197133102331756250., 41217384068187972753550441./995689156108134584983951250., -1937830199233462093713839397./9956891561081345849839512500., 11482547919632928216017847487./9956891561081345849839512500.// convert to EBU 3213 (PAL/SECAM) display RGB
#elif Mc == 1
118340000000./61951306817., -68897700000./61951306817., 12509006817./61951306817., 22981000000./61951306817., 38970700000./61951306817., -393183./61951306817., 0., 0., 1.// convert to XYZ, but keep the white point adaptation that was applied in the initial pass
#else
#ifdef Mm
Mm// convert to display RGB
#else
1., 0., 0., 0., 1., 0., 0., 0., 1.// do no conversion in external pixel shader compilers
#endif
#endif
)
#if Mr
*65535./32767.// restore to full range, first part
#endif
);

sampler s0;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 s1 = tex2D(s0, tex).rgb;// output default pass-trough
s1 = s1.r*mat[0]+s1.g*mat[1]+s1.b*mat[2];// convert to XYZ or display RGB
#if Mr
s1 -= 16384./32767.;// restore to full range, second part
#endif
// simple display RGB shaders can be injected here

s1 = max(0., s1);// discard negative RGB/XYZ values
#if Mc != 1
#ifdef Mg// do no conversion in external pixel shader compilers
s1 = pow(s1, 100./(float(Mg)+100.));// apply non-linear gamma correction
#endif
#endif
#if Mc == 1
float3 dcolor = pow(s1, 1./3.);// apply cube root gamma correction on the XYZ channels
float3 n = dcolor*unitlength;// to allow more chromatic changes to be encoded, the XYZ channels as stored in the LUT are extended by one eighth past the interval [0, 1]
float3 ntrunc = n-frac(n);
float3 ntrunc2 = ntrunc*ntrunc;
float3 lweight = (s1*unitlength3-ntrunc2*ntrunc)/(3.*(ntrunc2+ntrunc)+1.);// do the interpolation in linear space, optimization of (s1-pow(ntrunc/unitlength, 3))/(pow((ntrunc+1.)/unitlength, 3)-pow(ntrunc/unitlength, 3))
dcolor = (ntrunc+lweight)/(LUT3Dsize-1.);
s1 = dcolor*(LUT3Dsize-1.)/LUT3Dsize+.5/LUT3Dsize;// make the sampling position line up with an exact voxel coordinate
s1 = float3(tex3D(LUT3Drg, s1).rg, tex3D(LUT3Db, s1).r);// sample from the LUT3D
#elif Mc == 2 || Mc == 3
s1 = s1.r*float3(21827./85000., -16744./112965., 112./255.)+s1.g*float3(42851./85000., -32872./112965., -65744./178755.)+s1.b*float3(4161./42500., 112./255., -4256./59585.)+(float2(32., 1.)/510.).xyy;// BT.601 R'G'B' to Y'CbCr and compress ranges
s1 = s1.r+float3(0., -25251./73375., 1.772)*s1.g+float3(1.402, -209599./293500., 0.)*s1.b;// BT.601 Y'CbCr to R'G'B'
#elif Mc == 4
s1 = s1.r*float3(77599./425000., -119056./1182945., 112./255.)+s1.g*float3(32631./53125., -133504./394315., -133504./334645.)+s1.b*float3(26353./425000., 112./255., -40432./1003935.)+(float2(32., 1.)/510.).xyy;// BT.709 R'G'B' to Y'CbCr and compress ranges
s1 = s1.r+float3(0., -1674679./8940000., 1.8556)*s1.g+float3(1.5748, -4185031./8940000., 0.)*s1.b;// BT.709 Y'CbCr to R'G'B'
#endif
#if Mr
s1 = s1*32767/65535.+16384/65535.;// convert to limited range
#endif
return s1.rgbb;
}

It's compiling just fine now. No errors.

I am not seeing any discernible grid patterns at all now with the 5x5 dithering shader. I'll use the same file I used when I saw the grid pattern in darker areas before and check again.
I assume I was seeing the pattern in the first place because I wasn't using the substitute colour management script and colour passthrough mode on the last build.

XRyche

21st October 2015, 19:25

I just checked. I can't see any pattern at all when sitting right at my monitor using 5x5 block error diffusion dithering even in the dark areas where I was seeing it before. It looks very nice. You made some changes to the OSD graphs and progress D3D FS progress bar as well recently, didn't you?

JanWillem32

21st October 2015, 19:43

No, they're the same. I just don't have a post-OSD/subtitles/stats screen shader slot. The colors are wrong because the final pass is missing when you override it with post-resize shaders at the moment.
I should probably re-order the current post-resize shaders to the post-OSD/subtitles/stats screen shader slot. I see no harm in that.

XRyche

21st October 2015, 19:49

No, they're the same. I just don't have a post-OSD/subtitles/stats screen shader slot. The colors are wrong because the final pass is missing when you override it with post-resize shaders at the moment.

Ah, that explains it. It's not a big deal. Still is functional and everything else is working as it should.

Hera

21st October 2015, 23:23

Cursor doesn't go away on non-exclusive fullscreen (alt-enter)?

JanWillem32

22nd October 2015, 11:45

Do you know since which version this happens?

JanWillem32

22nd October 2015, 12:00

I already fixed the problem.

XRyche

23rd October 2015, 01:42

Latest build has also seemed to fix the long standing and ever present cursor problem when using D3D FS as well.

The block error diffusion method , at least when using 5x5, has made a huge difference in quality on my 6 bit TN over random-colour dithering. I honestly didn't think it would make such an impact. I expected it would improve quality, at least a little, but not this much. What level of random colour dithering would be comparable to 5x5 block error diffusion dithering?

Anima123

23rd October 2015, 02:26

So I chain the shaders in post-resize as follows:

- XLRCAM for LMS
- Substitute colour management
- block error diffusion

Of course disabling the internal coloured random dithering.
This would be correct?

Mind if you can elaborate in more detail about how to use customized shader and how to chain them?

XRyche

23rd October 2015, 04:41

Mind if you can elaborate in more detail about how to use customized shader and how to chain them?

The shaders I listed were all post process shaders. You want to make sure the "block-based error diffusion shader" is at the very end of the chain. Right before this though, you want the Substitute colour management shader". The only type of shader you would put between these two shader scripts would be a shader that is in the R'G'B' colourspace like JanWilliem32's anaglyph 3D and the "3LCD panel software" that JanWilliem32 mentioned before. To my understanding, the average user shouldn't really have a need to put anything between the "Substitute Colour management" and the"block-based error diffusion" shaders. Any shaders that deal with sharpening or colour controls would always be before these two shaders.

Also just like JanWilliem32 said you have to set Colour Management to "Enable Colour Passthrough Mode" in Renderer Settings.

If you don't put them in the correct order it's not going to work.

I hope this helped. I'm sure JanWilliem32 will be able to better elaborate on how to change these new shaders though.

JanWillem32

23rd October 2015, 11:07

What level of random colour dithering would be comparable to 5x5 block error diffusion dithering?The random ditherer actually is just a noise generator that spans multiple levels to hide banding by heavy noise. Error diffusion dithering is single level (more comparable with the other two single-level ditherers). It's less noisy than any of the ditherers because of its methods.

I hope this helped. I'm sure JanWilliem32 will be able to better elaborate on how to change these new shaders though.You are mostly correct. The only thing missing is that you also have to set the internal ditherer to "0 (Rounding)" to enable the pass-through mode.

Hera

24th October 2015, 03:20

I already fixed the problem.

Almost perfect!

With this new build,

If I move my cursor at least once when in full screen mode - it disappears.

If I don't move my cursor when in full-screen - cursor remains on the screen.

Can anyone reproduce?

Anima123

24th October 2015, 04:51

ts1

24th October 2015, 12:13

4k 60fps vp9 video is very laggy with display stats enabled. It plays the same with or without display stats on tranc mpc-hc. https://www.sendspace.com/file/o0oe5t test video.

Hera

24th October 2015, 16:01

4k 60fps vp9 video is very laggy with display stats enabled. It plays the same with or without display stats on tranc mpc-hc. https://www.sendspace.com/file/o0oe5t test video.
Sam here - lags with stats on.

XRyche

24th October 2015, 20:24

Almost perfect!

With this new build,

If I move my cursor at least once when in full screen mode - it disappears.

If I don't move my cursor when in full-screen - cursor remains on the screen.

Can anyone reproduce?

I can confirm this behavior as well. This only happens in Fullscreen mode not D3D FS mode. In D3D FS the cursor disappears after only a second or two without any user interaction.

JanWillem32

25th October 2015, 20:03

The stats screen of the trunk build uses a method that is less CPU-intensive than mine when text is being shown. I'll take a look at optimizing the text part a bit later on by not using GDI text drawing on every frame. I assume that the problem isn't there in the stats screen mode with only the graph visible?
As for the cursor hiding problem, I can probably copy the D3D FS exclusive mode cursor hiding methods to those of the windowed fullscreen mode. I'll have to test that a bit. But I will not be home for a few days, so have patience.

XRyche

4th November 2015, 02:57

JanWillem32, frame interpolation is the very last step your renderer takes before actually outputting the video, correct?

JanWillem32

4th November 2015, 10:59

No, frame interpolation is in between the pre-resize shaders and the resizing steps since the last few versions.

XRyche

5th November 2015, 06:14

Oh, that explains about a lot of the recent improvements I've been seeing with frame interpolation aliasing artifacts. On well encoded HD media (BD and digital BD files mostly) I can barely see any aliasing artifacts even when sitting right at the monitor. The aliasing artifacts are still there with DVD and well encoded SD files but much more toned down. Even with a little bit of post-resize sharpening (Fine-sharp HLSL script tweaked to work with SD) the aliasing artifacts aren't that bad. Badly encoded or damaged SD files still can have some heavy aliasing artifacts but that is to be expected considering.

JanWillem32

6th November 2015, 19:18

I changed the fullscreen mouse hider, specifically when opening in windowed fullscreen. It's a bit hachish, but it seems to work for me.
I changed the stats screen font drawing system. It should be much faster now.
x64 AVX: http://www.mediafire.com/download/wwkalp293q99thd/mpc-hc64_AVX_tester_im.7z
x64: http://www.mediafire.com/download/ka9773wwgiei3v9/mpc-hc64_tester_im.7z
x86 AVX: http://www.mediafire.com/download/fcdfqjdcd941cr5/mpc-hc_AVX_tester_im.7z
x86 SSE2: http://www.mediafire.com/download/hbxae9muw0312p4/mpc-hc_SSE2_tester_im.7z

ts1

6th November 2015, 20:57

Still same lags. Also with only the graph visible and in D3D fullscreen mode. CPU load is only 75-80% though (100% in stats, trunk mpc-hc 67-72%) and GPU ~20. And with VMR9 player hangs after 1st lag.

Edit: Without stats CPU usage is 65-69%.

XRyche

7th November 2015, 06:31

I only get about a 2% increase, if that, in cpu usage when having the full stats screen enabled. No lags or anything. This is using the modified EVR-CP renderer. GPU increase is negligible if at all when using the full stats and I use a lot of your custom HLSL scripts and Motion adaptive-High motion frame interpolation as well. I'm not having any issues with it at all on my setup and cosmetically it looks the same, which is good.

Hera

7th November 2015, 19:36

I think just having the graph on - no other text lags the output.
Oh and the default resizer now is Mitchel-Natravali Spline 4?

XRyche

8th November 2015, 03:07

Oh and the default resizer now is Mitchel-Natravali Spline 4?

What was the default resizer before? Mitch-Nat Spline 4 does work great for damaged video though :) .

Hera

8th November 2015, 04:57

What was the default resizer before? Mitch-Nat Spline 4 does work great for damaged video though :) .

I thought it was bilinear by default. Hm... now that you ask I am not sure that's correct.

EDIT: And, sadly, cursor doesn't disappear unless moved.

Also, the option menu could use a little dimension tweaking at high DPI though.

JanWillem32

8th November 2015, 22:38

Mitchel-Natravali Spline 4 is indeed the standard resizer. It's a balanced resizer. You can choose Catmull-Rom for sharper images (but with mild anisotropy and ringing artifacts) and B-Spline for more noise resistance (but unsharp images). See https://de.wikipedia.org/wiki/Mitchell-Netravali-Filter for a good overview in German. (The image is quite easy to read. B-spline 4 is on B=1, C=0, Mitchel-Natravali Spline 4 is B=1/3, C=1/3, Catmull-Rom spline is B=0, C=1/2. Robidoux filters are somewhere near Mitchel-Natravali Spline 4 on the dotted line.)
I'll have to experiment some more with the cursor handling code for launching in windowed fullscreen mode, it seems. The problem is, it works properly for me. I don't know I can fix this issue. It's not really code I usually edit at all. (I dislike editing the GUI elements. That also includes editing the menus.)
I can see that the current stats screen method could lag a bit when displaying at 60 frames per second on a 4k screen with high CPU usage. I balanced the CPU/GPU usage compared to the trunk build. (Somewat more CPU usage, less GPU usage.) I mostly wanted to eliminate the dependency on the extra D3D9X library (in the dll).
I'm not familiar with lags in VMR-9 r.. I'll have to test it a bit. ts1, do you have a sample and condition which always seems to get stuck with VMR-9 r.? Note that I didn't change anything timing related in the VMR-9 mixer (it doesn't allow it anyway).

XRyche

8th November 2015, 23:48

I can see that the current stats screen method could lag a bit when displaying at 60 frames per second on a 4k screen with high CPU usage.

Wouldn't that be expected though. Sixty FPS on a 4k screen is no small feat in of itself.

Hera

9th November 2015, 01:18

I have no problems with it. TBH I can't tell the difference between the resizers most of the time.

Well I double click on the video file, micro-pause, MPC launches while I don't move the mouse, then I press ALT-ENTER.

For the better or worse, most issues left are GUI related to me. Like poor HiDPI support, mouse cursor not disappearing, ... I also think I had mouse cursor disappear when over the controls in full screen non-exclusive mode - that shouldn't happen.

CPU usage climbed to ~30% (~25% medium) at 3.2Ghz. Which is a lot for my CPU. Now - I did put my computer on the high performance plan and ... no lag from the stats screen. High performance - 20% to 30% CPU at 3.6Ghz. Using VP90 3840x2160 60fps video clip. Most of the CPU usage is from decoding the video though....

ts1

9th November 2015, 13:49

VMR9 is not affected, this video played once till the end with stats enabled ~the same as on trunk mpc-hc. So lags only with evr custom + stats.
do you have a sample and condition which always seems to get stuck with VMR-9 r.?
Try to disable dxva, set player to lower priority and run 7-zip for example set to high priority on ultra with lzma2, always hangs for me on any video with vmr9 r.

v0lt

14th November 2015, 05:01

@JanWillem32
Do you plan to make a frame downscaling like madVR or VirtualDub (VirtualDub-1.10.4-src.7z\VirtualDub\source\f_resize.vdshaders)?
There is less scale image, the more reference points in the shader.

XRyche

26th November 2015, 22:13

I've ran into a problem with the ISR and the new AMD Crimson Beta Drivers. Entire subtitle lines get skipped unless you set the sub picture buffer to 0. This is with .ass subtitles, I haven't tested with vobsub.

I found a solution to this. If I create a game profile for MPC-HC Ex EVR and set the new shader cache to off, ISR works as it should. It's strange to me though since I don't think the ISR uses any shaders. Oh well, it works so idc.

XRyche

27th December 2015, 02:42

I ran into another ,what I think is a rather unique problem. I just upgraded from a Compaq TFT circa 2007 16:10 (1440x900) monitor to a BenQ GW2255 VA 16:9 (1920x1080) monitor (this is relevant). The problem is whenever I use any post-processing shader when playing any 1080p content the subtitles when in fullscreen, doesn't matter if it's Windowed FS or D3DFS, don't get resized properly when using the ISR. In fact the subtitles usually take up the entire screen and totally obscure the image. This never happened with my old 16:10 monitor because with the default resolution I was always downscaling 1080p content. This also doesn't happen when using an external subtitle renderer like vobsub.

rock

23rd February 2016, 18:09

Is it still on development?

XRyche

23rd February 2016, 22:03

JanWillem32 has been AWOL since early November but he never said he was abandoning it.

XRyche

27th April 2017, 09:48

Well it's been well over a year since JanWillem32 has even posted anything so I suppose it is no longer being developed. I suppose MadVR just made this render seem pointless.

JanWillem32

28th April 2017, 12:59

Sorry that I haven't posted in quite a while.
When I offered to help out with the internal renderers (but mostly EVR CP), I encountered a renderer in such dismal state, that I couldn't bother to try to fix any of its core issues. I made this clear to the development team from pretty much the beginning. I went on to replace the renderer with one I wrote and I continued expanding it. In the mean time I advised on some parts of the main player and made a few patches for some other issues. A few of those were accepted, some were rejected. After a few years of developing, I supposed the renderer section was stable enough to replace the old code in the main player. I stopped making big changes and consulted with the dev team. The subtitle sections could go in as a first patch, then the huge patch changing the internal video renderers and then minor other patches of things I edited along the way. As per usual, I said I don't mind style changes or other minor alterations, but the core video renderer code I worked hard on to get it optimized and organized the way I'm used to will have to go in as is. I asked the dev team to stop making changes to the subtitle and video renderer code and so pave the way for full integration of the new sections.
I was ignored.
For now, the video renderer and subtitle renderer code I wrote is pretty much stable, but due to fact it probably will not be integrated in the main player it is not in active development anymore.
I went on designing and coding other things like I have been for many years already. If the MPC-HC team needs my code, my invitation still stands. Other than that, I'm planning to give the video pixel shader pack an update. It's been a long time since I last took a look at it.
If anyone needs me for anything, I'll be available.

v0lt

29th April 2017, 10:37

@JanWillem32
Can you make a standalone video renderer? Like Haali Video Renderer, but open source.

burfadel

29th April 2017, 11:23

What about MPC-HC BE? It is a separate code path, maybe they'll accept the changes? Admittedly many people use madVR renderer now, but it's good to have options!

clsid

29th April 2017, 12:53

I honestly think the chances are better now to get it integrated. The player is pretty mature now, and development has slowed down. It would be interesting to see a build that is based on current MPC-HC code. With just the core changes and new renderer(s) with same basic featureset as EVR-CP (and VMR9). Then everyone can test it for a while and give their opinion and feedback. Any new and advanced features that you have added should go in at a later stage.

JanWillem32

29th April 2017, 23:12

v0lt, I wouldn't mind making the video renderer section separate, but I do depend a lot on the changes in the custom interfaces for the video renderers.
For example, the pixel shaders in the trunk build were always compiled sequentially in the renderer because of the limitations in the src\SubPic\SubPicAllocatorPresenterImpl.h, CSubPicAllocatorPresenterImpl{}, SetPixelShaders() interface.
The version I wrote looks like this: struct SetPixelShadersInput {
wchar_t const* pwcShader;
size_t upShaderLen;
wchar_t const* pwcLabel;
size_t upLabelLen;
};
// note: SetPixelShaders() guarantees all previous shaders will be cleared, there is no need to call ClearPixelShaders() beforehand
// note: setting 0 shaders in total is legal, but setting pLists to nullptr is not (use ClearPixelShaders() for that purpose)
// note: the caller may completely invalidate pLists and all pointers inside the array immediately after the call
// returned value: 0 for success, 1 for an out of memory error, 2 for not implemented, else the failed shader's SetPixelShadersInput const* from the input array
virtual __declspec(nothrow noalias) uintptr_t SetPixelShaders(SetPixelShadersInput const* pLists, size_t upPreResizeCount, size_t upPostResizeCount)
{...I made the conversion from UTF-16 LE to ANSI for the shader non-null-terminated character sequence and custom shader compiling functions multi-threaded because I could easily do that once I changed the interface and the pixel shader compiler DLLs do support such functionality.
In fact, I changed every single one of the custom interfaces to suit my needs (there were only 15 anyway, so it was easy).
So I would need a custom renderer socket for functions like these. However, I prefer regular integration. Coexistence with the current set of renderers is a bit pointless; I used the original mixer code and added my renderer to it. In the mean time I solved countless of issues, added some functions and tried to solve peoples issues (in this thread, on the tracker an on the MPC-HC IRC channels).
https://trac.mpc-hc.org/query?status=accepted&status=assigned&status=evaluated&status=new&status=reopened&status=reviewing&cc=~janwillem32&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority
https://trac.mpc-hc.org/ticket/3115
https://trac.mpc-hc.org/ticket/2292
Lastly, I would love to see the Haali Video Renderer or another DirectShow video renderer code for its mixer parts, so I wouldn't need VMR-9 or EVR anymore to do the mixing. I always struggled to get a grip on the DirectShow interfaces to get custom mixing parts right unfortunately.

burfadel, it's indeed good to have options. I wouldn't design my video renderers the same way as madVR, and I agree it's good to have some variety. (I did have quite few chats of course with madshi over the years. We certainly don't program in a similar way.)

clsid, it's good to hear that things might have changed since I last checked up upon the MPC-derived dev teams. Maybe I could still be useful after all. About the renderer features; it's do or die. I did not keep around much of the old renderer code, and all I programmed is pretty much incompatible with the old set of renderers. The "new and advanced features" are integral parts of what I've written and will not be a patch of some sort.