Log in

View Full Version : Media Player Classic Home Cinema (MPC-HC) - DXVA!


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 [324] 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410

Dstruct
9th February 2011, 10:14
The best I could do, is loading some vertex data to fake 3D rendering and try to get full 3D clock speeds (with very loud fans as a consequence :p).

Yeah, something like this. Same way games do it. Of course this should be optional only.

JanWillem32
9th February 2011, 10:19
@Stephen R. Savage: http://sourceforge.net/apps/trac/mpc-hc/changeset/2827 The build 2827 is one month old, and was released as "stable", because it was long overdue. I didn't contribute to it. All of the work I've done, is exclusive to nightly builds.

@Hera: Unfortunately, I'd wish that clock speeds would be adapted to the actual load. Unfortunately, it can only be set to 2D load or 3D load settings with a trick.
The 10-bit output option requires locking an entire screen to exclusive mode, as the Windows desktop won't allow it. The only thing available for windowed mode is a 10-bit backbuffer, to use the video card's color LUT on.
The ION probably has problems with setting a 10-bit backbuffer. I'll try to add a detection option to see if I can disable enforcing a 10-bit backbuffer in that case.
The stuttering is probably the worst with animated subtitles on 1080i/(30000/1001) video. I can only think of the 100% load limit for the ION that would cause stuttering and frame drops.
Explain the quality thing please. With the "optimal" settings preset, without dithering and other post-processing, the picture should come out like the "base" pictures I posted.

@thuan: That's too bad. I still wonder why users with similar systems reported that unaltered chroma came out of the mixer, but it doesn't work in your case. From a developer point of view, it's annoying that it's forced with your system for some reason, and can't be enabled on most other systems. There's no way that the program can directly detect this, either. Please hold on to your system for some time, I'd really like to find a complete solution, instead of advising all users to buy new hardware. It might very well be that a new mixer is required to get this problem solved.

