MPC-HC tester builds for internal renderer fixes

[Hera]

Haal is black screening now... for everything and for all codecs.

[ForceX]

Haali works fine here, but unless I enable "Disable RGB linearization", I get a black picture in EVR CP/VMR9r with >8bit surface, but subtitles/typesetting etc. appear.

[JanWillem32]

I've fixed the linearization functions (I misplaced one curly brace) and fixed another subtitle renderer initialization bug.
I'll have to look into the issue with Haali renderer. With basic settings it seems to reasonably work for me.
I'll have to think about adding color controls to the video renderer, so it can alter the combined subtitles with video image (like the color management and dithering). I wasn't planning to add any color controls on top of those of EVR and VMR-9, though.
These builds have a new present method for Windows 7 and newer (FlipEx). I'd like to ask how well it works with getting the image in windowed mode to the desktop swap chain, in terms of timing, efficiency and such. I'll try to make the reset-on-resize function a bit faster later on.

[cca]

Last 3 days I was trying madVR, only to discover it fails the same way EVR-CP failed in these experimental builds. Specifically, it cannot present the frammes in a timely manner when the video played is 24fps but the screen 60Hz, resulting in jerky motion, something like microstuttering. The trunk EVR-CP can do this perfectly, so the video is fluid, even if an effect like a 3:2 pulldown is visible.

I will try the latest tester build 3752 during the weekend, the EVR-CP in these builds is my only hope for some decent video quality apparently.

[CruNcher]

The 64 bit EVR-CP crashes immediately after loading the 32 bit SSE2 works, also the performance of the old FlipEX code here seems better with both ffdshow-quicksync (memory copy) and Cyberlink DXVA2 (direct) switching (resize) times with 3752i are better 3752ir causes a long (delay) and so a big audio glitch @ the switch (resize), perceptional this already hurts in 3752i a little (compared to the trunk) but in 3752ir it is unacceptable worse because its not seamless anymore (only video) but audio glitches also here now.


PS: The heaviest crash i got so far with 3752ir EVR-CP running Firefox 10 (GPU) in the background trying to switch from window to full window, doesnt happen with 3752i testing in both cases 10 rapid switch cycles (window,full window,fullscreen).

http://img97.imageshack.us/img97/5750/heaviestcrash.png



Trunk 3752 32bit MPC-HC EVR-CP result:

http://img207.imageshack.us/img207/6963/trunkfullresult.png

Tester 3752i 32bit MPC-HC EVR-CP result:

http://img840.imageshack.us/img840/7060/testerfullresult.png


Yep i got the rendering of the Text in Trunk back under control it seems to have repaired itself after installing the DirectX redist that came with RAGE :)

[cca]

More or less what CruNcher says, performance is much better in this version, those damn stutters seem to be almost gone, just the change between window and fullscreen is very slow and causes crashes at times.

[JanWillem32]

