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

[Scoty]

Is MPC-HC with VS2010 better?

[MPC-HTPC]

I was under the impression that MPC-HC is faster in regards of responsiveness, when using it on my sveral PCs. Anyway, there are no additional features/functions in this build.

[XhmikosR]

I need some help with (building MPC-HC x64) "Building ffmpeg x64 (libavcodec) with GCC "

I followed the guide (part E) and nothing it's working!
First there is no "buildffmpeg.sh" so $ ./buildffmpeg.sh --updatemingw
sh: ./buildffmpeg.sh: No such file or directory
and using ./buildmingwlibs.sh --updatemingw --compilemingw gives me an svn.exe error
and
$ ./buildmingwlibs.sh --compilemingw
Compiling MinGW64 crt and headers...
./buildmingwlibs.sh: line 87: ../mingw-w64-crt/configure: No such file or direct
ory

P.S. I can compile MPC-HC x86 with VS2010 with no problems

It works just fine for me. Obviously buildffmpeg.sh doesn't exist since it's been renamed to buildffmpeglibs.sh. The second error is caused because you have not download the mingw64 src before running --compilemingw. So just do

buildmingwlibs.sh --updatemingw

and then

buildmingwlibs.sh --compilemingw

or this which you said you did already but I don't see that from your post: buildmingwlibs.sh --updatemingw --compilemingw

If you still can't build it, use this: http://xhmikosr.1f0.de/mpc-hc_patches/libmingwex.a_x64.7z


Also like I said in my previous posts, there's no reason to use SDK 7.1 with VS2010. The only thing is the warning we get with SDK 7.0A when embedding the manifest. The projects in the SVN do not use SDK 7.1.

[Mercury_22]

Of course buildmingwlibs.sh --updatemingw gives me the same svn.exe error The application was unable to start correctly (0xc000007b).

Again my os is x64 (windows 7) maybe that's what's cause it ?!

Edit: in "Path" environment variable doesn't needed to be added the ;%MINGW64%\bin too?