@pdanpdan: Microsoft should make it possible to disable Aero on only the active screen. I can allow Aero to stay enabled when not forcing 10-bit output (or an experimental function I'd still like to add), but then it would be nearly the same as the fullscreen windowless rendering mode, anyway.

@Dstruct I can add it as an optional item, once I fixed the vertex processing (it's done in software at the moment). Right now, it's a bit too risky.

god_md5
9th February 2011, 11:43
reported bug
over the ffdshow 2882 can show idx subtitle(inside ts) .
hdtv is ok .
but my area sdtv is not have video outout
other software can't spilte the subtitle,only hpc-hc can spilter ,but not video out ,like is the hpc-hc spilter bug?
can you help to fix this ,thank you

sample ts
http://www.mediafire.com/?b5wcwcf4klljewk
Sourceforge and doom9 have Attack??
sorry my eng,photo , i mean mpc-hc spilter is not video,but have subtilte
please test the sample ts.ver is 1.5.1.2917
http://img17.imageshack.us/img17/9711/screenhunter02feb091840.jpg

JanWillem32
9th February 2011, 12:01
That's the black screen bug. Try one of my nightly builds, I've solved most of the causes of it. http://forum.doom9.org/showthread.php?p=1476526#post1476526
It will take some time before the fixes are integrated into the source code. We need to solve other mixer problems first.

cca
9th February 2011, 14:06
@JanWillem32: are your sure that graphics card clocks are not dynamic? In my ATI 4850, if I leave the Catalyst Control Center in the Overdrive display which displays the clocks and open a (non-DXVA) video, I can clearly see the clocks changing to higher speed, even going to max speed at many occasions. Of course I can only speak for my hardware.

Stephen R. Savage
9th February 2011, 14:40
@Stephen R. Savage: http://sourceforge.net/apps/trac/mpc-hc/changeset/2827 The build 2827 is one month old, and was released as "stable", because it was long overdue. I didn't contribute to it. All of the work I've done, is exclusive to nightly builds.

Please take the time to read what I write. If you notice, the build in the screenshot is revision 2917, one of your (http://www.mediafire.com/?er833bzfj200p5m) builds (even though nothing has changed relative to even v1.3...)

Quite honestly, I had no problems with the way MPC-HC was performing before, and am therefore extremely concerned with these future "improvements" that appear to accomplish nothing at all.

thuan
9th February 2011, 14:44
@Jan: I want to make another shot. Can you post the registry dump (without personal info like file open history) of a working MPC-HC config for me to try? I might have set up something wrong, albeit I have tried set it up from scratch once by deleting the old settings in registry, it still didn't work.

JanWillem32
9th February 2011, 16:52
@cca: Overdrive isn't enabled by default. If it helps to fine-tune things, it's a good way to achieve a good power balance. I usually overclock manually, so I'll have to try this first. Can nVidia, Intel, IGP and mobile GPU users report something similar to enable to get a bit more performance in 2D mode?

@Stephen R. Savage: I'm sorry about the version thing, I looked at the wrong item. It's odd that you get YUY2 with all types of inputs. It has a lower merit than NV12, YV12 and I420/IYUV (+ some rare other formats). I assume the same thing happens with internal codecs?
You might not realize it, but if the file format is a Y'CbCr-4:2:0-type and the mixer format isn't, you do have a lossy conversion problem before even mixing. It's hard to guess where that conversion happens. Can you post MediaInfo logs, the filter information from the filters menu, system information, or anything else that could help solve this problem? I haven't seen refusal of NV12 by the mixer before, and I do intend to solve it.

@thuan: Most certainly, these are my own settings (slimmed down a bit). Don't forget to back-up the main registry key before applying the REG file, as it will delete the all current settings.
It's a long shot, but it might help to get the mixer to leave internal chroma unchanged.

My pictures have been viewed quite a few times now. What do people think about the chroma up-sampling? Those who can't see it: zoom in with point sampling/nearest neighbor and look at the color contrasts. There are only differences in chroma quality between the spline4 and spline5 up-sampling in very detailed areas.

clsid
9th February 2011, 17:20
A tip that might help for better debugging/testing:
Use TRACE at strategic points in the code. Instruct users to download DebugView to log the output.

http://technet.microsoft.com/en-us/sysinternals/bb896647

thuan
9th February 2011, 17:54
@Jan: I tried your settings and right off starting playback I have this:
http://thumbnails15.imagebam.com/11883/0fced0118824650.jpg (http://www.imagebam.com/image/0fced0118824650)
My system seems not to like D3D exclusive mode, clicking OK on the error the movie starts but its color is convert to TV range which is wrong as I'm using a LCD monitor. This has been going for a while, but as I don't use it I didn't report the issue. Set aside this issue, my GFX card chroma upsampler still kicks in after that. And when I go and disable D3D exclusive mode still the same thing happens. If you want me to do more test, please do tell.

cca
9th February 2011, 19:52
@JanWillem32: I don't actually use overdrive, I have the checkbox unchecked. I just go the overdrive tab of the ATI Catalysts and there I can see the GPU clocks. Similar effect can be observed with 3rd party utilities, like GPU Z for example. I first noticed this behaviour over a year ago, so it is nothing new from a driver version point.

I do not know what happens on other manufacturers' cards though, this is only for AMD cards (R.I.P. ATI logo!).

JanWillem32
9th February 2011, 21:24
@clsid: Thanks, I'll explore this tool. Right now it seems to just detect MPC-HC starting up the detours library. Maybe after changing a few settings I'll find something interesting. There's already trace EVR, so I'll test that for another build.

@thuan: That as well? Can your computer even start games or other programs that use the exclusive mode? Can you see if VMR-9 (renderless) does the same thing with the exclusive mode? While you're at it, does VMR-9 (renderless) blur the chroma in the same way as EVR-CP?
I wonder what renderer will use limited ranges. As far as I know, none of the renderers does that by default. I'll take a look at it.

@cca: With my video card (HD 4890), I can only see it switch to idle mode (240 MHz), 2D load mode (500 MHz, too low for my usage) and 3D load mode (850 MHz). I haven't seen any dynamic changes outside of those modes, even on constant 100% GPU usage on 2D load mode, it won't go to the 3D load mode. Did you find any trick to enable more dynamic changes?

mariush
9th February 2011, 21:45
Is there any reason why the latest MPC-HC (1.5.0.2827,from the website) would freeze when trying to play AVS files?

I had 1.3.1249.0 , moved the folder and got the zip file from the site and renamed the executable to mplayerc.exe - every video plays just fine with the previous configuration (evr custom presenter, haali splitter, coreavc, ac3filter on win2k3 32bit, radeon 4850), except avs scripts - mpc-hc freezes and keeps two cpu cores busy...

http://savedonthe.net/image/857/mpchcavsfreeze.png

HoP
9th February 2011, 22:55
@JanWillem32:
please put your latest builds(MPC & Shaders)in your sig...thanks in advance

Ger
9th February 2011, 23:39
@Ger: The internal MPEG-2 decoder is old. I don't know much about it, but it could very well be that it just doesn't have any routines for 4:2:2 chroma sub-sampled data. I use the default Microsoft decoder, as it seems to be able to use at least IDCT DXVA mode in my situation. My video card can't do the full VLD DXVA decoding mode for MPEG2. I don't know if that decoder can do 4:2:2 structures, either.
AFAIR, Microsoft (Win7), Arcsoft, Cyberlink and MPC-HC MPEG-2 decoders all fail with 4:2:2 sources.

Mainconcept/Elecard, Dscaler and ffdshow, in addition to VLC etc. should work, but there are probably others out there as well.

Since you seem to have a good understanding of this chroma stuff, maybe you'd be willing to look into adding 4:2:2 support to the internal MPEG-2 decoder?

Anyway, if anyone is interested, here is a MPEG-2 4:2:2 sample (http://www.multiupload.com/X9JQLLLCNW).

I removed the convertor to YUY2, and gave NV12 a higher merit than YV12 and I420/IYUV. If it's preferred, I can set different merits for interlaced and non-interlaced content in future builds.
I think that would be a good idea, to be able to take advantage of the best hardware deinterlacing methods.

cca
10th February 2011, 00:09
@JanWillem32:

My 4850 only has 2 modes, one 2D (idle) and one 3D (max clock). The 3D mode clockspeeds are also used for DXVA. Now, when I play a video in MPC-HC I notice the clock sometimes is in 2D and sometimes in 3D, changing every few seconds sometimes. I did nothing at all for this to happen.

Also, a few weeks ago I modded my card's BIOS to lower the idle speeds. This had an unexpected effect. Now the card seems to use 3 clock speeds! Only very low, one intermediate (the original idle clock speed) and one maximum. When playing videos it switches between the intermediate and the max dynamically.

Note that the original behavior I describe in the 1st paragraph was happening even before I touched the VGA Bios, so my mod has nothing to do with it in reality.

tetsuo55
10th February 2011, 00:59
Is there any reason why the latest MPC-HC (1.5.0.2827,from the website) would freeze when trying to play AVS files?

I had 1.3.1249.0 , moved the folder and got the zip file from the site and renamed the executable to mplayerc.exe - every video plays just fine with the previous configuration (evr custom presenter, haali splitter, coreavc, ac3filter on win2k3 32bit, radeon 4850), except avs scripts - mpc-hc freezes and keeps two cpu cores busy...
]thats a security leak in avisynth, you need to put all the dll files next the avisynth exe afaik.


@everyone testing Janwillems builds, this forum thing doesn't seem to be working well for debugging and fixing the problems you are reporting, could you guys come on irc? http://webchat.freenode.net/?channels=mpc-hc
Chatting there would go a lot faster.

alexins
10th February 2011, 02:41
Media Player Classic HomeCinema (x86/x64), 1.5.1.2920 (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-1-2920.html)

Changes (2911-2920):

cosmetics in the batch files;
Enhanced the precision of the CIE D65 white point for the color management calculations. Patch by janwillem32;
clean up ffmpeg makefile;
update libpng to v1.5.1;
Fix : truncate OSD at file open;
merge makefile_c.inc with makefile;
resized "Playback" dialog box (no clipping in most translations).;
recalculated size of the sliders "Volume" and "Balance". more precise control with the keys.;
updated russian translation;
update lcms to the latest git.

mariush
10th February 2011, 02:43
thats a security leak in avisynth, you need to put all the dll files next the avisynth exe afaik.


I'm sorry tetsuo55, I don't understand what you're saying. If I start the old version of the player and drag an avs file on it, it plays just fine. Trying the same on the new version fails. Can you please explain it again?

I also found some other issue with this new version. I have a MKV file with 2 ac3 tracks and both play at the same time with Matroska selected in Source Filters. Play > Audio is grayed out.

After I unchecked Matroska in Source filters and restarted the player, Haali renderer was used and took care of the file and I can select again from the Haali properties which audio to play.

GTPVHD
10th February 2011, 03:25
H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine on 2910 and there's no changes that I can think of between 2910 and 2920 that could have cause this.

http://img232.imageshack.us/img232/7917/2920broken.png

http://img710.imageshack.us/img710/6382/2910ok.png

This could be a GCC 4.5.3 compiler bug, 2910 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169526, 2011.02.02) x86_32) while 2920 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169972, 2011.02.09) x86_32).