@cca: I was looking at the internal timing functions, and I found out that the timer functions are typically difficult to manage.
Some manufacturers disable HPET in the BIOS by default or set it to 32-bit, instead of the normal 64-bit mode. CPU throttling options are sometimes also to blame.
Can you see in your system BIOS if HPET is enabled correctly?
Can you test if disabling CPU throttling helps? You can temporarily disable it in the the Windows control panel. Under "Power Options", select the "High Performance" power plan to disable power-saving options. A nice article on this:
http://www.howtogeek.com/howto/windows-vista/disable-power-management-on-windows-vista/
If changing settings for power management helps, you might need to update some drivers or fine-tune the power settings to a more balanced state.
Some extra reading materials on HPET (for convenience, I left out the programmer's resources):
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.reghardware.com/2006/07/04/amd_dual-core_tweak_tool/

@CruNcher: It's a multi-threading issue for the paused mode. I've solved it already.
I'm trying to fix switching in between files with the 10-bit display mode enabled, and making the reset sequences less annoying for the next batch.
I've also added a pause command to allow the video renderer to take some time to finish its first paint loop, for example when creating a new file for the color management.

[CruNcher]

@cca: I was looking at the internal timing functions, and I found out that the timer functions are typically difficult to manage.
Some manufacturers disable HPET in the BIOS by default or set it to 32-bit, instead of the normal 64-bit mode. CPU throttling options are sometimes also to blame.
Can you see in your system BIOS if HPET is enabled correctly?
Can you test if disabling CPU throttling helps? You can temporarily disable it in the the Windows control panel. Under "Power Options", select the "High Performance" power plan to disable power-saving options. A nice article on this:
http://www.howtogeek.com/howto/windows-vista/disable-power-management-on-windows-vista/
If changing settings for power management helps, you might need to update some drivers or fine-tune the power settings to a more balanced state.
Some extra reading materials on HPET (for convenience, I left out the programmer's resources):
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.reghardware.com/2006/07/04/amd_dual-core_tweak_tool/

@CruNcher: It's a multi-threading issue for the paused mode. I've solved it already.
I'm trying to fix switching in between files with the 10-bit display mode enabled, and making the reset sequences less annoying for the next batch.
I've also added a pause command to allow the video renderer to take some time to finish its first paint loop, for example when creating a new file for the color management.

Nice :) in regards to hpet timer issues and how to identify them easily http://www.xtremesystems.org/forums/showthread.php?179044-Real-Temp-New-temp-program-for-Intel-Core-processors&p=4731014&viewfull=1#post4731014

[cca]

Thank for the suggestions, here's my 2 cents: I built the system myself, also use linux on it so I can already tell you it has 4 32bit HPET timers on it, enabled. Disabling power management just to play a video is not acceptable, my quad core consumes a lot of power in full clock mode. Also, the current VSync implementation in the trunk builds works fine for years now, why both of you are blaming my system all of a sudden? That VSync algorithm never drops a frame or produces stutter. Also let me remark this: this kind of slight stutters are not so visible when you watch movies or normal series, but in my case 99% of the time I watch *animation*. In the case of animation the slightest jerk or stutter is immediately noticeable. This is the reason that years ago I was one of the first users of ReClock, I could see dropped frames where no one else could.

I got the same attitude from the madVR users, "it must be your system or you". Well, MPC-HC's current EVR-CP works FLAWLESSLY even with postprocessing shaders enabled. madVR does not. The EVC-CP of this test builds does not. Nothing more to say.

[JanWillem32]

I should have pointed out in my previous post that I've changed some original timer functions for HPET equivalents. (Before I knew that the HPET system is rather flawed in some cases.) I don't mind changing things, but I do need to find out what to change first.
Anyway, how does the trunk build fare when VSync and flushing functions are disabled in the two windowed modes and the exclusive mode for both EVR and VMR-9? (Each uses different timing modes. Now with adding FlipEx mode for Windows 7 with Aero enabled, I've also added yet another mode.)

[cca]

I should have pointed out in my previous post that I've changed some original timer functions for HPET equivalents. (Before I knew that the HPET system is rather flawed in some cases.) I don't mind changing things, but I do need to find out what to change first.
Anyway, how does the trunk build fare when VSync and flushing functions are disabled in the two windowed modes and the exclusive mode for both EVR and VMR-9? (Each uses different timing modes. Now with adding FlipEx mode for Windows 7 with Aero enabled, I've also added yet another mode.)

Urgh, VSync disabled? So I gave it a go, the results I get seem to be a lot like your build, random skips and stutters. As for the exclusive mode produces similar result with the windowed, random jerkyness but I did not observe tearing at least.

EVR and VMR9 gave the same results from what I can see.

I do not know precisely how the VSync works in the trunk builds, but it is doing a very successful job at eliminating all random phenomena for me. Without it, it's the same with the rest of the renderers I tried, random motion problems.

The most recent change you did with the FlipEx helped a lot, but not quite there yet.

[CruNcher]

If you use High Performance does it still stutter, do you have a sample that shows the biggest problems for you in motion i guess @ 60 hz ?

Windows Power Management plays a big role when it comes to fluid video Playback unfortunately, not so for DXVA but with memory copy going on Power saving can be a bad thing Balanced also seems to work fine but Power Saving to fullest isn't really worth it compared to the back fire (especially with DWM Aero and it's continuous memory copy). Though it also Depends on the CPU,GPU architecture alot Sandy Bridge is in those regards very efficient in switching (and it even switches without anyone really noticing it even in High performance most standard stuff hasn't the resolution to show it ;) ) and latency reduction, tough measuring with EVR-CPs OSD in general is a problem the text output itself consumes a fair amount of cycles (continuous timer firing) and causes itself latency. Windows 8 and WDDM 1.2 should improve this though further :)

I switched to Sandy Bridge early on and i can say in those regards it's top it saves power like crazy without really hurting the Performance and if i think about haswell it shivers down my spine how efficient that must be :)

@ Balanced SNB system result

http://img195.imageshack.us/img195/1843/balancedj.png

OSD overhead:

http://img254.imageshack.us/img254/3318/currentresosdoverhead.png

Graph only:

http://img844.imageshack.us/img844/386/currentgraphonlyoverhea.png

[cca]

Here's mine:
http://img190.imageshack.us/img190/9639/wintimer.jpg (http://imageshack.us/photo/my-images/190/wintimer.jpg/)
System was always set to Balanced anyway.

[CruNcher]

cca could you provide some of the animation scenes you have issues with (samples) :) ?

[cca]

cca could you provide some of the animation scenes you have issues with (samples) :) ?

Umm, all you need is any recent anime release encoded in H.264. This one for example (http://mazuisubs.com/171)

[CruNcher]

@cca

if that isn't stable i dunno what could be :) not 1 glitch flawless motion no problems, though this is 3752i not 3752ir

http://img10.imageshack.us/img10/1082/crazystable.png

and now the craziest ;)

Process Explorer run the whole time with a 0.5 ms timer, the GPU Spike comes from Firefox D2D Gif Animation rendering, i love SNB and NT 6, i guess i will top it off running ID tech 5 windowed ;) :D

