MPC-HC tester builds for internal renderer fixes

[Hera]

same issues (subs ragequittig and video pausing (maybe the same bug) and resuming for no apparently good reason) - there is no indication as to why - CPU usage is relatively low and even when video stops playing, the CPU usage does not spike or anything. Mixed Surfaces Amount is 4, 1 is Free... when it stops that may or may not jump to 3 being free. These pauses are very long.

When these second pauses happen - effectively green/GPU spikes hardcore (peak might not be viewable), red like shows spiked teeth.
This is codec independent, your previous releases did not have this.

In between these pauses, the graph shows perfect flawless playback.

It also may be the case that subtitles do not cause the stuttering / pausing effect... which is irrelevant when the video pauses in well adjusted intervals to troll me.

Resuming video is very slow - it essentially responds to me pressing the play button five second later or so which is unacceptable.

Now it starts for a second with debug info/graph all screwed blurry, then it fixes it and so in Windowed mode after initialization it fixes it
So there is an instance when the debug information is wrong for some reason.

Haali Renderer Still Crashes! :(

Jitter when not freezing: 0, avg sync offset 0, std dev offset 0 (its approaches zero, rarely gets there because of the freezes...)

Jitters goes up to ~7, avg sync offset goes to into ~-1000 territory, std dev offset goes to 1000

NO FRAMES ARE DROPPED WHEN PAUSES HAPPEN

These pauses happen every few seconds - memory leaks?

Subtitles do not have much influence on the offset / jitter... although further testing needs to be done.

Overall I have played 6min of a 1080p MKV with 95 dropped frames and 1/4 - 1 second pauses every ~five seconds.

D3DFS does not help.

I have max paint time of 521 ms which is the only thing that seems off. Normal paint time is 20ms.

Plz fix :)

[JanWillem32]

@janos666: I'll take a look at it again with some various splitters and decoders. For now, the opening of the file is a little bit rough, and smooths out within two seconds for me. VC-1 in an MPEG transport stream is known for its time stamp problems, and I really don't know where to start with fixing that from a renderer perspective. The frame time compensation mode is unchanged from the trunk build, so it should still work.
Does the same thing happen in both windowed modes with and without frame time correction?

@CruNcher: You've made quite informative videos indeed. What the renderer is doing is completely correct. It allocates surfaces at the size of the original window that it initializes with. The player resizes the window after the renderer completed initialization, so after .75 second, the renderer resets to correct for that.
I'm sorry, but I don't have a clue how to work with window handles (as can be seen with my previous experiment with switching exclusive mode on the fly). It should be possible to make the window resize before the renderer initializes, but I doubt I'll be the one to implement that in the near future.

@RGold: I'm not suprised things stutter with 32-bit RGB. Both EVR and VMR really don't like converted input.
Take a look at the native format with MediaInfo, to se what format the video file is natively.
If the native format of the file is 4:2:0 Y'CbCr interlaced, NV12 should be used.
If the native format of the file is 4:2:0 Y'CbCr progressive, NV12 can be used on most video cards, Nvidia cards also support I420/IYUV and YV12 for this.
If the native format of the file is 4:2:2 Y'CbCr, YUY2 is only commonly used.
RGB32 is useful for the Windows still image filter, for example when loading a .BMP file.
The 10-bit formats are yet another issue, I'll put that aside for now.

same issues (subs ragequittig and video pausing (maybe the same bug) and resuming for no apparently good reason) - there is no indication as to why - CPU usage is relatively low and even when video stops playing, the CPU usage does not spike or anything. Mixed Surfaces Amount is 4, 1 is Free... when it stops that may or may not jump to 3 being free. These pauses are very long.