Edit 2 using your "libmingwex.a_x64" I get 1>------ Build started: Project: Filters (Filters\Libraries\Filters), Configuration: Release x64 ------
2>------ Skipped Build: Project: libavcodec, Configuration: Release x64 ------
2>Project not selected to build for this solution configuration
3>------ Build started: Project: libavcodec_gcc, Configuration: Release x64 ------
1>Build started 08/19/2010 07:19:47.
1>InitializeBuildStatus:
1> Creating "C:\MPC-HC\bin\obj\Release_x64\Filters\Filters.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
1>Lib:
1> All outputs are up-to-date.
1> Filters.vcxproj -> C:\MPC-HC\bin\lib\Release_x64\Filters.lib
1>FinalizeBuildStatus:
1> Deleting file "C:\MPC-HC\bin\obj\Release_x64\Filters\Filters.unsuccessfulbuild".
1> Touching "C:\MPC-HC\bin\obj\Release_x64\Filters\Filters.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.39
3>Build started 08/19/2010 07:19:47.
4>------ Skipped Build: Project: libdirac, Configuration: Release x64 ------
4>Project not selected to build for this solution configuration
5>------ Skipped Build: Project: DiracSplitter, Configuration: Release x64 ------
5>Project not selected to build for this solution configuration
3>Build:
3> make.exe: Nothing to be done for `all'.
3>
3>Build succeeded.
3>
3>Time Elapsed 00:00:04.47
6>------ Build started: Project: mpc-hc, Configuration: Release x64 ------
6>Build started 08/19/2010 07:19:52.
6>InitializeBuildStatus:
6> Touching "C:\MPC-HC\bin\obj\Release_x64\mpc-hc\mpc-hc.unsuccessfulbuild".
6>PreBuildEvent:
6> SubWCRev: 'C:\MPC-HC\'
6> Last committed at revision 2272
6> Updated to revision 2272
6> Local modifications found
6> SubWCRev: 'C:\MPC-HC\'
6> Last committed at revision 2272
6> Updated to revision 2272
6> Local modifications found
6>ClCompile:
6> All outputs are up-to-date.
6> All outputs are up-to-date.
6> All outputs are up-to-date.
6> All outputs are up-to-date.
6>ResourceCompile:
6> All outputs are up-to-date.
6>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(C:\MPC-HC\bin\mpc-hc_x64\mpc-hc.exe) does not match the Linker's OutputFile property value (C:\MPC-HC\bin\mpc-hc_x64\mpc-hc64.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
6>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5): warning MSB8012: TargetName(mpc-hc) does not match the Linker's OutputFile property value (mpc-hc64). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
6>MPCVideoDec.lib(utils.o) : warning LNK4217: locally defined symbol toupper imported in function ff_toupper4
6>MPCVideoDec.lib(log.o) : warning LNK4217: locally defined symbol _vsnprintf imported in function av_log_default_callback
6>MPCVideoDec.lib(log.o) : warning LNK4217: locally defined symbol __iob_func imported in function av_log_default_callback
6>MPCVideoDec.lib(interf_dec.o) : warning LNK4049: locally defined symbol __iob_func imported
6>MPCVideoDec.lib(sp_dec.o) : warning LNK4049: locally defined symbol __iob_func imported
6>MPCVideoDec.lib(sww32thread.o) : warning LNK4217: locally defined symbol _beginthreadex imported in function sws_thread_init
6>MPCVideoDec.lib(w32thread.o) : warning LNK4217: locally defined symbol _beginthreadex imported in function avcodec_thread_init
6>MPCVideoDec.lib(lib64_libmingwex_a-vsnprintf.o) : error LNK2019: unresolved external symbol __vsnprintf referenced in function _vsnprintf
6>MPCVideoDec.lib(lib64_libmingwex_a-snprintf.o) : error LNK2001: unresolved external symbol __vsnprintf
6>MPCVideoDec.lib(lib64_libmingwex_a-vsnwprintf.o) : error LNK2019: unresolved external symbol __vsnwprintf referenced in function _vsnwprintf
6>MPCVideoDec.lib(lib64_libmingwex_a-snwprintf.o) : error LNK2001: unresolved external symbol __vsnwprintf
6>MPCVideoDec.lib(mpc_helper.o) : error LNK2019: unresolved external symbol __mingw_aligned_malloc referenced in function FF_aligned_malloc
6>MPCVideoDec.lib(mem.o) : error LNK2001: unresolved external symbol __mingw_aligned_malloc
6>MPCVideoDec.lib(mpc_helper.o) : error LNK2019: unresolved external symbol __mingw_aligned_free referenced in function FF_aligned_free
6>MPCVideoDec.lib(mem.o) : error LNK2001: unresolved external symbol __mingw_aligned_free
6>MPCVideoDec.lib(mpc_helper.o) : error LNK2019: unresolved external symbol __mingw_aligned_realloc referenced in function FF_aligned_realloc
6>MPCVideoDec.lib(mem.o) : error LNK2001: unresolved external symbol __mingw_aligned_realloc
6>MPCVideoDec.lib(swscale.o) : error LNK2019: unresolved external symbol snprintf referenced in function sws_format_name
6>MPCVideoDec.lib(log.o) : error LNK2001: unresolved external symbol snprintf
6>MPCVideoDec.lib(pixdesc.o) : error LNK2001: unresolved external symbol snprintf
6>C:\MPC-HC\bin\mpc-hc_x64\mpc-hc64.exe : fatal error LNK1120: 6 unresolved externals
6>
6>Build FAILED.
6>
6>Time Elapsed 00:00:03.93
========== Build: 2 succeeded, 1 failed, 62 up-to-date, 3 skipped ==========

Don't I need the libgcc.a too?

[nevcairiel]

The project file still looks for GCC 4.4.4, if you are using 4.5.1, you need to change the library lookup directories in the MPCVideoDec VS project.

[XhmikosR]

If you used the package from the wiki everything should work. That's what I use and I build all the builds successfully. Fix your system, follow the guide step by step. Also do a rebuild if you didn't already.

[Mercury_22]

I've copy the libgcc.a from "C:\MSYS\mingw\lib\gcc\x86_64-w64-mingw32\4.5.1" into lib64 directory and now I can build x64 version too (using your libmingwex.a_x64)
I've also added the ;%MINGW64%\bin in "Path" environment variable

EDIT It's working with 4.5.2 too ( from http://www.xvidvideo.ru/component/docman/cat_view/28-cross-mingwgcc-x86x64.html ) but in the help / about it's still saying 4.5.1 (for both x86 & x64 version) How do I update that?

EDIT2 It's also working with libgcc.a & libmingwex.a from 4.5.2 (manual copied into lib64), svn.exe still gives me the error

[XhmikosR]

Well, it's pretty obvious that if you change the gcc version you will have to modify your system accordingly (That's what the wiki article says too). Anyway, I updated the wiki article. Hundreds of people follow the wiki and are able to compile mpc-hc, so use the msys/mingw package linked in the wiki and follow each step.

[SantinoSan]

Not sure if it is a bug or if I have something configured wrong, but I cannot get PCM sountracks from a Blu-ray rip in an MKV container to play. The file will play in Mediaportal, so it seems the file is fine. Any ideas?

Thanks,
Santino

[XhmikosR]

@SantinoSan: You provide no sample and no info such as which rev you are using.

[Mercury_22]

A small suggestion for the part E of How-to compile MPC-HC wiki:
Part E: Building ffmpeg x64 (libavcodec) with GCC

When building ffmpeg (project libavcodec_gcc) in 32 bit mode, GCC is used and according to the makefile that is automatically invoked from the solution.

Doing so for 64 bit, requires libgcc.a and libmingwex.a to be placed in C:\mpc-hc\lib64

For that you can either manually copy libgcc.a from your ...\mingw\lib\gcc\x86_64-w64-mingw32\4.5...

Example
C:\MSYS\mingw\lib\gcc\x86_64-w64-mingw32\4.5.1
and libmingwex.a from ...\mingw\x86_64-w64-mingw32\lib

Example C:\MSYS\mingw\x86_64-w64-mingw32\lib
Or :

Run MSYS and cd to the ...\src\filters\transform\MPCVideoDec\ffmpeg_x64 folder

Example:

cd /c/mpc-hc/src/filters/transform/MPCVideoDec/ffmpeg_x64/

(notice that the first part will most probably differ for the exact paths)

checkout the mingw files by running:

./buildmingwlibs.sh --updatemingw

run the buildmingwlibs.sh script, only to compile:

./buildmingwlibs.sh --compilemingw

Or

./buildmingwlibs.sh --updatemingw --compilemingw

After the compilation is done, libgcc.a and libmingwex.a will be placed in C:\mpc-hc\lib64

Now libavcodec can be compiled from within the mpc-hc visual studio solution file, and it will be linked correctly with the other components.


EDIT...

[XhmikosR]

What are you talking about? The only bash script in ffmpeg_x64 folder is the buildmingwlibs.sh. Everyone can use whatever works for them, I don't do what the wiki says, but it's the easiest thing for newbies.

[Mercury_22]

What are you talking about? The only bash script in ffmpeg_x64 folder is the buildmingwlibs.sh. Everyone can use whatever works for them, I don't do what the wiki says, but it's the easiest thing for newbies.

Sorry I didn't see you've already modified the wiki I was referring to ./buildffmpeg.sh --updatemingw not buildmingwlibs.sh (copy /paste error :) ) so never mind the last part

[sansnom05]

Well, it's pretty obvious that if you change the gcc version you will have to modify your system accordingly (That's what the wiki article says too). Anyway, I updated the wiki article. Hundreds of people follow the wiki and are able to compile mpc-hc, so use the msys/mingw package linked in the wiki and follow each step.

Hi, XhmikosR,

Using the file(libmingwex.a_x64) you attached for Mercury_22, along with libgcc.a from lib\gcc\x86_64-w64-mingw32\4.5.1, put them both under mpchc\lib64, I can successfully build mpc-hc x64 version.

However, use the procedure described in your wiki guide, I can't compile libmingwex.a, the reason is simple: the svn.exe included in your msys-mingw-4.5.1 package can not run under my win7 x64, the error message is the same as Mercury_22: "The application was unable to start correctly(0xc000007b). Click OK to close the application." I can confirm that by just open MSYS, and type $svn, the error message is same. So maybe the included svn.exe just can't run under win7 x64? You could check it by yourself.

:thanks:

[XhmikosR]

Thanks for the information, I only have 32bit Windows. The svn.exe comes from TortoiseSVN nightly builds and it depends on some dlls which are installed along with ToirtoiseSVN. So I guess the incompatibility is because you use the 64bit TortoiseSVN and the svn.exe is 32bit. I will probably remove the svn from the package then or replace it with 1.6.6.

EDIT: try the new package.

[Mercury_22]

Hi, XhmikosR,

Using the file(libmingwex.a_x64) you attached for Mercury_22, along with libgcc.a from lib\gcc\x86_64-w64-mingw32\4.5.1, put them both under mpchc\lib64, I can successfully build mpc-hc x64 version.

However, use the procedure described in your wiki guide, I can't compile libmingwex.a, the reason is simple: the svn.exe included in your msys-mingw-4.5.1 package can not run under my win7 x64, the error message is the same as Mercury_22: "The application was unable to start correctly(0xc000007b). Click OK to close the application." I can confirm that by just open MSYS, and type $svn, the error message is same. So maybe the included svn.exe just can't run under win7 x64? You could check it by yourself.

:thanks:

As I've said above you can also find libmingwex.a in your C:\MSYS\mingw\x86_64-w64-mingw32\lib

@XhmikosR Since the libmingwex.a & libgcc.a are already in your package it's there any point / advantage for this update & build them ? Also take in consideration many people have firewalls which need to be configure to allow svn.exe and ...

[XhmikosR]

If it works for you then use it. We had to build the libmingwex.a cause the original one failed when linking (search this thread and take a look at the patch in the ffmpeg_x64 folder).

EDIT: It still needs the custom built libmingwex.a for the x64 build so you will have to build it yourself or use the one I posted.

[sansnom05]

If it works for you then use it. We had to build the libmingwex.a cause the original one failed when linking (search this thread and take a look at the patch in the ffmpeg_x64 folder).

EDIT: It still needs the custom built libmingwex.a for the x64 build so you will have to build it yourself or use the one I posted.

Now everything works as it should be. :thanks:

Maybe you should change the components text file as well. I see now the SVN in package is version 1.6.6. Does this version works on X86 too? I can't test it, but assume it must be true.

And the avcodec included in svn 52851, do you have any plan like move to ffmpeg 0.6 in near future?

[XhmikosR]

Now everything works as it should be. :thanks:

Maybe you should change the components text file as well. I see now the SVN in package is version 1.6.6. Does this version works on X86 too? I can't test it, but assume it must be true.

The components text file is up to date. Everything works as expected.

And the avcodec included in svn 52851, do you have any plan like move to ffmpeg 0.6 in near future?

Yes, but we need someone who can update mpcvideodec's code to use the new ffmpeg API.

[SantinoSan]

I have a small clip from the file I am trying to play with MPC, but am having no luck. Any of my Blu-Ray rps that have a PCM soundtrack act the same way, but will play properly in Mediaportal.

http://www.mediafire.com/file/dgd92wil67bg8nq/CRANK%20%281%29-001.mkv

Any help would be greatly appreciated.
Santino

[XhmikosR]

All right, please open a new ticket at trac (https://sourceforge.net/apps/trac/mpc-hc/newticket).

[blaster00]

I have some problem with mpc audio render. It has a little noises while playing, more than directsound. And very loud sound like screaming after pause.
But foobar2000 with wasapi output works fine. This happens to both my pc and my lap.
Win 7/vista, x86/x64
Mpc-hc x86/x64
Conexant/Realtek sound chip

[Snowknight26]

XhmikosR, can you compile debug builds of both flavors? Trying to add that subtitle crash to trac but it doesn't happen with the latest revision, so I want to confirm that it was really fixed.

[Dreamhacker]

XhmikosR, can you compile debug builds of both flavors? Trying to add that subtitle crash to trac but it doesn't happen with the latest revision, so I want to confirm that it was really fixed.

What subtitle crash?

And XhmikosR, I think my patch with the new subtitle options is pretty much done. Just need someone to test it. :)

[MPC-HTPC]

Both 32- and 64-bit builds crash when playing this sample (http://stfcc.org/misc/bbc2.sample2.ts). The first crash when subtitles are enabled in /src/Subtitles/Rasterizer.cpp:

...

This second crash also happens with this first sample (http://stfcc.org/misc/bbc2.sample.ts) as well. I'll add these issues to the bug tracker when I'm less lazy.

I think he means this subtitle crash, but I cut out the crash reports, since they would consume to much space here and are still available in his original post.

And also good to know that you, Heksesang and Dreamhacker, are the same person. I almost found it a little bit mean from Heksesang to fix the crash-problem first, although you already announced to be working on it... :p Again, great job like all other devs and contributors!

P.S.: I think I won't have access to a Pentium 3 PC before Saturday. So maybe I can test the MSVC 2010 build on this CPU during the weekend.

[Guest]

And also good to know that you, Heksesang and Dreamhacker, are the same person. Heksesang account deleted per rule 14. PM Swede or Doom9 if you want to change your account name.

[Mercury_22]

Thanks for the information, I only have 32bit Windows. The svn.exe comes from TortoiseSVN nightly builds and it depends on some dlls which are installed along with ToirtoiseSVN. So I guess the incompatibility is because you use the 64bit TortoiseSVN and the svn.exe is 32bit. I will probably remove the svn from the package then or replace it with 1.6.6.

EDIT: try the new package.

New package it's working !
Thanks!

[Superb]

tetsuo55, maybe it's time to remove the Bazaar repository (http://sourceforge.net/projects/mpc-hc/develop)...

[bobdynlan]

http://forum.doom9.org/showthread.php?p=1425160#post1425160
ADDITIONS:
- Specify that it only works with updated GCC (4.4.4 fails)
- Specify that the svn command line client that comes with xhmikosr's MSYS package fails in Windows 7 x64; direct users to replace/rename it and install alternatives like Sliksvn
This would have saved 16 posts :) Think Green.
Edit:
[...]Anyway, try it out - maybe you only have trouble with building mingw libs, because of the svn issue. Mercury_22, why didn't you checked on it then?

[XhmikosR]

@bobdylan: again what you suggest is pointless in my opinion. Provide me a case where the current guide with the current tools fails. That's what sansnom05 did and his problem is fixed now.

[bobdynlan]

@bobdylan: again what you suggest is pointless in my opinion. Provide me a case where the current guide with the current tools fails. That's what sansnom05 did and his problem is fixed now. This was strictly about the svn.exe issue that prevented building libs on 7 x64, so get of my back :) Nice to see you've fixed that issue in the current package [was one of those cases you asked for, just read the quotes].

.

[XhmikosR]

Then everything is fine, I guess. Don't get me wrong, I just don't want to change something without any good reason. It works for a lot of people so there's no need to change anything. If something is broken again, feel free to provide the needed details and I'll take a look.

[sansnom05]

Hi, XhmikosR,

Today I'm trying to read the code under the MPCVideoDec, and I find something interesting:

in "DXVADecoder.h", typedef PICTURE_STORE, there is a field "bInUse", right now it's type is "int", should it better be "bool", or is this just some alignment decision? I've changed it to bool and rebuild the project, and nothing is broken as far as I can tell.

Let me know what you think about this. :thanks:

[tetsuo55]

If its a true bool value then changing it to bool probably makes sense.
Can you think of a good reason why its an int now?


tetsuo55, maybe it's time to remove the Bazaar repository (http://sourceforge.net/projects/mpc-hc/develop)...ok

[sansnom05]

If its a true bool value then changing it to bool probably makes sense.
Can you think of a good reason why its an int now?


ok

I've checked all its reference along with the struct PICTURE_STORE, and I can safely confirm that right now, it only holds a boolean value, so it's safe to change its type to "bool" for good name convention's sake.

[tetsuo55]

ok then please provide a patch

[sansnom05]

ok then please provide a patch

Sorry for my ignorance, but how do I do that? Besides, it's only a tiny mini little change, :) do we need call it a patch? Anyway, :thanks:

Edit: I didn't realise that you're the project manager. So could you help me join the project, and guide me on how to send in a patch? I really want to be useful.

[Dreamhacker]

XhmikosR, can you compile debug builds of both flavors? Trying to add that subtitle crash to trac but it doesn't happen with the latest revision, so I want to confirm that it was really fixed.

The samples still crash with the latest builds I compiled. However, when I added another check in one of the functions, it seems to play it all without crashes.

However, I don't see any subtitles with the subtitle track enabled. Are there supposed to be subtitles in the files?

[Snowknight26]

Not sure if there actually are any, but when I try playing it with the internal MPEG splitter, I get one DVB Subtitle track detected.

[Dreamhacker]

Not sure if there actually are any, but when I try playing it with the internal MPEG splitter, I get one DVB Subtitle track detected.

MediaInfo detects AVC video, AC3 audio and two text streams - TeleText and DVB Subtitles.

You've recorded/encoded them yourself?

[GTPVHD]

http://blogs.msdn.com/b/vcblog/archive/2010/06/01/how-we-test-the-compiler-backend.aspx

I have a quick question about the new code generation for SSE int->float conversion in VS2010.

A project specifies /arch:SSE and converts 32 bit integers from memory to an xmm register using this:

00012 66 0f 6e 44 24 04 movd xmm0, DWORD PTR _a$[esp-4]

00018 0f 5b c0 cvtdq2ps xmm0, xmm0

0001b f3 0f 11 46 10 movss DWORD PTR [esi+16], xmm0

Which is fine on my C2D. But isn't cvtdq2ps an SSE2 instruction? I haven't had a chance to pull my Athlon XP out of storage to try it.

@David

Yep this is a known issue and it will be addressed in the next full release of VS, and possibly the service pack for VS 2010.

It's a VC++ 2010 compiler bug thats causing the crashes on SSE only CPUs like Athlon XP and Pentium 3.

[XhmikosR]

Thanks for the info.

[Xorp]

I got a new Geforce GTX 460 video card that seems to force deinterlacing on everything. Problem is that it does a really shitty job. Everything is really choppy/stuttery, it looks like it's blending frames, and framestepping back every other frame at the same time. It also doesn't perform IVTC on 1080i material, so film 1080i60 is deinterlaced to 30fps, not proper 24fps. As you may or may not know, the video controls in the Nvidia control panel are really sparse. The only options are denoiseing, sharpening, and inverse telecine. No deinterlacing options at all. The problem occurs with inverse telecine on and off. Also there are no deinterlacing options in MPC-HC's AVC decoder either. This problem also carry over into TotalMedia Theater and it persists in both Windows XP and Windows 7.

Any suggestions?

[Aleksoid1978]

Not sure if there actually are any, but when I try playing it with the internal MPEG splitter, I get one DVB Subtitle track detected.

Give a sample - i look.

[MPC-HTPC]

Although GTPVHD has already figured out why the MSVC 2010 builds are not working properly on AthlonXP or Pentium 3 CPU's, I also did test an MSVC 2010 build on an Pentium 3 700Mhz since I finally had access to it and promised to do so. According to GTPVHD's findings MPC-HC crashed also on a Pentium 3 CPU when trying to play a file when EVR-Sync, EVR Custom Presenter, VMR9-Renderless or VMR7-Renderless are selected as renderers.

@Aleksoid: You can find two samples of the issue reffered to by Snowknight26 in this post of him: Both 32- and 64-bit builds crash when playing...

[omri09]

When I hold 'Shift' button and then left click on the seek bar, the movie suddenly jump to next frame in a much more smoother way.
How is that happen?

[kieranrk]

It also doesn't perform IVTC on 1080i material, so film 1080i60 is deinterlaced to 30fps, not proper 24fps.

Use the patched IVTC version of Dscaler.

[tetsuo55]

When I hold 'Shift' button and then left click on the seek bar, the movie suddenly jump to next frame in a much more smoother way.
How is that happen?keyframe/Gop based search is great :), but its not exactly where you would point the mouse.

[STaRGaZeR]

keyframe/Gop based search is great :), but its not exactly where you would point the mouse.

It only works with MPC's internal splitters, can it be enabled for other splitters?

[Momber]

reclock esque features.
You guys crack me up.
Have you completely lost touch with reality now?
Instead of adding ever more features you should concentrate on fixing the one million bugs that have been reported.

It's still impossible to play back BBC HD content with DXVA using MPC vid.dec. & ATI by the way. Just to let you know.