[Hera]

With animation, you can only notice stuttering with panning / zooming scenes / 3D-animation.
2D animation many times is simply is 0/1/0/1 for things like mouth movement so you really cannot notice stuttering.
Additionally, some encodes introduce stuttering (stuttering that happens with all codecs and renderers).

I do not notice any renderer-imposed stuttering. :/

Offtopic: GIF performance is a long standing Firefox bug introduced and reported during Firefox 4 development and will probably be fixed by Firefox 10 or 11.

[CruNcher]

With animation, you can only notice stuttering with panning / zooming scenes / 3D-animation.
2D animation many times is simply is 0/1/0/1 for things like mouth movement so you really cannot notice stuttering.
Additionally, some encodes introduce stuttering (stuttering that happens with all codecs and renderers).

I do not notice any renderer-imposed stuttering. :/

Offtopic: GIF performance is a long standing Firefox bug introduced and reported during Firefox 4 development and will probably be fixed by Firefox 10 or 11.


it is fixed but CPU wise it came back shortly as a regression but is fixed again https://bugzilla.mozilla.org/show_bug.cgi?id=595671 it's a wild ride with it ;)
Tough you should look @ it carefull it's GPU usage not CPU usage ;) the bug was about high CPU usage that maxed out old CPUs really fast and even caused unacceptable high CPU usage on Multicores, though if you compare with current Chrome they push the load to IO which seems far from nice ;).

And yep a bad encode also can cause problems see evil tree as perfect example you need a very specific playback chain to play it flawless which makes rarely sense todo and better fix it like jan did fixing it's pulldown :)

The best testing Horizontal and Vertical fluidness is pushing a lot of different Ken Burns @ it ;)

i watched this complete Anime and didn't saw any problem with it's motion also in zooms and pans and there are a lot of different pans zooms and ken burns here with different speeds.

[cca]

Hehe, I know about the stutters already in the animation itself, the difference with them is that they are reproducible every time you view the video. The ones I notice are obviously always in panning scenes, and they are *not* the same every time you view the specific scene, hence they come from the renderer.