When these second pauses happen - effectively green/GPU spikes hardcore (peak might not be viewable), red like shows spiked teeth.
This is codec independent, your previous releases did not have this.The last few revisions seem to have broken a lot in your case. :( What does the stats screen typically show for the subtitle allocator statistics in these cases you described?
Non-threaded rendering is when "Sub pictures to buffer" is 0. Threaded usage is with a buffer of at least 1. Can you try with a buffer set to 0, and with larger buffer sizes?In between these pauses, the graph shows perfect flawless playback.

It also may be the case that subtitles do not cause the stuttering / pausing effect... which is irrelevant when the video pauses in well adjusted intervals to troll me.

Resuming video is very slow - it essentially responds to me pressing the play button five second later or so which is unacceptable.)I really don't know what would be causing the issue with the slow response to a resume play command. The mixer doesn't parse commands directly, so it takes time to receive a command, but five seconds is really extreme.Now it starts for a second with debug info/graph all screwed blurry, then it fixes it and so in Windowed mode after initialization it fixes it
So there is an instance when the debug information is wrong for some reason.I don't know how to analyze/visualize this directly. Can you try making a screenshot?Haali Renderer Still Crashes! :(I'll fix external filter handlers when I have more time.Jitter when not freezing: 0, avg sync offset 0, std dev offset 0 (its approaches zero, rarely gets there because of the freezes...)

Jitters goes up to ~7, avg sync offset goes to into ~-1000 territory, std dev offset goes to 1000

NO FRAMES ARE DROPPED WHEN PAUSES HAPPENIf no frames are dropped when pauses happen, it means that the mixer handler doesn't detect itself as being late, and just resumes playing the next frame. That generally means that the main paint loop of the renderer isn't taking too long to complete. (Paint times reported in the stats screen will be lower than one frame time.)These pauses happen every few seconds - memory leaks?Memory leaks by either the video renderer or the subtitle renderer are easy to detect by the debugger for both system and GPU memory. During development, these kinds of errors can occur, and are dealt with afterwards. An excessively large buffer pool is more likely. That can be tested by just starting to play a video and looking at the player's memory usage. So far, I've seen nothing of this kind of problem.Subtitles do not have much influence on the offset / jitter... although further testing needs to be done.

Overall I have played 6min of a 1080p MKV with 95 dropped frames and 1/4 - 1 second pauses every ~five seconds.For disabling subtitles, you did completely disable the renderer by disabling the option "Auto-load subitles" in the "Options", "Playback" tab (requires restart)? The subtitle renderer is instructed in a pretty dumb way... It always renders a selected subtitle track, even if it's not visible.D3DFS does not help.

I have max paint time of 521 ms which is the only thing that seems off. Normal paint time is 20ms.In my case, it's 868 ms. That's not strange at all with all the filters I'm loading at the start.Plz fix :)I'll try, as usual. I only wish I had a 'misbehaving' PC like yours to run the debugger on. I'll try to arrange a debug build to work with a DirectX debug runtime and a system tracer, after I've done my round of basic code inspection and fixes.

[renq]

revision 3801 x86 AVX crashes instantly when opening any video.
Win 8 Dev prev, latest madVR & LAVFilters

EDIT1: Using default codecs/filters, EVR CP w/ BiLinear crashes also.
EDIT2: Previous build (3753, x86, avx) works fine even with the settings noted above.
EDIT3: X64 AVX 3801 seems to work fine

[Hera]

Ah, I didn't know that subtitles are renderer even if not shown. I just disabled subtitles via Right Click -> Subtitles.
Will test when time permitting.

[JarrettH]

Is any of this in MPC for real yet? :cool:

[RGold]

Take a look at the native format with MediaInfo, to se what format the video file is natively.
If the native format of the file is 4:2:0 Y'CbCr interlaced, NV12 should be used.
If the native format of the file is 4:2:0 Y'CbCr progressive, NV12 can be used on most video cards, Nvidia cards also support I420/IYUV and YV12 for this.
If the native format of the file is 4:2:2 Y'CbCr, YUY2 is only commonly used.
RGB32 is useful for the Windows still image filter, for example when loading a .BMP file.
The 10-bit formats are yet another issue, I'll put that aside for now.

How can I configure your build to use NV12 for interlaced?

[XRyche]

Is any of this in MPC for real yet? :cool:

Do you mean in the official builds? Actually some of it is implemented (real-if I understood correctly. If not oops :D )but a lot of it isn't as well. That's why this is "experimental". In all honesty, for this being essentially a beta build, the features that do work, work exceptionally well.

[JanWillem32]

Can anyone confirm the case renq is reporting? X86 AVX broken and x64 AVX working is possible, but it at least used to work in the past. I'm not sure if the factor of Windows 8 beta is important here. It could be, since that even for Windows 7 AVX support is relatively new.

