MPC-HC tester builds for internal renderer fixes

[nevcairiel]

You could convert to rgb before but you would have to do that in software - so you could as well do so in the decoder or a post processor. Maybe one could teach EVR to do it on the surface somehow, but it would require quite some rewriting (up to some point where it really isnt EVR anymore :))

IHMO, Your best option really is to write your favorite chroma upscaler in C or ASM and let me use it in LAV Video. :)

[nand chan]

You could convert to rgb before but you would have to do that in software - so you could as well do so in the decoder or a post processor. Maybe one could teach EVR to do it on the surface somehow, but it would require quite some rewriting (up to some point where it really isnt EVR anymore :))

IHMO, Your best option really is to write your favorite chroma upscaler in C or ASM and let me use it in LAV Video. :)

Never done graphics processing in ASM though, nor have I really worked with SSE2, the FPU etc. or any of that. x86 ASM is such a mess. I'll have to give it a try sometime though.

Then we'd basically have the best case scenario as far as I'm concerned:

1. LAV Video uses libav to decode the Hi10P source into P010
2. LAV Video uses a nice Mitchell-Netravali upscaler to pull this up to Y416
3. LAV Video uses its matrix information from the source to convert this to R16G16B16 or similar
4. LAV Video dithers this down to X8R8G8B8 RGB32
5. VSFilter paints its subtitles ontop of this RGB32 stream
6. EVR mixer accepts the RGB32 and transfers it to the VRAM as 32-bit floating point
7. all additional post processing, color management, upscaling, shaders etc. etc.

The only weak link in this process would be VSFilter for forcing dithering down to 8 bit, but with the correct algorithms this is basically bit perfect (compared to first post processing, and then dithering).

Edit: Doesn't swscale already have the code for Mitchell-Netravali?

[nevcairiel]

Edit: Doesn't swscale already have the code for Mitchell-Netravali?

It does have a bicubic scaler on which you can adjust the B and C arguments freely, which looks alot like a Mitchell-Netravali filter from all the coefficients used.
I do however not know how well the bitdepth is preserved if i ask it to convert 420p10 to 444p16, for example.

This would require some investigations - also regarding its speed.
Before i do that, what values for B and C would you prefer anyway? Default is B=0, C=0.6

[nand chan]

It does have a bicubic scaler on which you can adjust the B and C arguments freely, which looks alot like a Mitchell-Netravali filter from all the coefficients used.
I do however not know how well the bitdepth is preserved if i ask it to convert 420p10 to 444p16, for example.

This would require some investigations - also regarding its speed.
Before i do that, what values for B and C would you prefer anyway? Default is B=0, C=0.6

I haven't done such extensive testing. I just used whichever values madVR has for that option (which doesn't allow changing the B/C parameters). I doubt I'd notice it much since it's only for chroma information though.

I think it would be better to write a custom implementation (and test it well) before turning to something as large/bloated and dubious (eg. faulty depth algorithms) as swscale.

Edit: I looked at the paper, seems like Mitchell & Netravali recommend 1/3 for both

Edit 2: Seems like swscale is practically too slow for realtime usage when working with 444p10 and similar. It would probably also be best to pull up to 420p16 yourself then just do a conversion from 420p16 to 444p16, if anything. That way you can assure it doesn't do stupid shit or destroy the levels.

[Hera]

/\
Golden audio jacks discussion.

[nand chan]

/\
Golden audio jacks discussion.

When you spend more time tweaking your players and obsessing about quality than you spend actually watching things, these things sort of matter.

Ps. I use golden plated 6.35mm TRS connectors, any smaller should not be used due to the possibility of cross-channel interference.

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

[nevcairiel]

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

I'm on the #mpc-hc channel on freenode

[CruNcher]

When you spend more time tweaking your players and obsessing about quality than you spend actually watching things, these things sort of matter.

Ps. I use golden plated 6.35mm TRS connectors, any smaller should not be used due to the possibility of cross-channel interference.

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