@CruNcher: I do not doubt it is stable for you, but it is not for me. I can view the same scene 10 times, and some times it will be stable, sometimes I will see jerkyness. That is too random and not how a proper renderer should behave. The only renderer to date that is 100% predictable in my own system is the current EVR-CP in the trunk builds.

What I do in the specific video I gave you is this: I fast forward to 19:30 and watch the panning scenes there ( :D ) then I rewind again back to 19:30 and watch again. Sometimes smooth, sometimes not. And me disappointed every time it happens.

EDIT: forgot to add: I do not rely on stats and numbers, I fall for this trap with madVR. They say no glitches and everything smooth. But it is not. I do my tests visually only, my only instrument are my own eyes.

[CruNcher]

Hehe, I know about the stutters already in the animation itself, the difference with them is that they are reproducible every time you view the video. The ones I notice are obviously always in panning scenes, and they are *not* the same every time you view the specific scene, hence they come from the renderer.

@CruNcher: I do not doubt it is stable for you, but it is not for me. I can view the same scene 10 times, and some times it will be stable, sometimes I will see jerkyness. That is too random and not how a proper renderer should behave. The only renderer to date that is 100% predictable in my own system is the current EVR-CP in the trunk builds.

What I do in the specific video I gave you is this: I fast forward to 19:30 and watch the panning scenes there ( :D ) then I rewind again back to 19:30 and watch again. Sometimes smooth, sometimes not. And me disappointed every time it happens.

EDIT: forgot to add: I do not rely on stats and numbers, I fall for this trap with madVR. They say no glitches and everything smooth. But it is not. I do my tests visually only, my only instrument are my own eyes.

let me try something i guess this is perfect to test something new, and yes never trust anything else then your eyes OSDs and stuff are nice but they are influenced and some times can be even the cause for issues themselves ;)
And so i can only tell that i stay with AERO for me and my Configuration it's perfect and i don't seem to need any exclusive modes so far :)

And yep debuging issues like you experience is not easy though Microsoft is working hard to provide solutions for this currently you have to go deep down and analyze the system to find the cause but in the future it will be much easier :)

[Hera]

With latest builds I am getting issues, (netbook)
- Crashes when opening files with EVR:CP {1.5.3.0 (3752ir)}
-- MPC:HC resizes itself for the video size, states "Playing [DXVA]", doesn't show video and crashes {1.5.3.0 (3752ir)}
- Doesn't crash with EVR {1.5.3.0 (3752ir)}
- Black Screen with Haali which fixes itself if I seek (aside from the video being messed up still obviously) {earlier than 3740 - not present on XP}
- Doesn't crash when opening EVR and THEN switching to EVR:CP and opening the file again {1.5.3.0 (3752ir)}
- Before restarting, it blackscreened for EVR:CP {1.5.3.0 (3752ir)}


Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.3.0
Application Timestamp: 4e8e1107
Fault Module Name: mpc-hc.exe
Fault Module Version: 1.5.3.0
Fault Module Timestamp: 4e8e1107
Exception Code: c0000005
Exception Offset: 001b86c2
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[CruNcher]

http://www.mediafire.com/?fitumy3c9qf3p31 <- :) no fraps direct H.264 DWM Transcoding (including Pixel Shader) (speeduped to show the motion) ;)

[Hera]

You know what I think I might be getting stuttering/dropped frames every time a new line of subtitles get loaded. :|

[JanWillem32]

