Media Player Classic Home Cinema (MPC-HC) - DXVA! [Archive] - Page 172

73ChargerFan

11th July 2009, 04:37

Can someone tell me the registry key to activate D3D Fullscreen GUI support ???

I can't find a way to activate it, because the popup menu item is disabled unless you are playing a video in D3D fullscreen, but then you can't see the popup menu! :sly:

Errr... at least for VMR9 it's selectable as long as a video is opened. No need for the player to be in Direct3D fullscreen...
Thanks Leak... you were right.

It turns out that somehow I had "2d surfaces" selected. Changing to "3d Surfaces" fixed everything, and it now behaves as expected.

boyumeow

11th July 2009, 06:01

Is it possible to build the latest svn revision of MPC with the latest DirectX SDK? I get a lot of errors indicating missing include files (and perhaps missing libraries as well when I come that far). Any hints anybody? Thanks! -A

Would it helps if U install all the directx sdk in the same root folder, like overlapping each one. Thanks.

ADude

11th July 2009, 06:27

ar-jar

11th July 2009, 07:53

Would it helps if U install all the directx sdk in the same root folder, like overlapping each one. Thanks.

Not sure what would happen then. At least it would be an "unclean" build as it would be based on two versions of the SDK that wouldn't necessarily be compatible and could indeed be in conflict. Hopefully some experienced MPC dev makes the effort to bring everything up to date (if there isn't a magic trick that I haven't discovered). -A

Jong

11th July 2009, 08:26

Gosh, go away for a couple of days, and people are reinventing the wheel ! :D

The Cyberlink MPEG2 + DXVA + DVD bug is well known and is already in the bug database. It is known for menu highlighting, I am not sure that subtitle aspect was previously known or not, so that may be an additional bit of information.It did not mention the subtitle problem I have added it.

It was unclear if it affected just Cyberlink or all MPEG2 decoders in DXVA mode. I can confirm IG's comment it also affects the MS decoder.

It also suggested it affects all Windows versions, but XP SP3 definitely works fine here (with VMR9 renderless).

Thank you, Jong. I'll see if any online retailers are still selling PDVD7 and see if I can use that decoder within Directshow. Since I have the same problem with Microsoft's MPEG-2 decoder and the Arcsoft one, I doubt that will help. Thank you for the info though.I don't think PDVD7 will help, although I have not tested it. It does seem to affect all DXVA MPEG2 decoders on Vista (EVR CP).

if you look in the bug tracker though you will see you can get it to work by regressing to an earlier version. Maybe you can use one version for DVDs and one for other things?

Also, unless you are right up against it on CPU (and your PC would have to be very old) Kumi's suggestion of DXVA deinterlacing and ffdshow decoding sounds pretty good. DXVA deinterlacing is why I use the Cyberlink decoder.

_xxl

11th July 2009, 09:24