@RGold: The internal decoders, ffdshow tryouts and LAV Filters will use NV12 or YV12 by default on pretty much all consumer-grade video content, both for interlaced and progressive.

I've indeed been patching some bits and bytes a while ago. After I dumped the renderer core code and re-wrote the entire paint loop, that was not an option anymore. When the renderer goes into the trunk, it will have to replace the old one. For the work on the subtitle renderer, I might be able to patch it in some smaller parts. As my build currently breaks VSfilter on some interfaces (again and again), that's not going to happen anytime soon.

@XRyche: Well, "exceptionally well" is a bit of an overstatement... Some parts really need some extra care. The constant frame interpolator for instance needs a bit more "soap opera effect' code (I wonder where to find some).

[cca]

Latest build is improved again, but the jerky motion perists in my case, having a lot of glitches.

[chainring]

revision 3801 x86 AVX crashes instantly when opening any video.
Win 8 Dev prev, latest madVR & LAVFilters

EDIT1: Using default codecs/filters, EVR CP w/ BiLinear crashes also.
EDIT2: Previous build (3753, x86, avx) works fine even with the settings noted above.
EDIT3: X64 AVX 3801 seems to work fine
Same exact results for me, except I'm on Win7 x64.

[burfadel]

Mediafire folder doesn't seem to work... (keeps coming up no files then redirects me to my own Mediafire folder).

[Hera]

File without subtitles plays just fine (MP4)
Same goes for disabling subtitles!

So all those issues are subtitle code related.

Also, as for the corruption at the beginning which now fixes itself. You know when you open a file it tells you the file name in the top left corner? That thing is stretched, out of proportion and then it fixes itself.

Also WMP still outperforms MPC:HC (lower CPU) on MP4 files... by a lot (in netbook terms).
WMP can get as low as 5% playing an HD file and generally stays below 20% Atom. For MPC:HC is is like 15 low 40 high approx.
This is not the case when WMP fades in and out its GUI - CPU spikes to 50% - but is irrelevant for anything but GUI discussion.
I mention this from time to time. Easy to test - netbook with h264 DXVA support, W7, WMP, and an MP4 pirated from YouTube.

[JanWillem32]