For these builds, I've mostly tried to solve the nasty bugs in the intermediate versions. I added the presentation timer of the frame interpolator to the new present method. (Really, this sounds like something more complicated than it actually is.) It's enabled for Vista and onwards in full screen exclusive mode and for 7 and onwards in windowed mode with Aero enabled. I improved the reset function on resizing by a lot. I've also made some optimizations for this mode when frame interpolation is active. (Although it still can't do the full 80 Hz in my case, but I need the exclusive mode for pretty much anything, anyway. For others it might work.)
I've also been analyzing the VSync thread. It will take some time to fix it again. Its standard endless loop that constantly analyzes the active monitor's raster status has a CPU usage that's far beyond the normal amounts. I don't know yet why. It's difficult to trace.
The FlipEx mode will leave the last presented frame behind in the active window, and it seems to be impossible to clear it. For now, I've added an extra present when closing the renderer that simply paints a black screen. I hope to find a proper clearing method later on.
I probably forgot something in addition to this all, I hurried to build these during breakfast time today :rolleyes:. I'll comment on previous posts and PMs later today.

[cca]

For these builds, I've mostly tried to solve the nasty bugs in the intermediate versions. I added the presentation timer of the frame interpolator to the new present method. (Really, this sounds like something more complicated than it actually is.) It's enabled for Vista and onwards in full screen exclusive mode and for 7 and onwards in windowed mode with Aero enabled. I improved the reset function on resizing by a lot. I've also made some optimizations for this mode when frame interpolation is active. (Although it still can't do the full 80 Hz in my case, but I need the exclusive mode for pretty much anything, anyway. For others it might work.)
I've also been analyzing the VSync thread. It will take some time to fix it again. Its standard endless loop that constantly analyzes the active monitor's raster status has a CPU usage that's far beyond the normal amounts. I don't know yet why. It's difficult to trace.
The FlipEx mode will leave the last presented frame behind in the active window, and it seems to be impossible to clear it. For now, I've added an extra present when closing the renderer that simply paints a black screen. I hope to find a proper clearing method later on.
I probably forgot something in addition to this all, I hurried to build these during breakfast time today :rolleyes:. I'll comment on previous posts and PMs later today.

It shall be tested of course, when I get back home. Weekdays are loaded with work :/

[cca]

Unfortunately the new build brought this error:
http://img88.imageshack.us/img88/4654/errorosi.png (http://imageshack.us/photo/my-images/88/errorosi.png/)

Subsequent tries result in instant crashes, or, if I try a simple .avi, the playback stays paused, doesn't autostart.

[golagoda]

It's been working fine for me as always at least ;)

[CruNcher]

Wow jan that is some strange new behavior the video plays ok though after switching which still is heavily delayed and glitchy it doesn't stop anymore the funny thing it doesn't plays like the .wtv thing normal but a long time in slow motion the pause button is pushed and it continuous in slow motion very odd i wonder if i can record this :) :D

Wow it goes hi wire ???

Ok so it happens as follows

1, Drag and Drop like normal nicetest.ts into the MPC-HC tester window
2. it doesn't instantly plays it back but pauses ?
3. When clicking play it starts to playback in slow motion with heavy glitches opening the OSD looks crazy and when pause is pushed it stops but the video plays in slow motion in the background and audio stutters like crazy :P

hmm is it correct that mpc-hc SSE2 tester dfr3753 shows as version 1.5.3.0 ?

[JanWillem32]

I've made the access to the virtual subtitle renderer interfaces a bit more robust and improved the timing initialization functions for both the video and subtitle renderer.
The initialization functions are still a bit vulnerable to resizing immediately after opening. This can be caused by the "View", "Statistics" item or the playlist bar, for example. These items change the size of the video window after the renderer starts, so it immediately resets itself. The same type of problem can be observed with the full screen windowed mode's main bar.
I've added an optimization to the general paint speed. When not hindered by rendering a subtitle, alternative VSync or frame interpolation, paint time should be about 10% lower than before.

[golagoda]

I've made the access to the virtual subtitle renderer interfaces a bit more robust and improved the timing initialization functions for both the video and subtitle renderer.
The initialization functions are still a bit vulnerable to resizing immediately after opening. This can be caused by the "View", "Statistics" item or the playlist bar, for example. These items change the size of the video window after the renderer starts, so it immediately resets itself. The same type of problem can be observed with the full screen windowed mode's main bar.
I've added an optimization to the general paint speed. When not hindered by rendering a subtitle, alternative VSync or frame interpolation, paint time should be about 10% lower than before.