Audiophiles and Videophiles are sometimes good if they involved in the development a good mix of Film Video and Anime Videophiles isn't bad but they should never dictate development goals entirely that would be catastrophic ;)

[Nevilne]

As seen on hydrogenaudio :)

[JanWillem32]

@watchman: I'll take a look at the basic text subtitle renderer later on. Right now I didn't really find the exact code that handles these things. The subtitle renderer code lacks comments, proper file naming and organization unfortunately. I'll have to spend some time to analyze some parts.

@CruNcher: That's a lot better. I've started working on solving the audio issue (it's caused by improper multi-threading). It's a bit hard to do for me since I'm really not used to handling GUI items like the window frames used for the player. For example: the alpha version that allows fast switching from and to exclusive mode messes up the window size when returning to windowed mode. I have no idea why yet. I'll upload a build later to show what I mean (and for some crash testing).

@Matching_Mole: There is an option to override placement for subtitles, but I'm not very sure it will work properly. So far I've even seen that one type of bitmapped subtitle is always stretched to the window size (aspect ratio correction broken).

@cez4r: Thank you for noticing, I would never have guessed issues with registry settings.
The second issue probably needs a bit more analysis, I'll look up which one of the changed items could be causing this.

@Hera: Optimization for the new present mode isn't completely finished yet. The reset initialization in the renderer for resizing a window is fast, but the main window tread takes forever to respond properly and alter the rendering device (just a reset on the software port to the DirectX interface, not the entire graphics driver).
I've noticed the spikes from the subtitle renderer too. When fixing the Alternative VSync item, I've changed the order of where a frame is presented to what it was in the trunk build. I'll change it back once I'm sure that it doesn't break the brittle Alternative VSync function.

@JohnLai: Only when the .idx and .sub combination is external? I'll have to test and see. I did have a few problems getting the blu-ray and VOBSUB renderers to behave properly in a sense of the subtitle renderer's normal read/write schedule. That probably caused it.

@nand chan: The chroma scalers are specialized resizers for 2× height and width. Luma isn't scaled.
After resolving the chroma 'bug', the colorspace is converted to R'G'B' or linear RGB, which is used for general resizing in a later stage. It only applies to ATi at the moment, as both Intel and Nvidia force bilinear filters in the video processor's black box of the VMR and EVR mixers.
At a later stage I'll try to implement a better color space for gamut consistency (XYZ or xyY most probably). For now linear RGB suits the renderer fine. I was already glad to get rid of the gamma distortion.

About the mixers, I'm indeed not very happy with those. If I only knew how to pull a DirectShow or MediaFoundation pin and get raw bits out of it, I would have added a few custom mixer modes a long time ago. Creating working surfaces for the raw data to transfer to is reasonably easy, but I can't find any proper guides on handling pins. Both EVR and VMR obscure it completely, in many cases you can't even get the original stream information properly from the current mixers.
A minor exception to that rule is the DXVA helper device for EVR CP and Sync. It allocates proper NV12 surfaces on the video card, and then throws those into the mixer...

[nand chan]

@nand chan: The chroma scalers are specialized resizers for 2× height and width. Luma isn't scaled.
After resolving the chroma 'bug', the colorspace is converted to R'G'B' or linear RGB, which is used for general resizing in a later stage. It only applies to ATi at the moment, as both Intel and Nvidia force bilinear filters in the video processor's black box of the VMR and EVR mixers.
At a later stage I'll try to implement a better color space for gamut consistency (XYZ or xyY most probably). For now linear RGB suits the renderer fine. I was already glad to get rid of the gamma distortion.

But what's the difference between the 4:2:0 modes and the 4:2:2 modes? Do I have to select the right one based on what input I get? Why can't it do this automatically?

[JanWillem32]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

[nand chan]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

Here are two example builds that can switch between windowed mode and exclusive mode on the fly. Not for general usage. I wonder how I should fix that window?
x86 SSE2: http://www.mediafire.com/?r36sq36676ti432
x64: http://www.mediafire.com/?zv9zjsnwr4whn8o

If you do manage to get this to work somehow (just create your own interface for the same code that the Filters menu uses?), it would make the process trivial, since the required information can simply be pulled from biCompression (or read from pbFormat at offset 0x58, length 4)

Creating working surfaces for the raw data to transfer to is reasonably easy, but I can't find any proper guides on handling pins

Do you know how madVR and Haali's renderer do it? You could probably inspect/mimic/borrow code from those. It would be real nice to see software conversion to RGB32 added to EVR-CP (optional, of course), since that would probably make it the best renderer currently available - especially if it supports 10-bit.

On that matter, does EVR's in-house mixer support X2R10G10B10 input at all?

[CruNcher]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

Here are two example builds that can switch between windowed mode and exclusive mode on the fly. Not for general usage. I wonder how I should fix that window?
x86 SSE2: http://www.mediafire.com/?r36sq36676ti432
x64: http://www.mediafire.com/?zv9zjsnwr4whn8o

Same issues as before (Audio issue @ switching no seamless switching possible) + Black Screen when switching to Exclusive Mode (Audio Plays) (both issues aren't in currently preferred 3752i)

[watchman]

@watchman: I'll take a look at the basic text subtitle renderer later on. Right now I didn't really find the exact code that handles these things. The subtitle renderer code lacks comments, proper file naming and organization unfortunately. I'll have to spend some time to analyze some parts.

Hi. I tried to take a look at the source code and I was able to find it pretty quick and also modify it to my needs since it didn't require any special technical knowledge. So you don't have to bother with it anymore. Anyway, thank you for being willing to help :thanks:

I think it would be good if this little modification can find its way to official repository so everyone can benefit from it. I uploaded new source file so you can quickly see changes using some diff sw: http://www.mediafire.com/?43wvyuuuym85g50 (for quicker orientation I added comment lines above every change I did //watchman modification)

I also did one more little improvement, which I think is also very nice (also contains //watchman flag). Its purpose is to not use bottom positioning value if aspect ratio is bigger then 2.0f. Reason of this is to not have subtitles too low if watching video with aspect ratio like 16:9, but also not have subtitles too high if watching movie with cinematic aspect ratio :D

The thing is that hardcorer number like this is not very universal and there might be someone who wants to use different ratio outline, which will better suit his display needs. But unfortunately I'm not really into this old school C++ GUI stuff so I'm not able to do it by myself.

[nand chan]

JanWillem32, can you give me a more detailed explanation of what the pre-resize and post-resize shaders should input/output? eg. something like:

Pre-resize shaders:
Input primaries:
Input gamma curve:
Input white point:
Input value range:
Output primaries:
Output gamma curve:
Output white point:
Output value range:

Post-resize shaders:
Input primaries:
Input gamma curve:
Input white point:
Input value range:
Output primaries:
Output gamma curve:
Output white point:
Output value range:

[Matching_Mole]

@Matching_Mole: There is an option to override placement for subtitles, but I'm not very sure it will work properly. So far I've even seen that one type of bitmapped subtitle is always stretched to the window size (aspect ratio correction broken).

I use regular MPC-HC version with this option activated since ages and, if it works perfectly with text based subtitles, it do not works with bitmap based subtitles... at least the ones from DVD and Blu-ray (I do not use *.idx and *.sub ones).

[janos666]

@ JanWillem32,

I think there is a problem with the PC->TV shader which you integrated into your MPC-HC builds: click (http://forum.doom9.org/showpost.php?p=1532287&postcount=19)

Your method tries to do something about the different Y and Cb,Cr ranges but it fails. The bright primary colors have huge luminance errors (I think they would be C=240 if there were no rounding/clipping errors but they should be 235).

I am sure it's the PC->TV shader because:
1: I was always suspicious about it,
2: I couldn't find any problems when I don't use it: the upper three color values are always 251,253,255 for all primary colors and 0-0 for the other channels, so they are clipped properly and there is no difference between the individual channels.

[janos666]

And with your latest SSE2 build, I do have the "soup opera effect" (and some disturbing artifacts, something like a smooth "false contouring") with the Basic motion interpolation method, but the Precise methods still refuse to do anything.
My GPU switches to "DXAV clocks" when I start the playback and the GPU utilization is almost zero, even with a running Basic motion interpolation.

What do you think about an interpolation like this?
A-A-AB-B-B-BC-C-C-... where AB is an interpolated frame between the A and B frames.
This way we could spare ourselves from the "soup opera effect" and spare the GPU from some processing (or use that processing power to do more advanced interpolation...) and hopefully minimize the possibility of the noticeable artifacts (less interpolated frames = less place for errors and less probability of the detection of the interpolation errors).

[Hera]

I noticed that, in the main MPC thread, someone called you out on not buffering subtitles - whats up with that?

Also, the very latest build fails D3DFS.

[ADude]

Can Jan - or someone else - summarize that actual visual benefits - from the changes in the code that are described in the first post in the thread ?

Thanks !

[golagoda]

Can Jan - or someone else - summarize that actual visual benefits - from the changes in the code that are described in the first post in the thread ?

Thanks !

I'll put it this way - the things that have been improved, have improved. EVR still takes precise setting up to get right, and these builds can sometimes break features (Keep in mind that this is the latest trunk version, and then on top of that it's edited), but it's still better than the normal MPC-HC.

I personally don't even use EVR most of the time, I just use these for the internal subtitle renderer improvements, SSE2 optimisations and that it's based off the trunk MPC-HC, so it's very up to date and I can't be bothered getting the trunk versions from that xvidvideo.ru site or whatever it is, or getting visual studio to compile it myself

[ADude]

I'll put it this way - the things that have been improved, have improved. EVR still takes precise setting up to get right, and these builds can sometimes break features (Keep in mind that this is the latest trunk version, and then on top of that it's edited), but it's still better than the normal MPC-HC.

I personally don't even use EVR most of the time, I just use these for the internal subtitle renderer improvements, SSE2 optimisations and that it's based off the trunk MPC-HC, so it's very up to date and I can't be bothered getting the trunk versions from that xvidvideo.ru site or whatever it is, or getting visual studio to compile it myself

Other than subtitles, are these improvements anything that would improve the video watching experience, and if so, how ?

(I understand that performance and efficiency are important in the long-run and are laudable goals, but that is not what I am asking about in this question, thanks.)

[CruNcher]

@ Jan
Potplayers Direct3D9 Renderer seems to be very efficient (1080p) it's like 30% GPU for MPC-HCs (EVR-CP) and 8% for Potplayers Direct3D9 renderer with DXVA (Renderless and 1 time Native which increases CPU a little from 3% to 9% for Potplayer but holds GPU @ a whopping 8%)
Hmm it looks promising if they can get Shader support working on it :) (MadVR lowest GPU i could get was 17%).

Also Mirillis Custom Renderer used in Splash Player looks very interesting (from a Performance view) though they even have PS support with the same low GPU (when PS disabled).that Potplayers Direct3D9 Renderer provides

http://img254.imageshack.us/img254/5725/mpchcevrcpvspotd3d9.png

[toniash]

@cruncher
How to use Pixel Shaders with Mirillis Splash Player?

[CruNcher]

toniash Detail Boost http://downloadmirillis.com/gfx/clips/DetailBoostDemo01.swf?scale=noscale&tag1=Mirillis%20DetailBoost if im not wrong it's a PS (im not 100% sure though) :)

[toniash]

tohiash Detail Boost if im not wrong it's a PS (im not 100% sure though) :)

It must be if it increases GPU use, I haven't tried

[CruNcher]

not essentialy it could also be a OpenCL or Direct Compute implementation but most probably it isn't (because of hardware interoperability reasons and GPU reach without needing to fall back to Software) ;)

[Keiyakusha]

toniash Detail Boost http://downloadmirillis.com/gfx/clips/DetailBoostDemo01.swf?scale=noscale&tag1=Mirillis%20DetailBoost if im not wrong it's a PS (im not 100% sure though) :)

It looks more like they mislabeled these 2 photos. Sharper one is an original and other one is last.blur().blur() :D

[JanWillem32]

It's certainly busy here. I'm sorry that I can't really go in-depth right now. I'm very busy, because I have exams coming up (which I'll probably fail, as usual).
A nice bonus of the last few days was the big change in internal codecs. I'll need time to test all of that.
I'll try to go over the responses briefly, starting from #564.

@nand chan: I'd love to take a look at mixer code and then copy it 1:1, as the current mixer handlers are pretty much hollow shells for loading external DLL files. I've searched for this kind of code before, but couldn't find anything to import. I'm not going to read the entire DirectShow standards to completely custom write this kind of code.
Software conversion to RGB32 is available in both VMR-9 and EVR, and both are dead slow at it (no support for formats over 8-bit RGB output, either). The mixer that uses the video card is a lot more flexible.
A2R10G10B10 will probably be accepted, but EVR isn't exactly good at doing RGB to RGB conversion from DirectShow to working surfaces. I've ranked the RGB formats as the very lowest for the mixer, mostly for that reason.

@CruNcher: The test type was only different in handling the switching between windowed mode and exclusive mode on the fly. It wasn't really good at it, but it was possible (for most). I've kept some parts of that code and I'll try to fully implement such a function later on.

@watchman: How nice that you could find the target code. Maybe you have a knack for working with code like that. :) We can definitely integrate new functions into the trunk build, as long as it involves individual patches. I was already planning to submit some of my previous patches once I have some more time again. These can be added as well, but you might be able to persuade another developer to help sooner. To work out descriptive comments, GUI items and such, try the MPC-HC IRC channel and ask, else you can post on trac. Please keep me informed when I get back to developing. I'd love to help out properly when I can.

@nand chan: The pre-resize shaders can be used to convert to a working format, similar to the integrated initial pass section. The pack's set of color controls (also included with the chroma interpolators) are a good example of this.
The post-resize shaders are mostly for effects at window resolution. Preparation for display output is property of the final pass section. It's the only spot where such changes won't interfere with the rest of the filter chain.

@Matching_Mole: So it's the same with all bitmapped subtitles... I'll have a look at all four variants, then.

@janos666: I'll try to make a release build that doesn't have the clipping problem while nearest neighbor filtering is active. (It's already fixed it in an intermediate debug type.) Let's try to find the right function after that.

The basic interpolation method lacks any artifact cleanup, that's the main reason for the false contouring on items two frames earlier or later (can be seen clearly for a moment when pausing). It's pretty normal that it doesn't take much processing. The function is integral with the final pass (it doesn't add another filtering pass) and the code is pretty small and efficient.
I'm still looking at making additional frame interpolation modes and refining the current ones, but I haven't seen any good code resources on this yet, unfortunately.
Interpolation exactly in between two frames still has many artifacts with the methods I've currently implemented. I've been reading a bit about deinterlacing technology to see if there's a trick to it. (Not much progress so far.)
If anyone can find basic math or programming on frame interpolation or deinterlacing techniques, I'll happily take a look at integrating it.

@Hera: The buffer works fine. The execution order for rendering items in the paint was better the way it was before I started to fix Alternative VSync a few builds ago, though.

@ADude: I've mostly been trying to boost efficiency, before even trying to integrate filters/settings/stages that can improve quality. There's still a lot to do, though.

@golagoda: Indeed, a varied tester community is the best to quickly find various problems in the items I edit. Especially with the video renderer and DXVA related items, as various systems react in various ways to code in there.

@ADude: I've added a few extra resizer filters (and I really need to add some more), I've integrated some extra filters in the renderer settings menu and people can always insert a custom pixel shader (or copy one of mine).

@CruNcher: A custom mixer and a basic StretchRect will consume a lot less than a big video processing chain (with EVR and VMR-9 as added weight). I'd love to take a look at how they did it code-wise, maybe I can learn a thing or two from that.

I'll skip the last few posts, and go to bed next... I really wasn't planning on staying up this late today (2 a.m. here).

[Qaq]

Jan, good luck with exams.

[nand chan]

@nand chan: The pre-resize shaders can be used to convert to a working format, similar to the integrated initial pass section. The pack's set of color controls (also included with the chroma interpolators) are a good example of this.
The post-resize shaders are mostly for effects at window resolution. Preparation for display output is property of the final pass section. It's the only spot where such changes won't interfere with the rest of the filter chain.

You seem to have misunderstood my questions. What is the set of standards for primary information / gamma / white point etc. that the texture is expected to have at each position?

For example madVR outputs data with the primaries given by the .3dlut's params, and chromatic adaption to its white point, with the gamma being fixed at 2.3 pure power into its internal .3dlut, and expects fully gamma encoded output values.

What does EVR-CP input/expect?

[JanWillem32]

http://msdn.microsoft.com/en-us/library/bb970322%28v=vs.85%29.aspx
But really, range expansion and a Y'CbCr-to-R'G'B' matrix is the only thing truly applied: http://msdn.microsoft.com/en-us/library/ms698715%28v=vs.85%29.aspx .
For the custom renderer code;
In 8-bit mode, only resizing is applied by default (for compatibility and performance, not for quality). The other modes apply a 2.4 power (with safeguard for negative values) on the video input and subtitle blend step, and invert it again in the final pass.
The color management can automatically detect from the input video if a NTSC, PAL or HD R'G'B'-to-R'G'B' LUT is needed.

@Qaq: Thank you, I'll probably need it.

[JanWillem32]

I've tried to apply a few little changes quickly to patch a few issues. I'll have to fix a few more things when I have more time.
I'll work on switching the exclusive mode on the fly later on. It's disabled for now, but if anyone can help coding it, I would be very grateful.
I fixed the external sub/idx items (wrong handling of time codes, my mistake).
I reverted frame present order to what it was a few versions ago. I changed the order for the latest few versions for a few alternative VSync fixes, but I didn't like how the subtitle renderer reacted (paint times too high). Alternative VSync and flushing functions will need re-evaluation for if these can work with this placement (but so far it seems to work the same as before).
The nearest neighbor resizer had a range clamping issue. Turning it into a pixel shader is somewhat unusual, but it works fine now.

[tetsuo55]

@janwillem32: Recommended reading and likely to speed up commit of your changes to trunk: http://itscommonsensestupid.blogspot.com/2008/11/working-effectively-with-legacy-code.html

[CruNcher]

@jan
i still prefer dfr3752i (i think it's a good idea to use it as reference) result wise it's the most stable with the new (EVR-CP) render idea currently, though i can only speak currently for 1 Hardware OS scenario which would be Win7 with Intel Sandy Bridge dunno how it looks for Nvidia and AMD.
dfr3787i has a long black phase now (audio off,video off) @ switching therefore it recovers instantly after it (jitter) most of the times (not always) though it still likes to crash (closing a file while it's playing always freezes it's last frame in the playback area and sometimes it then crashes when closing).

[XRyche]

The added Switch to Limited Range for HD is spot on for pre 2004-05 BD movies. No more too dark scenes. I know Nvidia has the ability to dynamically change contrast but the constant switching gave me headaches so this works great. Dune(1984) on Blu-Ray is great now. Thank You.

[ForceX]

I can only use EVR-CP in the latest builds, selecting any other renderer does not work and falls back to the default Video Renderer. Win 7 x64

[cca]

I've tried to apply a few little changes quickly to patch a few issues. I'll have to fix a few more things when I have more time.
I'll work on switching the exclusive mode on the fly later on. It's disabled for now, but if anyone can help coding it, I would be very grateful.
I fixed the external sub/idx items (wrong handling of time codes, my mistake).
I reverted frame present order to what it was a few versions ago. I changed the order for the latest few versions for a few alternative VSync fixes, but I didn't like how the subtitle renderer reacted (paint times too high). Alternative VSync and flushing functions will need re-evaluation for if these can work with this placement (but so far it seems to work the same as before).
The nearest neighbor resizer had a range clamping issue. Turning it into a pixel shader is somewhat unusual, but it works fine now.

x86 SSE2: http://www.mediafire.com/?8yahnb8aap19df4
x64: http://www.mediafire.com/?kbwk5snkl07co63

Playback seems improved for me in this, but very buggy for real use, any kind of resizing and it 50% chance of freezing the player.

[JanWillem32]

@CruNcher & cca: I've tried to fix a few things to get it working a bit better. I still need to fix more things, but I think I fixed the worst bug with resizing.

@XRyche: That function works only properly with limited range displays. For full range displays regular color controls are advised, as the converter will compress brightness and saturation, and shift the red/green-green/blue balances.

@ForceX: Thank you for noticing. It was a bug with setting curly braces.

[CruNcher]

Much better jan no switch audio glitch anymore but still it has a rather long blackout (video frame) period compared to dfr3752i :)

[cca]

Much better jan no switch audio glitch anymore but still it has a rather long blackout (video frame) period compared to dfr3752i :)