thuan
10th February 2011, 04:02
@Jan: My replies are in bold.

@thuan: That as well?
Yes, when I have D3D exclusive mode enabled in conjunction with 10-bit output, if I disable either of them it works normally.
Can your computer even start games or other programs that use the exclusive mode?
Yes, finished Dead Space 2 recently. I got a SSD recently and reinstalled Windows then, but this error has been there before the reinstall and as I can play games fine before and I always leave my GFX card settings at default. It might be a problem with my configuration.
Can you see if VMR-9 (renderless) does the same thing with the exclusive mode?
Yes, it has the same behavior.
While you're at it, does VMR-9 (renderless) blur the chroma in the same way as EVR-CP?
Yes, it always kicks in.

I wonder what renderer will use limited ranges. As far as I know, none of the renderers does that by default. I'll take a look at it.

alexins
10th February 2011, 04:20
H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine on 2910 and there's no changes that I can think of between 2910 and 2920 that could have cause this.

http://img232.imageshack.us/img232/7917/2920broken.png

http://img710.imageshack.us/img710/6382/2910ok.png

This could be a GCC 4.5.3 compiler bug, 2910 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169526, 2011.02.02) x86_32) while 2920 was compiled with Cross-Mingw with GCC 4.5.3 (Pre-Release, svn rev. 169972, 2011.02.09) x86_32).
The problem was introduced in Rev. 2916:
OPTFLAGS += -O2 -march=pentium4 -msse -mfpmath=sse
Dear developers, be careful with keys optimization, particularly with key -march !!!