@cca: I've seen some scheduling issues as well. Creating a scheduling method attached to both VMR-9 and EVR mixer handlers isn't working out so well. (I'll ignore the two other mixers for convenience.)
EVR drops entire sets of frames, VMR-9 calls the paint command too late most of the time. Both are pretty oblivious to monitor refresh rate or any other kind of scheduling associated with that.
Can you describe the improvement in your case for the exclusive mode, the windowed mode with Aero and the windowed mode without Aero (enable Alternative VSync for that one)?

@chainring: Thank you for reporting. We'll see if things work out for the next version.

@burfadel: I'll take a look later, but for now the link indicated by MediaFire to share the folder is still the same. I might need to change some settings.

@Hera: Well, that's a relief. Editing only the subtitle allocator should not be too hard. Did you already try different sizes for the buffer setting (while keeping animation enabled, of course)?

[Hera]

Will test, just a min.

EDIT1: I noticed that CTRL-C in Windowed Mode resizes player back to mini size but leaved the picture of whatever I was watching just before CTRL-C. I mean, instead of MPCHC logo I get 1080p Fullmetal Alchemist Brotherhood image resized to tiny with Graph seeable in the bottom right corner. When in Windowed mode, but maximized (Fullscreen without D3DFS) - The player does not resize after CTRL-C but still leaves the image on screen of whatever I was watching. See like a bug.

EDIT2: Another odd thing - first line of subtitles was blurry and really low res in Windowed mode - second OK.

EDIT3: The above happens due to resizing I believe.

It seems that pictures to buffer is set to 0 by default (I reset the setting!) which is causing the issue I am experiencing. Setting buffer > 0 fixes the stalling I think.

EDIT4: Now I cannot reproduce the bad stuttering... uh, buuuut.
Sometimes when resizing (windowed -> fullscreen non D3D) the subtitles and stat screen do not resize, sometimes they do.
Setting more than 0 buffers DOES keep things much better.

EDIT5:
0 Picture To Buffer + UNchecked Allow Animation When Buffering -aside from slight stuttering- is the same as having Checked Allow Animation When Buffering. Oh...

EDIT6: Having 0 buffer or buffer like of 40 causes pauses / stutter. Having other buffers and kareoke might cause frame dropping, but the sound does not cut out.

EDIT7:

Make sure you are using D3D fullscreen, Press CTRL-Q, leave the file open dialog alone, double click (open) MKV file from Explorer (assuming MKV are opened by default by MPC:HC) - CTRL-C and ALT_F4 do not register that nicely.

[janos666]

3801 shows improper colors with this (http://www.mediafire.com/?zo3vzr60ia06s3t) profile but I think it's a problem with the Little-CMS GIT version.

[JanWillem32]

@Hera: A numbered list to work on? Let's see...
1: Already reported by CruNcher. If the player resizes the renderer's target window during the closing sequence of the renderer, a copy of the last picture is left behind.
Solution: The player should not resize the active window before the renderer is completely unloaded.

2&3: Similar issue as above. If the active window is resized directly after renderer initialization, the renderer resets itself to correct for that in .75 seconds.
Solution: The player should resize the active window before the renderer is loaded.

3: I've never understood why the non-threaded version was made standard. It forces the thread of the video renderer to draw a subtitle, which isn't exactly a great idea. On the other hand, the threaded version does waste cycles on checking for free buffers and constantly allocates and deallocates its memory resources.
I'll see what I can do.

4: If the stats screen doesn't resize, the video isn't resized properly either. I'll see if can replicate this problem. Maybe it's because the fullscreen windowed mode is a bit broken?

5: The non-threaded version always animates.

6: A buffer of 40 on a 1920×1080 screen will take 316.40625 MB of video memory (7.91015625 MB for each frame). If such an amount of memory isn't available, the driver will stall the updating of textures until sufficient space is available.

7: A known item, and certainly not new. The popup dialog windows for "Open File" and such have a higher priority in taking focus. That's okay for multi-monitor playback, but it's not ideal when the the exclusive mode obscures that dialog window.

@janos666: I assume you tested 3801r, the standard 3801 messed up a memory resource for the LUT creation.
It's really dark and sepia-like (low saturation, hue shifted far away from blue). The older version is dark, but doesn't have such a big impact on saturation and tint. Do you see the same thing, or something else?

[cca]

@cca: I've seen some scheduling issues as well. Creating a scheduling method attached to both VMR-9 and EVR mixer handlers isn't working out so well. (I'll ignore the two other mixers for convenience.)
EVR drops entire sets of frames, VMR-9 calls the paint command too late most of the time. Both are pretty oblivious to monitor refresh rate or any other kind of scheduling associated with that.
Can you describe the improvement in your case for the exclusive mode, the windowed mode with Aero and the windowed mode without Aero (enable Alternative VSync for that one)?

@chainring: Thank you for reporting. We'll see if things work out for the next version.

@burfadel: I'll take a look later, but for now the link indicated by MediaFire to share the folder is still the same. I might need to change some settings.

@Hera: Well, that's a relief. Editing only the subtitle allocator should not be too hard. Did you already try different sizes for the buffer setting (while keeping animation enabled, of course)?
I'll try to test later today or tomorrow, I'm a bit swamped with work these days.

[cca]

Some preliminary tests in exclusive full screen produce heavy tearing when Alt Vsync is on, and no tearing but jerky motion (glitches, not dropped frames) when off. In Windowed Aero mode, I always get glitches. Vsync doesn't appear to be doing anything or even detect the actual refresh rate in windowed aero mode, something that the trunk build does even with AERO on.

[janos666]

@janos666: I assume you tested 3801r, the standard 3801 messed up a memory resource for the LUT creation.
It's really dark and sepia-like (low saturation, hue shifted far away from blue). The older version is dark, but doesn't have such a big impact on saturation and tint. Do you see the same thing, or something else?

Yes, 3801r and yes, very brownish white balance with strange huye and saturation.

[RGold]

Some preliminary tests in exclusive full screen produce heavy tearing when Alt Vsync is on, and no tearing but jerky motion (glitches, not dropped frames) when off. In Windowed Aero mode, I always get glitches. Vsync doesn't appear to be doing anything or even detect the actual refresh rate in windowed aero mode, something that the trunk build does even with AERO on.

Yes, tearing is the biggest issue for me. I tried all render settings but none helps. Also sometimes it hangs when starting a video and only way out is to open task manager and kill the application. Want back to the "official" version that seems to work all the time.

[Hera]

You guys use XP or something?

[RGold]

You guys use XP or something?

Windows 7 + ATI 5450

[ForceX]

Yes, 3801r and yes, very brownish white balance with strange huye and saturation.
Did you delete your existing lut3d files? Files from old versions were creating such problems for me.

[G_M_C]

There was a request posted before, that you reset all your settings upon installing Jan's versions, and reconfigure. Also try not to use Jan's version on the same machine as trunk builds.

This is to prevent unreliable or untrue bug-reports, that cannot be reproduced and/or found by the developer(s).

[CruNcher]

Im doing that always automatically when comparing trunk and test :)

[cca]

There was a request posted before, that you reset all your settings upon installing Jan's versions, and reconfigure. Also try not to use Jan's version on the same machine as trunk builds.

This is to prevent unreliable or untrue bug-reports, that cannot be reproduced and/or found by the developer(s).

You understand that you're asking something unreasonable right? Most of us use our home PCs to test, you cannot possibly expect me not to have the trunk build around to plays videos! That build is reliable, at least it's renderer is, asking to have only Jan's builds is asking me to cripple my video playback capability. Sorry, but not going to happen until Jan's builds are on par in reliability with the trunk, in which case will replace the trunk.

As for the settings, I store them in .ini files, no chance that they may interact.

[Hera]

Windows 7 + ATI 5450

Thats... not right.

[CruNcher]

A small Player(Render and PP)/Decoder compare (with a out of DXVA Spec file) :)

EVR Custom Billinear PS 2.0 (MPC-HC test 3801r) + ffdshow quicksync + Sharpen Complex 2:

http://www.mediafire.com/download.php?h9ia0mi6tr637sv

Splash Quicksync Decoder (DXVA?) + Custom Renderer (Direct3D?) + Detail Boost (Shader?):

http://www.mediafire.com/download.php?lr93jn6pnut54bg

PS: A speedup actually indicates a slowdown in Real (when activating Sharpen Complex 2 in MPC-HC , need to find something not so heavy on GPU cycles to compare against splashs detail boost i guess) :(

[RGold]

Thats... not right.

What not right? I'm using Windows 7 X64 with ATI 5450 MXM video card.

[Hera]

Am I the only one who cannot access JanW32's builds on Media Fire right now? I need the latest SSE (non-SSE2) to test...

What not right? I'm using Windows 7 X64 with ATI 5450 MXM video card.

Well you shouldn't be getting tearing IMO. :)

[CruNcher]

uhh madshi implemented DXVA2 based Deinterlacing in his renderer :)
and current test build doesn't seem to support it anymore it crashes with it

[burfadel]

Yep! Me, I mentioned it the other day:

Mediafire folder doesn't seem to work... (keeps coming up no files then redirects me to my own Mediafire folder).

[Hera]

With Six sub pictures to buffer and allow animation while buffer and Haali Splitter and 8-bit surfaces and D3D:FS,
[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv - started off more at 21 / 30 and moved to 30 / 30.

[CruNcher]

wow that result blows even looking @ the High resource utilization it's stable i would say even more stable then EVR custom or Mirillis Renderer result :)

MPC-HC trunk + Madvr (bicubic) + ffdshow quicksync

http://www.mediafire.com/download.php?7uhdibw4i3r2jce

[RGold]

Am I the only one who cannot access JanW32's builds on Media Fire right now? I need the latest SSE (non-SSE2) to test...



Well you shouldn't be getting tearing IMO. :)

I have no tearing issue with the regular version.

[CruNcher]

just 2 words jan it rocks (this was with 500 ms timer running in the background) :)

http://www.mediafire.com/download.php?ag163hwz6fewzlo

only the innit issue and it would be perfect from a stability stand for NT6 (until i finished my upcoming test marathon) ;)

