Media Player Classic Home Cinema (MPC-HC) - DXVA!

[cengizhan]

Did you check the mapping for "Framestep" and "Framestep back"? The default keys have recently changed.

Thanks. i thought that was all about jumping. the new framestep was also ctrl+right. removed it and fixed the problem.

i think it will be very helpfull if you make mapping list sortable by name, key etc. And the program should refuse and disable dublicate key mappings.

[clsid]

Good news. I have fixed the vertical padding functionality in VSFilter. Also, a patch has been committed that significantly improves performance of subtitles in VSFilter and MPC.

Does any of the other devs perhaps has some time to update the settings page of VSFilter with this suggestion:
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/VSFilter/DirectVobSubFilter.cpp?r1=3260&r2=3259&pathrev=3260

[Underground78]

Does any of the other devs perhaps has some time to update the settings page of VSFilter with this suggestion:
http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/VSFilter/DirectVobSubFilter.cpp?r1=3260&r2=3259&pathrev=3260

Something like that (http://i.imgur.com/15KnH.png) ?

[clsid]

Yes, that looks good.

[GrofLuigi]

[Commands2]
CommandMod0=891 3 0 "" 5 0 13
CommandMod1=892 b be "" 5 0 0
CommandMod2=893 b bc "" 5 0 0
CommandMod3=901 3 be "" 5 0 0
CommandMod4=900 3 bc "" 5 0 0
CommandMod5=905 b 27 "" 5 0 0
CommandMod6=904 b 25 "" 5 0 0

In short, try the above.

edit: This may have been reverted.

Thank you, but I wanted an explanation on the meaning of the entries so I can figure out what was changed and why (I forgot why I made some of the entries, some were changed by MPC-HC itself maybe, and there might be errors).

Like, what does be, bc mean; what are the codes for modifier keys and where... I'll by trial and error if I have to, but I was hoping for an explanation.

GL

[v0lt]

@GrofLuigi
There was an error. It is fixed in v1.5.2.3262.
I do not recommend using versions 3247...3261.

[Underground78]

Yes, that looks good.

You can try this test build (http://www.mediafire.com/?5ef9tk7b01a22vi).

[clsid]

You can try this test build (http://www.mediafire.com/?5ef9tk7b01a22vi).The settings aren't saved correctly.
The buttons to increase/decrease buffer size should be inverted. Top one should increase instead of decrease.

[Underground78]

The settings aren't saved correctly.
The buttons to increase/decrease buffer size should be inverted. Top one should increase instead of decrease.

That was really stupid, damn copy/paste ... :o It should be fixed in this build (http://www.mediafire.com/?qad8mazqaonen31).

[clsid]

Buffer option works now. But animation option still broken.

[Underground78]

Buffer option works now. But animation option still broken.

Problem found, I was not reading the same key I was writing in the registry so the saved value was not reloaded ... I hope it is ok now : VSFilter_v3.7z (http://www.mediafire.com/?oukb4ur3rk0fxzy) !

[Midzuki]

Problem found, I was not reading the same key I was writing in the registry so the saved value was not reloaded ... I hope it is ok now : VSFilter_v3.7z (httpwww.mediafire.comoukb4ur3rk0fxzy) !

httpwww.mediafire.comoukb4ur3rk0fxzy cannot be OK :)

[namaiki]

http://www.mediafire.com/?oukb4ur3rk0fxzy

Regarding the "allow animation when buffering" checkbox-

In v3: Tick means animation is disabled when buffering, unticked means buffer with animation.

So, you could either reverse the function of the checkbox or reverse the displayed name/action of the checkbox. To disable buffering, user can change 'sub pictures to buffer' to '0'.

[Midzuki]

@namaiki: Thanx :thanks:

[Underground78]

Sorry for the link, I still don't understand how this happened ... :eek:

In v3: Tick means animation is disabled when buffering, unticked means buffer with animation.

So, you could either reverse the function of the checkbox or reverse the displayed name/action of the checkbox.

I have kept the same name than in MPC-HC and reversed the action of the checkbox: VSFilter_v4.7z (http://www.mediafire.com/?b892nk7946dl1o0).

To disable buffering, user can change 'sub pictures to buffer' to '0'.

Is that ok ? It was done like that in MPC-HC so I have kept it the same way.

[namaiki]

I have kept the same name than in MPC-HC and reversed the action of the checkbox: VSFilter_v4.7z (http://www.mediafire.com/?b892nk7946dl1o0).

Everything seems to work as it should. Awesome work! :D

Is that ok ? It was done like that in MPC-HC so I have kept it the same way.
I think it should be fine as long as animation is enabled by default. Also, I might recommend buffer set to 4 subpictures by default due to flickering subtitles on 3 when there is more than a single subtitle line on the screen.

[clsid]

Working OK now, so time to commit.
Changing buffer size to 4 should be fine. Please change it in MPC as well. The old default in VSFilter was 10, but I don't know if a larger buffer than 4 has much real benefit.

I did notice a crash when changing the settings during playback. Perhaps that can be solved by reading the setting into two vars, one for usage during playback, and one purely for the GUI. So no real-time update of the setting.

I did some basic benchmarks to test the performance of subs. These numbers were gathered with ProcessExplorer and from just one run per test, so take results with a grain of salt.
I measured the total CPU time used by MPC while playing a 720x480 H.264 clip with subtitles that have karaoke effects. Clip duration 1m46s.

Without subs
6.74 seconds

New VSFilter, Buffer = 0
12.38

VSFilter 2.39, Buffer = 0
13.09

New VSFilter, Buffer = 4
10.54

New VSFilter, Buffer = 4, Animation on
13.81

New VSFilter, Buffer = 10
11.01

New VSFilter, Buffer = 10, Animation on
13.76

VSFilter 2.39, Buffer = 10
10.78

Conclusions:
- Heavy subtitles can have a big performance impact. Up to 50% of the total CPU usage.
- Animation with buffering uses the most CPU time. Followed by Animation without buffers. Buffering without animation uses the least CPU time.
- Animation can use up to 80% more CPU time than no animation.
- New VSFilter is not much faster than the old one. I expected a bigger difference with the recently added performance tweaks. Perhaps the VSFilterMod additions have some negative effect on performance.

I might do another test with basic SRT subs later to measure performance in case of a non-animated sub.

[tetsuo55]

That is kind of disappointing.

please do the basic SRT test.

[JEEB]

Well, unfortunately VSFilter has been and will continue to be slow. No real news there. And I kind of expected there to be not much of real performance-up, although the "multithreaded VSFilter" guy is relatively enthusiastic, which is a good thing.

Anyways, if we want real speed-ups, someone needs to make fontconfig less awful on Windows so we can use libass instead :3

[clsid]

With a quickly manually created SRT I get results between 7,5 and 7,9 seconds. So those differences are small.
Btw, all the above tests were done with the standard EVR renderer.

EVR CP has a very nasty 'bug' that makes it consume CPU cycles even when paused or when playback has stopped. Hopefully that can be given some priority to fix.

I also tried with the internal sub renderer (and EVR CP instead of EVR), but I got weird results. Both SSA and SRT have same CPU time of 17.0s (buffer 4 + anim), no subs gave 14.4. The measurement method might be inaccurate.

[namaiki]

EVR CP has a very nasty 'bug' that makes it consume CPU cycles even when paused or when playback has stopped. Hopefully that can be given some priority to fix.

I believe it's because it's continually scanning the screen's refresh rate.


I did notice a crash when changing the settings during playback. Perhaps that can be solved by reading the setting into two vars, one for usage during playback, and one purely for the GUI. So no real-time update of the setting.
There is the 'Apply changes immediately' checkbox in the 'Misc' tab. I suppose that could be disabled by default. (please don't get rid of it)

[Underground78]

So everybody agrees with that:
I think it should be fine as long as animation is enabled by default. Also, I might recommend buffer set to 4 subpictures by default due to flickering subtitles on 3 when there is more than a single subtitle line on the screen.
There is the 'Apply changes immediately' checkbox in the 'Misc' tab. I suppose that could be disabled by default. (please don't get rid of it)

If everybody does, I will commit the changes and also update default settings for MPC-HC.

Edit : Here what MPC-HC does to choose if it enables or not animation when buffering :

bool bAllowAnimationWhenBuffering = true;
SYSTEM_INFO SysInfo;
GetSystemInfo(&SysInfo);
if (SysInfo.dwNumberOfProcessors < 3) {
bAllowAnimationWhenBuffering = false;
}

Maybe I should keep something like that ? Although I am not sure it is really useful to check the number of processors if VSFilter is not multithreaded ?

[fastplayer]

Assuming that the code is actually not multithreaded, this sure looks like a lazy man's performance categorization. It is pure nonsense IMO.

[Underground78]

Assuming that the code is actually not multithreaded, this sure looks like a lazy man's performance categorization. It is pure nonsense IMO.

Yeah but I need to be sure the code is not multithreaded at all.

[fastplayer]

Yeah but I need to be sure the code is not multithreaded at all.
Even if it was, it wouldn't be dependent on this setting at all. There's no variable that saves the number of cores and uses it subsequently throughout the code.
We had similar nonsense in ffdshow that Stargazer removed when he cleaned up the colorspace conversion code.

[Underground78]

Even if it was, it wouldn't be dependent on this setting at all. There's no variable that saves the number of cores and uses it subsequently throughout the code.
We had similar nonsense in ffdshow that Stargazer removed when he cleaned up the colorspace conversion code.

I am not sure to understand, it is just an hint for the user I guess so why would you need a variable to save the number of core ? However I am quite sure it was wrongly chosen and I will probably delete it.

[fastplayer]

I am not sure to understand, it is just an hint for the user I guess so why would you need a variable to save the number of core ? However I am quite sure it was wrongly chosen and I will probably delete it.
The code basically says that anything with less than 3 cores is not suitable of running sub animations which is total nonsense of course. Especially considering that the code itself is not multithreaded at all.

My suggestion:
bool bAllowAnimationWhenBuffering = true;
SYSTEM_INFO SysInfo;
GetSystemInfo(&SysInfo);
if (SysInfo.dwNumberOfProcessors < 3) {
bAllowAnimationWhenBuffering = false;
}

r.fSPCAllowAnimationWhenBuffering = !!pApp->GetProfileInt(IDS_R_SETTINGS, _T("SPCAllowAnimationWhenBuffering"), bAllowAnimationWhenBuffering);
replace with
r.fSPCAllowAnimationWhenBuffering = !!pApp->GetProfileInt(IDS_R_SETTINGS, _T("SPCAllowAnimationWhenBuffering"), true);

[clsid]

There is the 'Apply changes immediately' checkbox in the 'Misc' tab. I suppose that could be disabled by default. (please don't get rid of it)Disabling that option is not a good idea. It is useful for seeing effects of font and size changes.
The crash only happens with the two new settings. Just do not apply those changes directly.

The rationale behind the number of processors check is that a CPU with multiple cores is usually a reasonably fast one.

I believe it's because it's continually scanning the screen's refresh rate.That could be made conditional based on the playback state. Maybe the scan interval can be increased as well to lower CPU usage. Isn't the refresh rate typically a constant value? Except maybe at the start if rate changing is enabled.

[Underground78]

Disabling that option is not a good idea. It is useful for seeing effects of font and size changes.
The crash only happens with the two new settings. Just do not apply those changes directly.

I've changed the code so that those two settings are not applied immediately : VSFilter_v5.7z (http://www.mediafire.com/?77q365o7fq0td7o). I have also change the default to 4 and true but I can still change this.

The rationale behind the number of processors check is that a CPU with multiple cores is usually a reasonably fast one.

This is how I understood it at first that's why I am not sure what to do. Even if it is a test for lazy, we may not want to always enable this setting.

[clsid]

Working fine now.

The core detection code is only used for the default setting. It is only used if the value was not yet set in the Registry/INI.

[cyberbeing]

I measured the total CPU time used by MPC while playing a 720x480 H.264 clip with subtitles that have karaoke effects. Clip duration 1m46s.

CPU time alone is not a good way to judge VSFilter performance. The real question is if there is a gain in FPS with extremely heavy scripts, which are unable or barely playback in real-time on slower computers.

I did some testing, and in most cases gommorah's fixed string manipulation patch results in a 0-2% increase in avg framerate on difficult samples when VSFilter is CPU limited and prebuffering is disabled (r3255 vs r3262 from xvidvideo.ru). Some subtitle samples and CPUs likely benefit from the patch more than others, but at least this resolved one of many causes of VSFilter slowdowns. Since the code hasn't really changed much, it's likely the optimizations from VS2010 vs VS2005 results in most of the gain over Guliverkli2.

AMD X2 4800+ (939) @2.64Ghz on WinXP SP3

VSFilter r3262 (xvidvideo.ru VS2010)
KaraokeSample1: ~22 fps
KaraokeSample2: ~20.5 fps
TypesettingSample1: ~20.5 fps

VSFilter r3255 (xvidvideo.ru VS2010)
KaraokeSample1: ~21.75 fps
KaraokeSample2: ~20 fps
TypesettingSample1: ~20 fps

VSFilter r3242 (VS2010 WPO+PGO)
KaraokeSample1: ~22.5 fps
KaraokeSample2: ~22.75 fps
TypesettingSample1: ~21.25 fps

VSFilter 2.39.5.2 (Guliverkli2 VS2005)
KaraokeSample1: ~20.75 fps
KaraokeSample2: ~16.75 fps
TypesettingSample1: ~19.25 fps

Note: The above are rough measurements, averaged over a few runs on 1000-2000 frame clips. They are accurate enough to see which builds are faster/slower with the samples tested, but not accurate enough to determine exact performance gains/losses in the way I tested. The r3242 WPO+PGO build I just added for comparisons sake. I haven't taken the time to make a new build, but I suspect a r3262 WPO+PGO build would have a similar 0-2% gain with the patch like the xvidvideo.ru builds do.

[Underground78]

The core detection code is only used for the default setting. It is only used if the value was not yet set in the Registry/INI.

Yeah I know but what should I do ? Keep 4 and true as default settings for VSFilter ? Should I port them back to MPC-HC (getting rid of the core check) ?

I never use animation in subtitles so I don't really know what to do ...

[VipZ]

Yeah I know but what should I do ? Keep 4 and true as default settings for VSFilter ? Should I port them back to MPC-HC (getting rid of the core check) ?

I think the 3 core check seems kind of odd, as this eliminates Core2Duo's but includes AMD Phenom X3 which are typically clocked lower and slower clock for clock. Especially since its not multithreaded.

Maybe if a check is desired something like this,
WinXP = 3 cores (Mostly to keep it away from older P4's with HT)
Vista+Windows7 = 2 cores

[clsid]

I say commit with 4 as default in both VSFilter and MPC. Use true for the anim option. It can always be changed later if needed.

[neb1236]

Hi, since revision 3262 (fixed vertical padding) placement of Drawing is wrong (I don't know why and how).
Here is a self explanatory image, I used Aegisub to render it so we can see the anchor point, but I have tested on a video, and the result is the same:
http://img808.imageshack.us/img808/8107/examplerb.png

Thanks for reading.

[namaiki]

Hi, since revision 3262 (fixed vertical padding) placement of Drawing is wrong (I don't know why and how).
Here is a self explanatory image, I used Aegisub to render it so we can see the anchor point, but I have tested on a video, and the result is the same:
http://img808.imageshack.us/img808/8107/examplerb.png

Thanks for reading.
It would be much appreciated if you could upload your video/subtitle sample so that this issue can be reproduced.

[neb1236]

It would be much appreciated if you could upload your video/subtitle sample so that this issue can be reproduced.

Of course, here it is, under the form of a test case: http://www.mediafire.com/?6at2mvvzhb3xd97

[clsid]

With the old VSFilter 2.39 it also isn't perfect. Without padding the blue boxes are slightly larger, but the black boxes are positioned correctly. With padding enabled, the black boxes are stretched vertically. But padding is something not really suitable for subs that need specific positioning above the video.

With new VSFilter, the black boxes are positioned wrong even with padding disabled.

[neb1236]

Oh, sorry, forgot to mention the reference image, (I didn't made the square the same size), here is reference image, and the result with r3262, it's not a very good testcase:
http://img717.imageshack.us/img717/2954/resultu.png

[cyberbeing]

I can confirm what neb1236 is seeing when Vertical Padding is set to Original Height in r3262.

CCCP's r339/r1096 basevideofilter revert patches doesn't have the positioning bug seen in neb1236's r3262 image and fixes Vertical Padding in VSFilter. Identical results to Guliverkli2.
Edit: My mistake, it turns out I tested the wrong build which only had the r339/r1096 basevideofilter revert patches. The build with r339/r1096 basevideofilter revert patches and gommorah's patch did have the bug. It looks like CLSID fixed this in r3270.

CLSID's custom Vertical Padding Fix patch in r3261 does have the positioning bug seen in neb1236's r3262 image.

[clsid]

r3261 should have the same effect as reverting 339/1096. Some fresh eyes looking at that code would be helpful. I might have overlooked something.

[Eliminateur]

noone of the internal filters appear to be working i select all of them, ffmpeg and dxva and i always get a pin failed to render message.
no matter if i disable them in ffdshow or not
r3262 x64

[v0lt]

mpc-hc_3268_dts_ac3_test1.7z (http://www.mediafire.com/?wveo5je94w57y8g)
DTSAC3Source:
+ Added support DTSWAV (DTS-CD)
+ Added search DTS and AC3 headers (skip garbage in the beginning)
+ Improved support for AC3 and E-AC3

[JohnLai]

Next question, does full floating point processing work with ATI? I can't use it, if I do, it resulted in either black screen or flickering black and white. (in dxva mode)

[TheElix]

Next question, does full floating point processing work with ATI? I can't use it
I can. I have an HD6950.

I have a different problem which is quite terrible. I can't change files with PgUp/PgDn when I'm in D3DFS. When I try to do so everything's normal except one thing: video is frozen on the last frame of the previous video. It's as if the video card fails to see the need to show any changes! Sound is running normal but seekbar as well as mouse cursor aren't showing up. Catalyst 11.6, everything is set to use application settings. All video enhancers are off. I use EVR CP and tried every option in renederer settings. Tried different splitters as well. Tried uninstalling the player with its settings and with a fresh install it's the same thing.
:confused:

[JanWillem32]

I can. I have an HD6950.

I have a different problem which is quite terrible. I can't change files with PgUp/PgDn when I'm in D3DFS. When I try to do so everything's normal except one thing: video is frozen on the last frame of the previous video. It's as if the video card fails to see the need to show any changes! Sound is running normal but seekbar as well as mouse cursor aren't showing up. Catalyst 11.6, everything is set to use application settings. All video enhancers are off. I use EVR CP and tried every option in renederer settings. Tried different splitters as well. Tried uninstalling the player with its settings and with a fresh install it's the same thing.
:confused:It's an old problem of the renderer termination sequence in exclusive mode. It causes the old renderer instance to keep attached to an exclusive mode session on a display output, and it disallows new sessions to take possession of it. I re-wrote that part of the renderer fist in March, and I've made several optimizations for this part after that. Note that EVR is usually more sensitive to this problem than VMR, due to different unloading speeds. I've yet to integrate any optimizations I've made over time since January. There are some regressions in my version of the renderer core that inhibit me from requesting integration of the code I wrote. The most notable problem is the incompatibility with some the original VSync code.

[TheElix]

JanWillem32, are you a wizard (http://angrywhitedude.com/wp-content/uploads2/2010/05/are-you-wizard.jpg)? The problem is gone with your build! Why don't other development folks use your method to prevent this problem?
P.S. And I've almost made up my mind to delete the system.

[JanWillem32]

I'm not going to try to break up my re-written parts of the renderer for partial integration. I've re-written almost the complete rendering engine, and the allocator-presenter is re-written for more than a quarter of the total code. There's little resemblance in some parts of the rendering method. That causes incompatibility with a lot of the older code. The best I can do at the moment is to provide users with tester builds and interact in the thread I made. I use this method as a way to work towards offering the renewed version of the internal renderer sections as a complete replacement, rather than a patch of the original code. I most certainly know I have bend over backwards to ever get the three VSync items to work again as they used to. I'll just have to make it work, but it's very hard for me to understand the cohesion in the many 64-bit items it uses, with timescales in millisecond, 100 nanosecond, nanosecond, second and per second timing units. I would never have written it in this way. (I'm usually lazy in this regard and just activate the video card's own internal VSync, or let desktop composition handle the VSync in windowed mode, but I'm a lot more familiar with DirectX 10 and 11 than 9, anyway.)

[TheElix]

I see. Well, your method is the only one that makes internal autochange frequency work for me. That just makes one more reason for me to stick to your versions for now. By the way, does autofrequency in your build work for you with D3DFS?

[JanWillem32]

The exclusive mode frequency adjustment part is officially on the "to do" list, but if the display frequency is already set while the program is in windowed mode, the code I wrote will happily accept normal (whole number) and NTSC refresh rates (those are 1/1.001 adjusted) from the currently active state in windowed mode. If the exclusive mode is activated before this kind of frequency change command is used, that command is simply negated.
I didn't know this function worked at all in my builds. I haven't paid much attention to this part, I just tried to fix the critical things first. I'll have to add this function to the "to test if it works in all cases" list then...
If it doesn't really work in exclusive mode I can try to make a link to the allocator-presenter. It could then inherit the custom set frequency number directly from the user-set options and enable it on an output by itself, instead of inheriting the frequency from the windowed mode before it.