But remember, by using these flags, binaries from your system might not work on another one with a different CPU. So if you compiled with optimizations for a Pentium 4 (-march=pentium4), you can't share a hard disk or packages with a friend who only has a Pentium MMX (-march=pentium-mmx). Though the other way around should work, see below.
This is the case if you are using the -march flags. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages. There is one exception though; if your old CPU supports a feature, like AMD's 3dnow, that your new CPU doesn't. So if you have an athlon (-march=athlon) and upgrade to a pentium4 your old packages might not work. You can mix -march and -mtune if you, for example, would like to create binaries that would run on any i686 but are optimized for a pentium4. This would be accomplished by using -march=i686 and -mtune=pentium4.

3.17.15 Intel 386 and AMD x86-64 Options (http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options)

P.S.
The -mfpmath = sse, doesn't always work correctly, sometimes it leads to problems!!!

skingery
10th February 2011, 05:26
Hi Everyone, been watching for a while. Still trying to get a handle on all the technical details. Feeling pretty much like a noob so bear with me.

The first thing I want to understand is the resizer drop down under Playback - Output using EVR CP. Is it correct these are different methods of resizing? And that quality is best at Bicubic A=-1.00? And that nearest neighbor would be the least taxing on GPU and Bicubic A=-1 would be the most taxing? So, depending on your hardware would want to experiment with what it will handle the smoothest?