PS: This is also cool now that any background noise is completely gone it's easy to tell problems apart immediately (for the whole chain) :) http://www.mediafire.com/download.php?d0bg6khk2lk8bjl

Another perfect result :) http://www.mediafire.com/download.php?7gxisjnzedbo0u8

This is also something cool http://www.mediafire.com/download.php?6uhkiqiajnak5c4 (not directly related but also MPC-HC test was used so ;) ) unthinkable todo with XP (NT5) :) 2 different frameworks running side by side with a low timer running :) (and if you take also the fact im recording this all near realtime on a IGP GPU directly (@ relatively low power) into what i upload it becomes even more amazing)

[TheElix]

What? What happened?
PS: This is also cool now that any background noise is completely gone it's easy to tell problems apart immediately (for the whole chain) :) http://www.mediafire.com/download.php?d0bg6khk2lk8bjl
What do you mean background noise is gone?

[burfadel]

How do we access the builds? I'm not the only one that can't access http://www.mediafire.com/?r367kbp7p9but

It just flashes up '0 Items to Display!', then redirects to my Mediafire page (in my case).

[XRyche]

How do we access the builds? I'm not the only one that can't access http://www.mediafire.com/?r367kbp7p9but

It just flashes up '0 Items to Display!', then redirects to my Mediafire page (in my case).