x64: http://www.mediafire.com/?qjxmdfbt1fj3ymo
x86 SSE2: http://www.mediafire.com/?6i89id0m4vfp16g

Will use and test out the x86 SSE2 later today, thanks for these builds and keep up the great work ;)

[CruNcher]

yep the new version has problems with to fast close and open that causes the slow motion start it doesn't pause anymore on load though :)
ok once it's stable starting without slow motion, open the OSD causes a small hickup for say 10 seconds then it's fine :)
Switching to full window is still ok small glitch then fine but switching to Fullscreen causes it to go slow motion hi wire again.
Also it crashes some loads randomly it seems, most loads though after the first you either get slow motion or crash and it's hardly stable.


changing to fullscreen (it doesn't recover here anymore) :

http://img24.imageshack.us/img24/4181/fullscreenhiwire.png


So in my (Aero) use case for now 3752i EVR-CP was still the most stable (the only issue was the on demand size switching compared to trunk but it is seamless no glitches their) of the testers so far with (Intel HD Graphics DXVA2, Driver: 2509)

3752i (perfectly stable if on demand resize needs to be)
3752ir (started the problems)
3723 (still issues)
3754i (still no good,even worse hardly recovers @ all, crashes randomly)

[JanWillem32]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

[watchman]

Hello. I don't know if this is right thread to post a request about subtitle renderer, but I saw on the first page that you also are working on improving it.

I'd be really happy if it's possible to implement option similar to "Position subtitles relative to the video frame", but without resizing the font. The point of this is to always have subtitles above the bottom black bar with all combinations of monitor/source video aspect ratios, but preserve predefined font size.:thanks:

[JanWillem32]

Can you please specify that in more detail? I can't really imagine a way I could make this work in general.
For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image. There's no embedded data on the actual font size or subtitle position inside these types.
For the plain text subtitles, it should be possible to set one font size, independent from the window size. It would then behave the same as the OSD (including the clipping behavior on smaller window sizes).
For styled text subtitles, font size, formatting and positioning data is written in the file itself. All items are given in window coordinates, so resizing with this type gives the same problem as with the bitmapped types; all positions will be scaled and offset, and entire lines/items can be pushed outside the window area.

[watchman]

Can you please specify that in more detail? I can't really imagine a way I could make this work in general.
For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image. There's no embedded data on the actual font size or subtitle position inside these types.
For the plain text subtitles, it should be possible to set one font size, independent from the window size. It would then behave the same as the OSD (including the clipping behavior on smaller window sizes).
For styled text subtitles, font size, formatting and positioning data is written in the file itself. All items are given in window coordinates, so resizing with this type gives the same problem as with the bitmapped types; all positions will be scaled and offset, and entire lines/items can be pushed outside the window area.

I'm sorry, I probably did not post all the relevant info. I was talking about external file plain text subtitles (.srt for example).


Here is a simple example how it works now (with "Position subtitles relative to the video frame"):
When playing 4:3 video on 16:10 screen, subtitles have correct font size and are n pixels from the bottom of the screen (because there are simply no horizontal black bars)

When playing movie with cinematic aspect ratio on 16:10 screen, subtitles are n pixels above the bottom black bar, but font size is much more smaller and subtitles are almost impossible to read.


This is how it works without that option checked:
Subtitles always have same predefined size and are n pixels above the bottom of the screen, so if I want to have them inside video frame, I have to change the "Bottom" value for every different screen/source aspect ratio, because black bars have always different height.


With predefined/correct font size I just mean settings in mpc-hc font options in Subtitles / Default Style -> Font.

All I asked is just to provide some "automatic horizontal positioning relative to video frame", which will simply lead to always having subtitles inside video frame n pixels above the bottom of the video frame.

With n I mean "Bottom" value in Screen Alignment & Margins options

/edit: I found that subtitles are resizing with video and looks like it's somehow related to screen resolution/video resolution ratio. So to be even more specific, I was talking about case when video is resized to FS (as it looks like that mpc font settings are apllied to this case). Downscaling subtitles with video frame relative to screen resolution is cool indeed and I have no intention in asking to change it :)

/edit2 "A picture is worth a thousand words":
Here are two screenshots of what I was writing about. Hope it will make everything clear :)