Thanks in advance for your help!
Scott

Hera
10th February 2011, 06:02
@JanW - Thuan provided a screenshot of the exact issue I am experiencing with your builds. Older versions work just fine. Fullscreen games like FO3 or Portal work fine. By reduced quality, I just meant just that which others reported it seems.
@tetsuo55 - If I see JanW there, I will.

god_md5
10th February 2011, 06:23
That's the black screen bug. Try one of my nightly builds, I've solved most of the causes of it. http://forum.doom9.org/showthread.php?p=1476526#post1476526
It will take some time before the fixes are integrated into the source code. We need to solve other mixer problems first.
my test ver is 2917 form xhmikosr (black screen bug)
you compile ver have other bug(JanWillem32 in post the comilpe x86 ver 2917)
xhmikosr and xvidvideo ver 2917 is ok
i use win7 x64,and ati xt2600 ,driver 11.1,cpu is q9400
http://img843.imageshack.us/img843/3402/screenhunter02feb101314.jpg

Aleksoid1978
10th February 2011, 07:04
The problem was introduced in Rev. 2916:
OPTFLAGS += -O2 -march=pentium4 -msse -mfpmath=sse
Dear developers, be careful with keys optimization, particularly with key -march !!!

But remember, by using these flags, binaries from your system might not work on another one with a different CPU. So if you compiled with optimizations for a Pentium 4 (-march=pentium4), you can't share a hard disk or packages with a friend who only has a Pentium MMX (-march=pentium-mmx). Though the other way around should work, see below.
This is the case if you are using the -march flags. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages. There is one exception though; if your old CPU supports a feature, like AMD's 3dnow, that your new CPU doesn't. So if you have an athlon (-march=athlon) and upgrade to a pentium4 your old packages might not work. You can mix -march and -mtune if you, for example, would like to create binaries that would run on any i686 but are optimized for a pentium4. This would be accomplished by using -march=i686 and -mtune=pentium4.

3.17.15 Intel 386 and AMD x86-64 Options (http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options)

P.S.
The -mfpmath = sse, doesn't always work correctly, sometimes it leads to problems!!!

Hi. what flag do you use for your build ???

tetsuo55
10th February 2011, 07:40
I'm sorry tetsuo55, I don't understand what you're saying. If I start the old version of the player and drag an avs file on it, it plays just fine. Trying the same on the new version fails. Can you please explain it again? a while ago we commited some security fixes for exploits. One of the exploits has to do with dll's loaded from a non standard directory. Many people have avisynth dll's and avsi files spread accross the computer. so you need to have all your files next to avisynth.exe (except for the .avs)

I also found some other issue with this new version. I have a MKV file with 2 ac3 tracks and both play at the same time with Matroska selected in Source Filters. Play > Audio is grayed out.

After I unchecked Matroska in Source filters and restarted the player, Haali renderer was used and took care of the file and I can select again from the Haali properties which audio to play.Sounds like the audio splitter is disabled, i suggest resettings you settings, click on the word "bugs" in my signature for instructions.