Is it possible to build the latest svn revision of MPC with the latest DirectX SDK? I get a lot of errors indicating missing include files (and perhaps missing libraries as well when I come that far). Any hints anybody? Thanks! -A
You need DirectX SDK (August 2007) Download (http://www.microsoft.com/downloads/details.aspx?FamilyID=529f03be-1339-48c4-bd5a-8506e5acf571&DisplayLang=en&displaylang=en) because later versions don't have WMR7. You could compare include and lib dir with latest and copy missing files from August 2007 SDK. Same issue with Win7 SDK, some file is missing and can be found in previous VISTA SDK. To compile you could use information from my opening post.

tetsuo55

11th July 2009, 10:19

Is there any reason to keep VMR7?

I believe all supported Os's support VMR9

ar-jar

11th July 2009, 10:26

You need DirectX SDK (August 2007) Download (http://www.microsoft.com/downloads/details.aspx?FamilyID=529f03be-1339-48c4-bd5a-8506e5acf571&DisplayLang=en&displaylang=en) because later versions don't have WMR7. You could compare include and lib dir with latest and copy missing files from August 2007 SDK. Same issue with Win7 SDK, some file is missing and can be found in previous VISTA SDK. To compile you could use information from my opening post.

Thanks, I'm building according to those instructions currently.

Casshern indicated in an other post that the "regular builds" were using a later version of the SDK, the reason being that some shaders don't work with the older SDK. And indeed, many of the shaders produce a lot of stutter on my machine (admittedly I'm using a fairly cheap ATI board). Thus my question. -A

PS. How long do we need to keep support for VMR7? Is anybody actually using it anymore?

tetsuo55

11th July 2009, 10:57

My friend google just told me there is no reason to keep VMR7, all windows version that can run MPC-HC have DirectX9c available as an update or already built in.

I also do not see any reason to keep supporting "windowed" renderers. As far as i can see it's just a crippled version of "renderless", and people can use Overlay if they want overlay features.

There really is no reason for 99% of users to not use EVR-CP or VMR9 renderless. For those who want software based renderers Haali, madVR and old-renderer are available.

All the others should be removed imho, and maybe "null" should be debug only or something.

The remaining options would be:

System default
Old Renderer (Software renderer)
Overlay mixer (hardware renderer)
VMR9 (hardware renderer)
EVR CP (hardware renderer)
Haali renderer (software renderer)
madVR (Software renderer)

(i personally also think we can dump system default and overlay mixer)

While in there we might as well redesign Quicktime and realmedia.
Simply make a checkbox (which is unchecked by default, which means "system default")

Use VMR9 for ... (when these boxes are not checked, the default renderers for these types are used)
Realmedia []
Quicktime []

i wonder if the realmedia and quicktime renderers can be so adjusted that any of the left side renderers would work, then we would only have to add 2 checkboxes

Use selected renderer for this media type instead of the default one (If this is not checked the custom proprierty renderer is used, check the box to use the renderer of your choice)
Realmedia []
Quicktime []

GTPVHD

11th July 2009, 11:09

I personally use VMR9 Renderless on XP SP3 for DXVA support and softsubs support from the internal subtitle engine.

You can't take screenshots using F5 with Overlay. And VMR9 Renderless and Haali is slower than VMR7 Windowed on older hardware. You should just keep all the VMR7 options, it doesn't really matter.

Of course on Vista/Win7, you should default it to EVR Custom for DXVA and softsubs support.

6233638

11th July 2009, 11:09

Is there any way to force MPC-HC to output a specific resolution when in fullscreen mode?

I want to have my windows desktop at 1080p60 and video at 1080p24.

There's a huge list with most of the resolutions supported by my nvidia 9400 but 1080p23 or 1080p24 aren't on that list for some reason. It only goes down to 1080p25.

Even if I set my desktop to 1080p24 (which I dont want) it doesn't show up in MPC-HCs list.

Oh and I found that if I do set a resolution from that option, when I close MPC-HC the process doesn't actually end and I have to use the task manager to close it.

tetsuo55

11th July 2009, 11:16

And VMR9 Renderless and Haali is slower than VMR7 Windowed on older hardware. You should just keep all the VMR7 options, it doesn't really matter. The difference is so small, i doubt anyone using MPC_HC actually has weak enough hardware to see any difference.

VMR9 and EVR-CP work perfectly fine on my GF4MX which is a low budget directx 6 card !!, Also my intel chipset 825 which is slightly newer than the GF4, has no problems with VMR9 and EVR-CP (haali is CPU limited on these systems)

avivahl

11th July 2009, 11:56

My friend google just told me The remaining options would be:

System default
Old Renderer (Software renderer)
Overlay mixer (hardware renderer)
VMR9 (hardware renderer)
EVR CP (hardware renderer)
Haali renderer (software renderer)
madVR (Software renderer)What about regular EVR (not CP)?

tetsuo55

11th July 2009, 12:00

I think regular EVR is the same as VMR# Windowed (but i could be mistaken)

-----

IMHO one should be able to compile MPC-HC with only the newest Directx and windows SDK's, this basically means that for the older stuff we need a zip file with those libraries.

Casimir and i have also been toying with the idea to create a custom mingw for MPC-HC.

Anyone who knows which headers are required from older SDK's could you please put them all on a zip file and host it somewhere? Casimir and i will work on a permanent hosting solution.

Neeto

11th July 2009, 12:10

It did not mention the subtitle problem I have added it.

It was unclear if it affected just Cyberlink or all MPEG2 decoders in DXVA mode. I can confirm IG's comment it also affects the MS decoder.

It also suggested it affects all Windows versions, but XP SP3 definitely works fine here (with VMR9 renderless).

I don't think PDVD7 will help, although I have not tested it. It does seem to affect all DXVA MPEG2 decoders on Vista (EVR CP).

if you look in the bug tracker though you will see you can get it to work by regressing to an earlier version. Maybe you can use one version for DVDs and one for other things?

Also, unless you are right up against it on CPU (and your PC would have to be very old) Kumi's suggestion of DXVA deinterlacing and ffdshow decoding sounds pretty good. DXVA deinterlacing is why I use the Cyberlink decoder.

I've been able to use DXVA deinterlacing on my 2600XT & 4650 with ffdshow by using the NV12 color space in latest ffdshow build and setting the deinterlacing mode in CCC. I uncheck all other colorspaces except NV12 & RGB32 in the ffdshow Output tab.
This way I can use ffdshow MPEG2 decoder, plus mess with any output Levels etc I need to make it match VMC LiveTV playback.

Regards, Neeto

clsid

11th July 2009, 12:11

VMR-7 should NOT be removed and this has already been discussed once in the past. VMR-7 (windowed) is the default renderer on XP, which is still the most used OS. There are still plenty of people who use it as a fallback when the other renderers have issues.

As for the DVD menu/subs issue: DVD menu highlighting is done with subtitles, so that is why the two issues are related.

tetsuo55

11th July 2009, 12:18

I don't think it's too much to ask from users to keep their windows updated, directx 7 is 10 years old now, XP even shipped with DirectX 8.

Can you describe some of the problems that would force a user to use VMR7 windowed?

------------------

EDIT:
I did some more googling on the subject.
Microsoft states it did not "force update" to VMR9 because some older applications where not able to cope with the new or changed functions, they do however recommend any actively developed application to use VMR9 "Renderless", windowed mode is a backwards compatibily feature for some older API's.
(Ofcourse MS recommends EVR (or a custom presenter variant) for Vista and up.)

As we are in full control of our own application, there is no reason to anything other than VMR9 renderless and EVR-CP.
(If VMR9 renderless and EVR-CP really are benchmark-measurably slower than the other hardware renderers, we should troubleshoot and optimise to minimize the difference), not coinsidentally these are the only 2 renderers on which every feature of MPC-HC actually works.

EDIT2:

Would it be possible to compile standalone renderers? We could compile a VMR7 etc renderer so people could still manually install and use it on later builds?

EDIT3:

And i also forgot to mention, there are a truckload of bugs with VMR7 that do not occur in any of the other renderers, which often lead to complete crashes (do note that i am unable to reproduce many of these bugreports)

clsid

11th July 2009, 13:00

VMR9 is also a buggy renderer in many people's opinion. Newer does not always equal better. On Windows XP, the Overlay Mixer is still my favorite. Not everyone cares about DXVA.

The dependency of MPC is mostly for VMR-7 (renderless) I assume, since that is a customized renderer. I doubt it would be needed to remove VMR-7 (windowed).

But why is the never SDK needed? Is there anything broken in the current one that has been fixed in the newer one?

The devs should imo concentrate on fixing the many existing bugs first, before considering removing stuff.

tetsuo55

11th July 2009, 13:19

Well there are currently 4 people interested in VMR9 and EVR from a programming standpoint, there is a real chance most or even all of the remaining bugs will eventually be fixed. (and both of these renderers have enough bugs, that's also true)

however nobody wants to touch VMR7 or Overlay renderer, or any of the "windowed" VMR versions.

Meanwhile renderers like madVR make even EVR seem obsolete...

The newer SDK('s) mainly fix a lot of bugs, and give the dev's access to newer features available in modern os's. In the case of DirectX the newest SDK makes some shader operations up to 2x faster. I doubt this is optimisation, i think MS found a bug that caused it to be 2x slower all these years.

Although i try to get as many bugs fixed as possible, the motivation for fixing them all not very high, a lot of them come from code that noone has even tried to understand yet. From a team-effort developement standpoint MPC-HC is a mess and a PITA to work with.

If you really want to get more bugs fixed, and know how to compile MPC-HC from scratch (assuming a system with no compiling environment and no svn access) and can put that into a easy to follow step by step guide you can be sure that within a short time 10-20 dev's will start submitting bug fixes.(I get approached by willing programmers several times per month, but they usually give up when it turns out MPC-HC is so difficult to compile, and at that point they haven't even complained about the lack of comments)

clsid

11th July 2009, 13:47

however nobody wants to touch VMR7 or Overlay renderer, or any of the "windowed" VMR versions.There is also no reason to touch a non-custom renderer.

If you really want to get more bugs fixed, and know how to compile MPC-HC from scratch (assuming a system with no compiling environment and no svn access) and can put that into a easy to follow step by step guide you can be sure that within a short time 10-20 dev's will start submitting bug fixes.(I get approached by willing programmers several times per month, but they usually give up when it turns out MPC-HC is so difficult to compile, and at that point they haven't even complained about the lack of comments)There already is a compilation guide in the first post:
To compile you need:
* Microsoft Visual C++ 2008 SP1
* Microsoft® Windows® Software Development Kit Update for Windows Vista™ Download
* BaseClasses from same SDK
* DirectX SDK (August 2007) Download
* For VS2008SP1 see ATL Server Library and Tools
* MinGW GCC 4.2.4 x86_32 MinGW - Minimalist GNU for Windows or TDM's GCC/MinGW32 Builds
* MinGW GCC 4.4.0 x86_64 MinGW - Minimalist GNU for Windows 64 to compile libavcodec_gcc.lib.
The baseclasses aren't needed anymore, since they are included in SVN.
The Windows SDK is also not really needed. Visual Studio already has its own Windows SDK.
An easy to use installer for MinGW32 can be found in the first post of the ffdshow topic.
Missing step: libgcc.a and libmingwex.a must be copied from MinGW into the \lib\ directory of MPC.

So updated guide could be:
To compile you need:
* TortoiseSVN
* Microsoft Visual C++ 2008 SP1
* Microsoft® Windows® Software Development Kit Update for Windows Vista™ (optional) (Download (http://www.microsoft.com/downloads/details.aspx?familyid=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en))
* DirectX SDK (must be August 2007 !!!) (Download (http://www.microsoft.com/downloads/details.aspx?FamilyID=529f03be-1339-48c4-bd5a-8506e5acf571&DisplayLang=en&displaylang=en))
* ATL Server Library and Tools (http://www.codeplex.com/AtlServer/Release/ProjectReleases.aspx?ReleaseId=3754)
* MinGW32. Installer can be found here: ffdshow discussion topic (http://forum.doom9.org/showthread.php?p=930660#post930660) (see bottom of the first post)
* Copy libgcc.a and libmingwex.a from the MinGW32 \lib\ directory to the \lib\ directory of MPC's code repository.
* Building a 64-bit build requires MinGW64 and several additional steps. Not recommended for novice developers.
But I doubt you will get many extra skilled developers.

The method that MPC uses for compiling FFmpeg code is unnecessarily complex. If a user adds the MinGW32 bin directory to the system's %PATH% variable, then running "make" is sufficient. My MinGW32 installer updates %PATH% automatically.

tetsuo55

11th July 2009, 13:58

Most programmers have a pre-installed environment, where they store the source on a local or networked disk. Now they have to install a lot of stuff themselves and that can be a challange, and learn about svn too. i wouldn't worry too much about the skill level, judging from people like beliyaal and ar-jar that's not going to be a problem.

Do those downloads include yasm?
Basically all that needs to be added is the path declarations

And someone needs to get those files from the old SDK's into zip so we can do a problem free update to the latest SDK's

EDIT:

Can we legally store those 2 mingw files on the SVN?

clsid

11th July 2009, 14:11

MinGW is open-source, so yes, you could include those files into SVN. You could include my MinGW32 installer as well if you want. It includes all the required stuff, including YASM. It also sets the environment variable "CC" and updates %PATH%. Then the build script for the 32bit build could also be updated, so that no further user actions is needed.

For 64-bit things are more complex.

But developers that don't even know how to use SVN are not really skilled enough to be of use to make MPC better.

tetsuo55

11th July 2009, 14:13

I think that's the best solution, and the same should be done for 64 bit (as far as possible)
This way we also solve the storage problem for the mingw environment, is it up to date with the latest mingw SVN?

contrary to popular believe SVN is not used by 99% of the worlds programmers

clsid

11th July 2009, 14:18

It is not possible for 64-bit. That requires recompiling parts of the MinGW64 distribution. Plus, there is no installer for that, and I am not making one.

contrary to popular believe SVN is not used by 99% of the worlds programmers lol, where did you read that nonsense. Any good programmer knows hows to use a version control system or can easily learn how to use it.

tetsuo55

11th July 2009, 14:26

Too bad about the 64bit part, we will need someone else to take care of that one then.

Would you be willing and able to put the required files on the SVN? (for the 32bit build)

I didn't read it anywhere, i deal with a lot of software companies, and i know many programmers, they do not use any form of SVN, code is stored on networked disks and roaming profiles.

But i do agree that learning SVN should be simple.
(and i also think that an SVN-like system is much better than the scenario i mentioned above)

clsid

11th July 2009, 14:29

Well, those are very unprofessional software companies then. And certainly not representative for the entire software development industry. All software companies I know use version control systems.

tetsuo55

11th July 2009, 14:39

hmmm, it looks like mingw and yasm get updates quite regularly, do you have plans to update the custom mingw installer every so often?

-------------------

This file from the ffdshow project might contain all the file's we need for VMR7.
http://iknowu.net/files/public/ffdshow/old_dx_sdk.rar

If this works we only need the missing files from the windows SDK

clsid

11th July 2009, 14:46

It gets updated whenever there are useful updates.

tetsuo55

11th July 2009, 14:49

Cool!

Ps ffmpeg has not been updated for 3 months, do you still keep track of it, no noteworthy updates?
h264 playback has been broken in the standalone mpcvideodecoder for a while now, an update might fix it.

clsid

11th July 2009, 15:17

I currently don't have time to keep that updated.

tetsuo55

11th July 2009, 15:21

Okay.

Inspector.Gadget

11th July 2009, 15:42

test & report.

Same problem, plus in KMPlayer menus don't work period using the Cyberlink decoder and any renderer.

The Cyberlink MPEG2 + DXVA + DVD bug is well known and is already in the bug database. It is known for menu highlighting, I am not sure that subtitle aspect was previously known or not, so that may be an additional bit of information.

OK thanks.

It did not mention the subtitle problem I have added it.

Well, my work's done for me :D

if you look in the bug tracker though you will see you can get it to work by regressing to an earlier version.

I'll investigate this. Thanks.

kieranrk

11th July 2009, 15:51

Following some discussion with tetsuo55 I've registered #mpc-hc on freenode for mpc-hc development.

irc://irc.freenode.net/mpc-hc

73ChargerFan

11th July 2009, 16:09

(i personally also think we can dump system default and overlay mixer)
Sometimes I must use overlay for two reasons:

1. Some of my videos need the contrast changed, "VMR9 Color Controls" don't work, and using CCC makes my desktop unreadable.

2. Overlay is faster than VMR9r with software rendering. With 1080p videos, I get stuttering with VMR9r but not with overlay.

My HTPC: AMD 4600X2, ATI 4850, XP SP3 MCE 2005

My ideas:
On install / or 1st run, select the default render based on which OS it is running on. XP - VMR9 renderless, Vista/Win7 EVR custom. Default to 3d surfaces so shaders work.

Fix color controls, make them easily accessible and work across everything. If overlay is being used, make calls to the video driver. Otherwise a shader?

Implement a graph rebuild feature. I hate having to exit the application and restart it every time I change a setting.

This is for discussion... I don't want to add it to the feature tracker yet.

_xxl

11th July 2009, 16:18

tetsuo55

11th July 2009, 16:31

Color controls will never work in any non-overlay compatible renderer, this is not a bug.

The only way to fix this is to write completely independent (sofware based) color controls. Like the one in ffdshow.

i understand that the small speed difference between overlay and VMR9 could be the difference in borderline powered hardware. Still i wonder if VMR9 could be optimised to tighten the gap in speed.

I'm not surprised you have tearing problems with the 7900, MPC-HC still needs a lot of work in the refresh rate detection and jitter reduction field. What sucks though is that as far as the dev's can see, we're doing everything as it should be done.

ar-jar

11th July 2009, 17:05

With some video cards including nVidia 7900 WMR9 Renderless and EVR Custom Pres (WinXp Sp3) are unusable because of tearing problem, no D3D doesn't fix my problem. Also some other issues using TV-out.

I'll throw myself into the discussion even though I'm a n00b around here and therefore ignorant.

First about tearing: I never get tearing in my GothPlayer (see link below) that has a custom allocator presenter for VMR9, as long as it stays in sync (which it does). With exclusive mode I *never* get tearing. I've run it with many kinds of NVidia cards and now a low-end ATI card. So I believe tearing could and should be fixed in the MPC flavor of VMR9 too (and EVR for that matter).

I also believe that MPC is a player for geeks (like me), not the common folks that use Media Player or PowerDVD. I mean, how many people out there knows what "flush GPU after Present" means or what a "bicubic" resizer" does? Or the multitude of shaders. (Or perhaps these menus just exist for testing purposes?) We can not be everything to everybody. Thus it is my hypothesis that users in our "target market segment" at least keep their machines updated and that VMR7 w/ custom AP therefore has an insignificant user base. I vote for scrapping it, updating DirectX and focusing on the new renderers. I haven't tried it but I guess all standard renderers, including VMR7, that are registered on the system can still be used?

As for SVN, I had not used it before I started working on MPC although I understand CM in general. SVN was very easy to learn and Tortoise is an excellent interface. SVN is not the biggest hurdle to get started and I guess used by most open source projects nowadays (and CVS is definitely not easier).

What I stumbled on mostly before succeeding with my first build was that yasm wasn't mentioned anywhere in the build instructions (and I still don't see anything about it there), I wasn't sure about the ATL stuff as it was labeled "alpha", and there were a couple of environment variables that I learned about from error messages and a BAT-file as I recall. I still get a bunch of warnings so maybe all isn't fine and dandy yet but at least I can play all common file formats. -A

Edit: I have not tested VMR9 tearing with the 7900 board, only with an old 5000 series-something, 6800, 7600, and 8600 + ATI 3450. Maybe 7900 has specific issues.

kieranrk

11th July 2009, 17:17

What I stumbled on mostly before succeeding with my first build was that yasm wasn't mentioned anywhere in the build instructions (and I still don't see anything about it there), I wasn't sure about the ATL stuff as it was labeled "alpha", and there were a couple of environment variables that I learned about from error messages and a BAT-file as I recall. I still get a bunch of warnings so maybe all isn't fine and dandy yet but at least I can play all common file formats. -A

I think the build guide is now correct apart from the code embeds not working and the default numbering not working:

http://mpc-hc.wiki.sourceforge.net/How+to+compile+the+MPC

73ChargerFan

11th July 2009, 17:25

Color controls will never work in any non-overlay compatible renderer, this is not a bug.

Shader to change brightness:
# Brighten2
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return(tex2D( s0, tex ) +2);
}

ar-jar

11th July 2009, 21:59

I think the build guide is now correct apart from the code embeds not working and the default numbering not working:

http://mpc-hc.wiki.sourceforge.net/How+to+compile+the+MPC

Good stuff! Looks about right and yasm is there too. Does it compile and link without warnings? My set-up doesn't. If there are warnings to be expected, maybe they should go into the wiki too. -A

kieranrk

11th July 2009, 22:17

There are loads of warnings unfortunately.

alexins

12th July 2009, 01:11

Media Player Classic HomeCinema (x86/x64), svn 1168 (http://www.xvidvideo.ru/content/view/824/1/)

Supported languages: BY, CN, CZ, DE, EN, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

Updated FFmpeg

GrofLuigi

12th July 2009, 04:11

I regularly install MPC-HC on friends' computers (yeah, I'm spreading the word :)) with various windows OSs, graphic cards & drivers. More often then not, I have to change renderers to find one that works without artefacts. The situation is worst with the integrated cards. I cannot pinpoint one (or two, pre- and post-vista) renderers that are guaranteed to work. I'm not even looking for tearing. :p

Maybe it's fixable (I suspect they don't accept some colorspaces), but investigation would take months. So I'd say every renderer is potentially useful. Why limit our choices? If they want, developers can concentrate on some of them and leave others "unsupported".

Just my .02.

GL