Same here, and the Vsync although much improved in the latest versions still gives the occasional jerk. But way better than it was a few builds ago.

[JanWillem32]

Does the occasional jerk mean that tearing occurs, or does the scheduler deviate from the target amount of refresh cycles to present a frame for? (For example; a 60 Hz monitor with a 24 fps video playing would need scheduling of 2-3-2-3-2-3-2-3 refresh cycles for frames constantly, else it's a glitch.) In case of the latter, what are the responses of each scheduler? There are different schedulers for most scenarios:
-The exclusive mode has two, one for Windows Vista and newer, and one for older systems.
-The frame interpolator stood at the base for the new scheduling code first used in the exclusive mode for Windows Vista and newer, and later in Windowed modes with Aero enabled. It's just a little more complicated as it makes intra-frames for each screen refresh cycle. It depends heavily on the frame queue, as it can create a batch of up to 8 complete output frames per input frame. (It's a multiple render target system that can write up to 4 frames simultaneously, present those, and do that a second time when required. The basic frame interpolator will try to batch everything in the first pass. The adaptive types use the first pass to interpolate the intra-frames in the interval of [0, .5] , and the second pass to interpolate those in the interval (.5, 1).)
-Windows 7 and newer with Aero enabled in windowed mode uses the new present mode (FlipEx) I added a few versions ago. It uses a mode slightly altered from the one used in exclusive mode. (This present mode currently leaves behind the last frame after closing a video, I'll fix that later.)
-Windows Vista with Aero enabled in windowed mode uses a mode slightly altered from the one used in exclusive mode.
-With Aero and Alternative VSync disabled, tearing is pretty much inevitable. Scheduling for this mode is pretty much useless, so I can't even bother on working on scheduling for this mode.
-With Aero disabled and Alternative VSync enabled, the scheduler from the original VSync code is used. However I've patched this code about a dozen times, I still don't really get it. This mode disables scheduling frames completely, making it drop frames when workloads are high (doesn't even have to be even near 100% load) and with higher video frame rates (it drops frames for me on 50 and 60 Hz sample videos). This mode is pretty basic when used with VMR-9 r., EVR CP uses an extra worker thread.
The settings for flushing and Alternative VSync are only used when in windowed mode with Aero disabled.

I can make a function that writes out a log of scheduler statistics to the desktop, maybe that can be useful for debugging.

The blackout period will need a bit of work to become shorter. I'm already glad that the reset function performs better than before.

[cca]

Since I always use windowed mode with Aero on, and my OS in Windows 7, we are definitely talking about a glitch here. The exclusive mode is inconvenient for me, if it ever becomes dynamically switched like madVR does it, then I will use it. Alt VSync is also on but I suspect is may not work as intended, the graph in the statistics display is not continuously jagged as it should for a 24hz video played in a 60Hz refresh, sometimes it is a straight line, then jagged, then a line again in random patterns.

[G_M_C]

[...]

-With Aero and Alternative VSync disabled, tearing is pretty much inevitable. Scheduling for this mode is pretty much useless, so I can't even bother on working on scheduling for this mode.
-With Aero disabled and Alternative VSync enabled, the scheduler from the original VSync code is used. However I've patched this code about a dozen times, I still don't really get it. This mode disables scheduling frames completely, making it drop frames when workloads are high (doesn't even have to be even near 100% load) and with higher video frame rates (it drops frames for me on 50 and 60 Hz sample videos).
[...]

Does this in fact mean you advise leaving Aero on, and alternative Vsync off ? Or Aero off and 'regular' vsync on ? For full screen on secondary output (i.e. TV) i mean.

G_M_C is confused now. It used to be best practive to switch off Aero if memory serves right.

[JanWillem32]

@cca: That pattern is normal for that scheduler. Sometimes the present calls are delayed a bit, causing the jitter graph to lift a bit above the central line, and sometimes the present calls simply fit into the frame queue, making pretty much flat lines. It's caused by delays created by the subtitle renderer and mixer (and the processing line before the mixer). Disabling the subtitle renderer and different sizes for the mixer buffers can make a level in the jitter graph last longer.
The exclusive mode could use a better GUI, and unfortunately, I don't have much experience with that. Switching from exclusive mode to windowed mode proved to be a bit difficult for me. I still don't know how to get the child window to return properly on top of its parent. Switching to exclusive mode from windowed mode is pretty easy.

@G_M_C: It depends, Aero can still corrupt the output in 10-bit exclusive mode (rainbow colors on some systems, but it's rare) and uses some resident memory in both 8- and 10-bit exclusive mode.
For the windowed modes, I've invested quite a bit of work to not have to rely on the Alternative VSync code, so that a frame queue can work. In general, Aero uses a bit more memory and processing (it can't compete with the exclusive mode), and usually can't handle a full frame queue to present frames at every screen refresh interval, but that's nothing compared to the cost of flushing the adapter's command queue and forcing a present afterwards (what the Alternative VSync does).

[cca]

From my testing, Alt. Vsync On or Off, I get the same glitches. Subtitles off is something I cannot live with, most of the content I watch are anime, in Japanese audio, so I need the subs! The trunk MPC has no such issues with the subtitles, I wonder why these exist here.

But anyway, from the testing I did I get the glitches regardless if subs are on or off, so I guess this is not really the issue. The frames are just not presented when they're supposed to, scheduler issue, some other issue, I don't know, but there is a defect somewhere.

[Hera]

Video still effectively stops when a new line of subtitles is loaded and then resumes.
The animation of a loaded line of subtitles doesn't do this...

I think this also happens when accessing statistics (CTRL-J) the first time, subsequently toggling statistics does not stutter.

[JanWillem32]

@cca: I'll take a look at writing something that can log the scheduler statistics. I'm glad it isn't the the subtitle renderer that's causing issues this time, as it's troublesome enough as it is already. I'll have to come up with something that can trace timing issues with all parts in the video timing chain.There are plenty of factors that come into play here. It could very well be something in the mixer that's causing this issue. About that, do both VMR-9 r. and EVR CP have the same timing issue?

@Hera: I've modified the renderer to not initialize the stats screen rendering parts by default, unless invoked for the first time.
The subtitle renderer is still very heavy, but I've already made schematics for improving some things. The first part will be creating a hard separation between the DirectX 9 and VSfilter parts. It's inexcusable that both MPC-HC and VSfilter have to integrate the full package of both parts. Just another case of poor design.

[Hera]

Maybe you keep initializing something redundantly for the each line of subtitles now?

The performance of the stat screen is impressive though - after initialization, toggling between its differ modes doesn't do anything to the jitter.