H.264 software decoder is broken in 1.5.1.2920 build on Athlon XP, works fine on Core 2 CPU. Which is weird since it works fine Minimum CPU requirement for official builds is a Pentium4 or Athlon64.
You can use what alexins said to create a custom build that does on athlonXP
@tetsuo55 - If I see JanW there, I will.He's there most of the time
my test ver is 2917 form xhmikosr
you compile ver have other bug
xhmikosr and xvidvideo ver is ok
i use win x64,you ver 2917 x86,and ati xt2600 ,driver 11.1
can you explain in a bit more detail which version causes what behaviour? for example from which build is that screenshot?

See "bugs" in my signature for more info.

GTPVHD
10th February 2011, 10:17
Tetsuo, I don't compile MPC-HC, I use alexins' builds for testing and this is short sighted. A lot of people still use MPC-HC 1.x, you shouldn't bump the requirements to SSE2 CPUs for very minimal gains. If you do that for the next major version like 2.0/3.0/whatever I can understand but 1.x should always be compatible with SSE CPUs.

Dstruct
10th February 2011, 10:32
Media Player Classic HomeCinema (x86/x64), 1.5.1.2920 (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-1-5-1-2920.html)

Changes (2911-2920):

Enhanced the precision of the CIE D65 white point for the color management calculations. Patch by janwillem32;
update lcms to the latest git.


Cool. But Color Management isn't working anymore at all with this build. It gets grayed out on playback start and isn't becoming active (seen in Playback Stats). Same with (Half) Floating Point Processing option(s).

Was fixed by JanWillem32 here: http://forum.doom9.org/showthread.php?p=1473873#post1473873

tetsuo55
10th February 2011, 12:04
Tetsuo, I don't compile MPC-HC, I use alexins' builds for testing and this is short sighted. A lot of people still use MPC-HC 1.x, you shouldn't bump the requirements to SSE2 CPUs for very minimal gains. If you do that for the next major version like 2.0/3.0/whatever I can understand but 1.x should always be compatible with SSE CPUs.We removed SSE support a long time ago, its just only recently become noticable. higher performance is only one of many reasons.

I do see your point and i suggest the following:
The community works together to help make a wiki page that explains how to compile for legacy systems. that way some of the nightly builds can still be used on older hardware and os's.

I am aware of 3 required changes.
1. Remove forced SSE2 settings
2. Remove forced DEP settings
3. Comment out DVD related code that makes mpc-hc crash on win2k

We will not support builds created through this page!

betaking
10th February 2011, 12:45
We removed SSE support a long time ago, its just only recently become noticable. higher performance is only one of many reasons.

I do see your point and i suggest the following:
The community works together to help make a wiki page that explains how to compile for legacy systems. that way some of the nightly builds can still be used on older hardware and os's.

I am aware of 3 required changes.
1. Remove forced SSE2 settings
2. Remove forced DEP settings
3. Comment out DVD related code that makes mpc-hc crash on win2k

We will not support builds created through this page!

2. Remove forced DEP settings
+1! A lot of people don not like dep!

GTPVHD
10th February 2011, 12:49
I don't care about DEP changes, DEP should always be on for security reasons or the Win2k changes since MPC-HC hasn't been supported or worked on Win2k since 1.4.2499.0, but making MPC-HC 1.x incompatible with SSE CPUs just by using -march=pentium4 compiler option is really short sighted decision. You're just gonna alienate a lot of users. Also most people just pull down the code and compile it, they're not gonna change anything so your wiki guide page idea is unrealistic.

But since the MPC-HC team has decided to give up all those users to VLC, I'm not gonna comment anymore on this matter.

tetsuo55
10th February 2011, 12:49
But they do love virusses and trojans! haha:p