I'm sure JanWillem32 is aware of the issue by now. Just give him time to do something about it.

[CruNcher]

What? What happened?

What do you mean background noise is gone?

The Noise if you have constant vsync changes in the OSD it's still realizable though as a strange spike is visible in both situations but this way it's even easier to spot now (flat line everythings perfect, spike something is wrong somewhere) :)

[burfadel]

I'm sure JanWillem32 is aware of the issue by now. Just give him time to do something about it.

Ah ok! just that when I mentioned it, then mentioned by someone else, and then rementioned by myself, nobody else commented on the issue. At least now I know its a proper issue and not just an issue affecting only a couple of us.

[CruNcher]

So now we know why Mediafire had problems they completely overhauled it got a complete new HTML5 UI ;)

PS: Jan i tested a lot of DXVA implementation with your current EVR Custom and some fail i wonder those that doesn't fail could be called better though ;) ? it seems especially the init issue makes some decoders problems keeping a really big surface without changing it (Mainconcepts DXVA is on that list) :D

[Hera]

The latest SSE (non-SSE2) build crashes when resizing window while playing video.

[JanWillem32]

I'm glad that the folder works again. The links to the files remained the same, so that's a relief.

I've revised the internal numbering for the renderer selection list. This will reset the selection for the renderer to default on the first initialization.

About the settings, not everyone can use the save to .INI function, as it's limited in total size (it hardly supports even a few custom pixel shaders). The Miscellaneous page of the Options menu has a button to export all settings to a .REG file from the registry.

I've completely revised the texture handling for the subtitle renderer. It should have somewhat safer functions now, but some extra revisions will be required later on. It's a bit slower to react to resizing and will consume quite a bit more memory when switching from one buffer to another. Purging resources and making new ones while the video renderer is still running is a delicate procedure.