How it should look every time: http://imageshack.us/f/827/correctp.png/
How it looks with black bars: http://imageshack.us/f/88/toosmall.png/

[cca]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

x64: http://www.mediafire.com/?23fn9b9m6q4alqo
x86 SSE2: http://www.mediafire.com/?c01602kwqpjay4v

Sounds promising, will try it later today.

[CruNcher]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

x64: http://www.mediafire.com/?23fn9b9m6q4alqo
x86 SSE2: http://www.mediafire.com/?c01602kwqpjay4v

Hehe i take that as a compliment ;)
much better still glitches slightly (especially the audio glitching is annoying) at resize but stability and jitter recovery are ok again :)

http://img191.imageshack.us/img191/3184/glitchu.png

[Matching_Mole]

For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image.

It existing already a way to change the position and the size of bitmapped subtitles? If not, do you plan to implement one day?

Thanks for all your great work.

[cez4r]

Hi! There are 2 problems under XP with 3 latest builds: 3753, 3754i and 3755i.
1) small bug: with checked option to store settings to .ini file, these builds insert many empty keys under: HKEY_CURRENT_USER\Software\Gabest\Media Player Classic.
The 3751 and 3752ir versions don't do this.
2) big problem w/ EVR-CP: there's long opening and no rendering of files, and MPC-HC stays in memory after closing (after "playing" files).
It's OK with 3751 and 3752ir versions. I have an ATI IGP HD4290.

[Hera]

notebook:

Resizing seems to take longer.
And the really annoying thing is that the seek bar in fullscreen mode resizes the video all the time.
I also tried enabling 16f surfaces and that caused the player to crash - did not happen again though.

[JohnLai]

Problem : I just noticed ur build is unable to load subtitle if it are external idx and sub.

[nand chan]

I'm afraid I haven't quite understood the “ATI Video Chroma Up-sampling fix” option yet.

If I set it to, say, “4:2:0, Mitchell-Netravali cubic5”, and input YV12, does that mean that chroma information gets upscaled to 4:4:4 using that filter, then both get upscaled using my chosen luma filter?

I'm asking because I've just finished switching from madVR to EVR-CP but I'm still curious about this option. In madVR, I could set the chroma and luma scalers separately, so I could use a softer scaler for chroma and a sharper one for luma. Am I correct in assuming that I will get the same behavior with this option?

What about nVidia users, why can't they have separate chroma upscalers?

Edit: Also why does it start paused if you open files from the menu?

[Hera]

There is a spike every time a new subtitle line is loaded and noticeable frame dropping because of this.

If no stuttering is {A,B,C} then what I am seeing is {A,C} or {A,B,A,C} or {A,B,A,B,C} if subtitles get loaded at B
I think this is new; subtitle performance regressed, before I only noticed issues with animated subtitles.
Recently got frame dropping when showing a few lines of subtitles - never had this issue before.


I think you broke subtitle buffering or something.

[nand chan]

Also, are there any plans on including support for P010 or other 10-bit formats as input?

[nevcairiel]

As i understood it, the EVR is not really equiped to deal with 10-bit input formats.

[nand chan]

As i understood it, the EVR is not really equiped to deal with 10-bit input formats.

Why not? It handles 32 bit floating point textures and processing just fine, and it can output 10 bit A2R10G10B10 to the display in D3D fullscreen mode. The only thing it's lacking is 10 bit input, but all dithering, post processing etc. is done with 32 bit precision then dithered down to 10. (Which is more than madVR will probably ever be capable of)

[Mangix]

madVR does processing in 48-bit IIRC and scales down to 8-bit. 10-bit output is missing only.

[nand chan]

madVR does processing in 48-bit IIRC and scales down to 8-bit. 10-bit output is missing only.