tetsuo55
10th February 2011, 12:54
I don't care about DEP changes, DEP should always be on for security reasons or the Win2k changes since MPC-HC hasn't been supported or worked on Win2k since 1.4.2499.0, but making MPC-HC 1.x incompatible with SSE CPUs just by using -march=pentium4 compiler option is really short sighted decision. You're just gonna alienate a lot of users. Also most people just pull down the code and compile it, they're not gonna change anything so your guide page idea is unrealistic.The SSE2 decision is based on many factors, the most important ones are that msvc2010 cannot compile for SSE1, SSE2 offers a considerable improvement in performance and we don't support hardware older than 5 years.
But anyone is free to join the team and be the legacy developer person! maybe we can decide on hosting an official x86 sse legacy build, as long as the main team members are not the one releasing it.

GTPVHD
10th February 2011, 12:57
MSVC2010 SP1 compiles SSE just fine, alexins' 2910/2920 builds all use SSE if you see the About screen. The compiler bug with MSVC2010 has been fixed in SP1, just so you know. That's my last comment on this.

betaking
10th February 2011, 12:59
But they do love virusses and trojans! haha:p

I think you mentioned that the DEP settings to remove just remove the MPC-HC in the relevant code, rather than a complete shutdown of the operating system in the DEP! This did not have any impact on the safety! And I found a problem. In XPSP2 OR XPSP3 both operating systems use the code open the DEP of the MPC-HC. (The two systems are enabled by default DEP's) does not appear random CRASH. On the contrary if it is in VISTA or WIN7 two operating systems, but will appear randomly CRASH! In addition, I have a suggestion if it is SVN daily updates DEP code without removing the relevant code. But if it is officially released version of the relevant code can be removed DEP!
PS: DEP does not provide much of the help system security. Anti-virus software and network firewalls is you need most!
:)

Dstruct
10th February 2011, 13:07
DEP should stay enabled. Users that don't want it still can disable it.



This way is the one to avoid:

Having DEP forced on on the system but the application not being DEP aware.

tetsuo55
10th February 2011, 13:09
Indeed if people have problems with DEP it will be because they have one or more DEP incompatible applications.
The crashes betaking mentiones are caused by non-DEP aware filters and/or dll's.

I'm not 100% sure but i think reclock is an often crasher that is not DEP aware.

@GTPVHD I've asked the team to think about the SSE vs SSE2

GTPVHD
10th February 2011, 13:16
Tetsuo, your legacy SSE build idea is an acceptable compromise. Also, you should communicate changes like this months in advance instead of letting people know only after release.

tetsuo55
10th February 2011, 13:36
We changed the support level almost a year ago, i didn't even know we still had SSE users :P

nevcairiel
10th February 2011, 14:00
There hasn't been a new CPU for nearly 8 years (P4 in 2001, Athlon64 in 2003) now that did not support SSE2. At some point, you should realize that your way outdated hardware won't be able to run the up-to-date software anymore. Your system is probably not fast enough to take advantage of the new enhancements anyway, so could as well stick with the last SSE release, imho.

How about we disable SSE as well, so you can run stuff on your Pentium2?
You have to draw the line somewhere. And 8 years is a long time in the PC industry, so imho requiring SSE2 is totally acceptable.

Same with OS support. Anything below XP SP3 is not officially supported anymore, as even MS gave up on those.

GTPVHD
10th February 2011, 14:09
Look, I have Core 2 machines, no need to attack me just because I tested the latest builds on an old Athlon XP which worked fine until 2916 changes.

Also Pentium 4 was released in 2000, 11 years ago and Athlon 64 was released in 2003, 8 years ago. Since you all don't support hardware older than 5 years old, aka stuff released in 2006 which would be Core 2 minimum, with your logic why not disable support for Pentium 4 and Athlon 64/X2 CPUs then?

nevcairiel
10th February 2011, 14:17
Attack? Right.

5 years is just a guideline, as you yourself said, its 8 years right now.
In any case, SSE3 does not offer a significant upgrade like SSE2 does.
The decoders are already able to use SSE3, as they have runtime checks and use custom written assembly.
Just the parts that are not hand optimized get optimized by the compiler, and that is told to use SSE2 if possible.