I've written a scheduler for on EVR CP, and I've misnamed it "Disable Scheduler" (the name of the function that was there before it). It's default enabled for the constant frame interpolator (not system dependent). The selectable version should work for Vista and newer in exclusive mode, for 7 and newer it's also available in windowed mode with Aero enabled. It doesn't have the Frame Time Correction function for VC-1 in MPEG transport streams yet, and I don't know if will work properly with all types of pulldown. It is at least completely compatible with scheduling for a command queue of several entire frames ahead (the other scheduling modes can't really queue more than 1). I probably have to work on getting timing right for the insertion moment of subtitles, but it does a pretty good job at it usually, and maybe I'll add proper support for the non-threaded version of the subtitle renderer later on. There's a new option to adjust the detected monitor refresh rate in the output tab, for if the scheduler skews a bit in timing (can be seen in the jitter graph, the lines should be roughly symmetrical, averaged over a few hundred frames).

I couldn't find out what exactly the problem is with the color management. It's quite clear that the update to the most recent beta caused this, but so far I haven't seen what part of the code is causing this. It might be sufficient to only update the code in the renderer. I will investigate this next week.

I didn't have time to test with external filters. I will do so within the next two weeks.

[golagoda]

I'm glad that the folder works again. The links to the files remained the same, so that's a relief.

I've revised the internal numbering for the renderer selection list. This will reset the selection for the renderer to default on the first initialization.

About the settings, not everyone can use the save to .INI function, as it's limited in total size (it hardly supports even a few custom pixel shaders). The Miscellaneous page of the Options menu has a button to export all settings to a .REG file from the registry.

I've completely revised the texture handling for the subtitle renderer. It should have somewhat safer functions now, but some extra revisions will be required later on. It's a bit slower to react to resizing and will consume quite a bit more memory when switching from one buffer to another. Purging resources and making new ones while the video renderer is still running is a delicate procedure.

I've written a scheduler for on EVR CP, and I've misnamed it "Disable Scheduler" (the name of the function that was there before it). It's default enabled for the constant frame interpolator (not system dependent). The selectable version should work for Vista and newer in exclusive mode, for 7 and newer it's also available in windowed mode with Aero enabled. It doesn't have the Frame Time Correction function for VC-1 in MPEG transport streams yet, and I don't know if will work properly with all types of pulldown. It is at least completely compatible with scheduling for a command queue of several entire frames ahead (the other scheduling modes can't really queue more than 1). I probably have to work on getting timing right for the insertion moment of subtitles, but it does a pretty good job at it usually, and maybe I'll add proper support for the non-threaded version of the subtitle renderer later on. There's a new option to adjust the detected monitor refresh rate in the output tab, for if the scheduler skews a bit in timing (can be seen in the jitter graph, the lines should be roughly symmetrical, averaged over a few hundred frames).

I couldn't find out what exactly the problem is with the color management. It's quite clear that the update to the most recent beta caused this, but so far I haven't seen what part of the code is causing this. It might be sufficient to only update the code in the renderer. I will investigate this next week.

I didn't have time to test with external filters. I will do so within the next two weeks.

As the last SSE version doesn't work very well, x86 SSE: http://www.mediafire.com/?57fm7xqvl9pzbd3
x64: http://www.mediafire.com/?45fm4vvmgbki9ou

Thanks so much, good job and I will try it as always.

[JanWillem32]

Thanks again.:)

I forgot to mention, the two new schedulers tend to require at least 8 mixer buffers to work properly. The jitter graph can even be seen jumping back and forth "in time" when not enough are set. Setting more buffers will also smoothen out the graph, because more samples can be scheduled ahead. Note that setting more buffers will require more memory, but won't necessarily increase the strain on the memory controller. If the video card or IGP is short on total memory, don't use too many buffers, as that will cause swapping textures to the system memory parts. Memory consumption for a single 1920×1080 video frame in the 8- or 10-bit formats takes 7.91015625 MByte, the 16-bit format takes double of that, and the 32-bit format quadruple. There are also some tools available to see the video memory consumption in real time.

[Hera]

As the last SSE version doesn't work very well, x86 SSE: http://www.mediafire.com/?57fm7xqvl9pzbd3


EDIT: Black Screen is caused by Firefox being open along with MPC:HC. What the ****?

Version 3801 was much much better in terms of being usable on Windows XP (See sig).

In that version I had video (3801). In this version I do not get video, just subtitles. There is also a flash of something every time a new line of subtitles appears - to fast for me to notice if that is video. Otherwise the screen is black.

On a youtube 1080p MP4, the screen is grey - black when I get statistics on screeen.

BUT, it doesn't crash when resizing!
EVR & VMR9 renderless also black screen.
Haali makes the player exit/crash.

Something else I noticed,
the ability of the render not to skip frames improved. I still need to test on some more intensive stuff when I have time.

[JanWillem32]

Well, that's quite a chaotic description we have there. Vanilla EVR and VMR-9 w. also give a black screen? I probably can't solve that problem then, as these are completely external renderers. If the mixer parts are failing, it will affect VMR-9 r. and EVR CP, too. You do have normal playback without programs rendering in the background?
The frame dropping code for EVR was a bit rusty, so I've given it some minor updates. The new schedulers tend to never drop frames at all, which can be a bit of a problem if the video frame rate is slightly below, equal or over the monitor refresh rate. I'll have to take a look at creating code to allow dropping frames for such situations, to prevent desynchronization.

[Mierastor]

Would it be possible to add Lanczos to the resizers? It is very popular for image resizing and many people think it gives the best result.

[JanWillem32]

It's been a while since I've added any resizers, so I can indeed try. I'll look for some code or math for it, as long as it's easy to insert. (I'm not going to work out the programming for sampling nodes, like I did for the spline5 and spline6 forms anytime soon.)