By 48 bit you mean 16 bit. 16 × 3 = 48, because there are three channels. There's no such thing as a 48 bit floating point number. If you want to do it that way, then EVR-CP would be 96 bit.

[nevcairiel]

Why not?
Because that part is handled in the EVR mixer, which is a completely separate part to the presenter which does all the other things you speak of.

The mixer is still the vanilla Microsoft Mixer, which is quite limited. It even doesn't properly support 4:4:4 AYUV input.
It only supports formats that are natively supported by the hardware as texture formats, which may include 32-bit float, but only in RGB space, not in sub-sampled YUV.

To add all these missing features, one would have to rewrite the whole mixer, as you can't just "extend" the built-in mixer. EVR is not a design suited for such advanced tasks, once you have replaced the mixer and the presenter, you could as well just get rid of the remaining minor parts of EVR, and write a new renderer from scratch. JanWillem looked into 10-bit input a while ago, and concluded that its currently out of reach.

In comparison, writing a Presenter to replace the default presenter is easy, the mixer is the hard part.

EVR is really just a wrapper around the hardware, with the addition to run pixel shaders on the content, but it'll never reach a flexibility or feature set a stand-alone renderer would be capable of.
It also has alot of other serious limitations, mostly regarding dynamic format changes and RGB levels. For example, EVR is incapable of dynamically switching its input pixel format, which means if its not possible to probe the best pixel format before decoding, you'll end up down-converting the video because EVR failed at dynamically switching to the best format. There are quite some other difficulties with it, but thats one of the bad ones. :)

PS:
I still think 32-bit float is just wasted computational power. The actual output is 8 (or maybe 10) bit. What good is creating a intermediate result in 32-bit precision?
More bits = more better, right? :)

PPS:
If this is all about the subtitle issue, why not just work on fixing that situation? :d

[nand chan]

Because that part is handled in the EVR mixer, which is a completely separate part to the presenter which does all the other things you speak of.

The mixer is still the vanilla Microsoft Mixer, which is quite limited. It even doesn't properly support 4:4:4 AYUV input.
It only supports formats that are natively supported by the hardware as texture formats, which may include 32-bit float, but only in RGB space, not in sub-sampled YUV.

To add all these missing features, one would have to rewrite the whole mixer, as you can't just "extend" the built-in mixer. EVR is not a design suited for such advanced tasks, once you have replaced the mixer and the presenter, you could as well just get rid of the remaining minor parts of EVR, and write a new renderer from scratch. JanWillem looked into 10-bit input a while ago, and concluded that its currently out of reach.

In comparison, writing a Presenter to replace the default presenter is easy, the mixer is the hard part.

So basically, I have to keep inputting NV12? Wouldn't it be possible to, say, upscale P010 -> Y410 then convert that to RGB32 (A2R10G10B10) in software, and pass the RGB32 texture to the EVR mixer, and have it convert that to a 32 bit floating point texture?

EVR is really just a wrapper around the hardware, with the addition to run pixel shaders on the content, but it'll never reach a flexibility or feature set a stand-alone renderer would be capable of.
It also has alot of other serious limitations, mostly regarding dynamic format changes and RGB levels. For example, EVR is incapable of dynamically switching its input pixel format, which means if its not possible to probe the best pixel format before decoding, you'll end up down-converting the video because EVR failed at dynamically switching to the best format. There are quite some other difficulties with it, but thats one of the bad ones. :)

If mixed with the idea above that could become a non-issue, just always pass RGB32.

PS:
I still think 32-bit float is just wasted computational power. The actual output is 8 (or maybe 10) bit. What good is creating a intermediate result in 32-bit precision?
More bits = more better, right? :)

Always. I'm doing a lot of post processing so I want my bits. :(

PPS:
If this is all about the subtitle issue, why not just work on fixing that situation? :d

Nah, it's not about the subtitle issue. I've given up on that, with the conclusion that all subtitle renderers are shit. Oh, I should mention that EVR-CP color corrects subtitles properly unlike madVR, so that's another plus!