GTPVHD
10th February 2011, 14:20
The SSE2 decision is based on many factors, the most important ones are that msvc2010 cannot compile for SSE1, SSE2 offers a considerable improvement in performance and we don't support hardware older than 5 years.

I know tetsuo didn't really mean this but anyway. :p

Lets just drop this, it's not really important anyway.

clsid
10th February 2011, 14:42
There is very little C/C++ code in MPC that can benefit from forcing SSE(2) in the compiler. Most CPU an data intensive code already uses hand-written assembly code.

We have tested it several times in ffdshow and came to the conclusion that for general decoding forcing SSE(2) has no real benefits at all. It only helped for a select few data intensive processing algorithms, none of which are used by MPC. An example of the few filters was Deband, which is now even implemented using runtime cpu dectection, making it even less useful to force SSE in ffdshow.

I suggest adding a simple benchmark option to MPC:
mpc-hc.exe /benchmark some_test_file.mkv

This should do something like this:
1) open MPC
2) open file
3) start timer
4) play file
5) close file at end of playback
6) stop timer
7) write duration to STDOUT
8) close MPC

Perhaps even a /benchmark=X to play the file X times and output the duration X times. So repeating steps 3-7.

bobdynlan
10th February 2011, 16:39
I suggest adding a simple benchmark option to MPC:
mpc-hc.exe /benchmark some_test_file.mkv

This should do something like this:
1) open MPC
2) open file
3) start timer
4) play file
5) close file at end of playback
6) stop timer
7) write duration to STDOUT
8) close MPC

Perhaps even a /benchmark=X to play the file X times and output the duration X times. So repeating steps 3-7.
Download Batch Launcher - a cmd script (http://cid-d561cc7d122f3f32.skydrive.live.com/redir.aspx?resid=D561CC7D122F3F32!115)
1. copy bl.cmd to SendTo folder (%AppData%\Microsoft\Windows\SendTo in W7 or %USERPROFILE%\SendTo in XP)
2. right click the first mpc-hc.exe to test, and choose bl.cmd from the SentTo menu.
3. at the parameters prompt, add something like this:
C:\XFILES\SHARED\t3.vob /play /close
4. wait for the playback to finish - you should choose a short file like 30 seconds for benchmarking (can measure up to 24h).
5. check out the summary in the cmd window
6. repeat from step 2 with another mpc-hc.exe build. At 3, just press enter to use the saved parameters.

Sample output (file) from this batch file:
mpc-hc.exe C:\XFILES\SHARED\t3.vob /play /close RunAs:N
Started 17:29:47.13 Thu 02/10/2011
-------------------------------------------------


-------------------------------------------------
Finished in 0:00:25.87 ~ 25.87 seconds


Another usage would be to launch a file to a specific position and pause, for consistent screenshots
C:\XFILES\SHARED\t3.vob /open /start 182000

nevcairiel
10th February 2011, 16:48
The time required to play a file is really irrelevant. Those optimizations don't usually affect the GUI, they affect the processing of the media. And in the player, its always the same speed. You just might have lower CPU usage.

bobdynlan
10th February 2011, 17:40
The time required to play a file is really irrelevant. Those optimizations don't usually affect the GUI, they affect the processing of the media. And in the player, its always the same speed. You just might have lower CPU usage. Not true. The total time of playing a 30 second file will be 30 seconds + some overhead of less than a second. But if you use another decoder/splitter/option this might change drastically - stuff like stutters and frame drops also come into play. How about that Crowd run file :)

Hera
10th February 2011, 19:18
I use Athlon XP 3000+ for 360p - 720p content. XP SP3, NV 6600.

Sina™
10th February 2011, 19:21
when i add external filters (cyberlink) restart mpc, mpc doesn't save them. (drm?)
v1.5