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

tetsuo55
30th August 2009, 16:11
I'm doing that now.

Is it possible the Beliyaal made the same assumption that one is using analog audio output from the HT-PC rather than SPDIF ? This might explain why some people like Casshern had their sync problems solved by Beliyaal, while other people like me (and other people in the thread) only have sync problems after Beliyaal changed the code...The results are the same for me with or without SPDIF

No has nothing to do with it! Beliyaal's code does not affect audio. It just implements a better vblank handler. I use reclock for audio-sync. Ar-Jay code is promising but still has some drawbacks for me:
1) syncing the monitor refresh through powestrip gives glitches on my sony vwl 60
2) syncing through audio clock, does not work for spdif - audio and video desyncs
3) his new sync code gives a repeated frame or dropped frame in regular intervals. SPDIF works (naturally as video is adjusted to audio). One can lenghten this interval by using accurate powerstrip timings. But it will strike once in a while.

With Reclock, Powerstrip and beliyaals code everything works perfectly smoothly.1)Do you see visible glitches?
2) Spdif cannot be audio clock synced by design
3) repeated or dropped frames occur with all MPC renderers, gothsync's new graphs actually show these errors (the old stats do not consider dropped/repeated frames of this type like errors),also the code has been written to minimise the number of errors.

Ger
30th August 2009, 22:06
A suggestion: I don't think I would be the only regular changelog reader who would find it helpful if the commits to the gothsync branch (ie. rev 1263, 1260 etc.) were prefixed with a static text string like "gothsync branch:" in the changelog (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log).

The reason for this is to easily be able to distinguish the trunk changes from the other branches in the SF changelog without clicking to see which files have been changed.

Everything that doesn't go into the trunk could get a branch prefix, so that for rev. 1255 it would say something like:
gothsync branch:
Some small optimizations in the EVR code.

In other words, I suggest doing it the same way haruhiko and the other ffdshow devs do it (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log) (there is an example of this if you scroll down to rev. 2810).

Thanks.

Leak
30th August 2009, 22:22
A suggestion: I don't think I would be the only regular changelog reader who would find it helpful if the commits to the gothsync branch (ie. rev 1263, 1260 etc.) were prefixed with a static text string like "gothsync branch:" in the changelog (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log).
How about looking at the changelogs for trunk (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/?view=log) and the gothsync branch (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/branches/gothsync/?view=log) instead?

It's not as if subversion wouldn't allow you to distinguish those...

np: Das Bierbeben - Der König (Das Bierbeben)

Ger
30th August 2009, 22:40
That would be much easier, yes. Didn't know that was an option. :)

wayland
31st August 2009, 00:38
anyone working on UI updates? on another forum a topic was created about v1.3.1249 and the only real complaint i saw was that the interface is poor which i gotta agree with, not saying add loads of useless bling but its called mpc-hc so why not improve the ui and add features you would find in a media centre app like xbmc?

GTPVHD
31st August 2009, 00:56
No, MPC-HC was designed to be minimalist and retain the original Gabest MPC look and remain lightning fast.

I know which forum, it's the Neowin forums thread. If you are Waylander on the Neowin forums, you're posting misinformation on the Neowin thread. CoreAVC CUDA has less compatability than DXVA, it's limited to 15 reference frames while Nvidia DXVA can decode all the way up to 16 reference frames files. Please don't post misinformation, it will hurt more than posting the real info that people need.

DXVA is not crap as you insinuate on the Neowin thread, try decoding a L5.1 16 reference frame file and see if you can get any hardware acceleration from CoreAVC CUDA.

ADude
31st August 2009, 01:19
anyone working on UI updates? on another forum a topic was created about v1.3.1249 and the only real complaint i saw was that the interface is poor which i gotta agree with, not saying add loads of useless bling but its called mpc-hc so why not improve the ui and add features you would find in a media centre app like xbmc?

There is also a bug introduced since 1043, where "Fullscreen" and "Fullscreen w/o res change" both toggle to a tiny window too small to be useful.

This seems possibly to have been introduced at the same time as the Keys were changed for those, but perhaps not.

In 1043 and before, both of those toggled between Fullscreen and 1:1 display according to the resolution.

88keyz
31st August 2009, 01:46
Is anybody else having issues with SPDIF output using build 1245 or newer? When I upgrade to any build from 1245 on I am no longer getting audio from my SPDIF connection to my audio receiver. When I downgrade back to build 1179 it works perfect. Tested with multiple video files with both AC3 and DTS audio and its the same thing. I have set the audio output device to SPDIF and have set the DTS and AC3 internal decoder to output via SPDIF. Any version 1179 or lower seems to work fine and anything newer has this new issue. The SPDIF output in question is from the IDT onboard audio of an Intel DG965WH mobo which is running the latest drivers from the Intel site. Nothing changes in system settings and nothing changes in MPC-HC settings just the build number. Lastly, I am running the x86 build on Vista 32-bit. :confused:

khagaroth
31st August 2009, 08:17
There is also a bug introduced since 1043, where "Fullscreen" and "Fullscreen w/o res change" both toggle to a tiny window too small to be useful.

This seems possibly to have been introduced at the same time as the Keys were changed for those, but perhaps not.

In 1043 and before, both of those toggled between Fullscreen and 1:1 display according to the resolution.

Works for me still the same as it always did, check your settings.

peek
31st August 2009, 09:41
I can confirm this behaviour for the recent MPC-HC versions on XP 32 as reported by ADude. It came up at the same time when the "Launch files in fullscreen" mode was broken once (in 1222 or 1223), but although that has already been fixed for a while, the "tiny window" which appears after closing fullscreen mode still exists.

wayland
31st August 2009, 13:39
No, MPC-HC was designed to be minimalist and retain the original Gabest MPC look and remain lightning fast.

I know which forum, it's the Neowin forums thread. If you are Waylander on the Neowin forums, you're posting misinformation on the Neowin thread. CoreAVC CUDA has less compatability than DXVA, it's limited to 15 reference frames while Nvidia DXVA can decode all the way up to 16 reference frames files. Please don't post misinformation, it will hurt more than posting the real info that people need.

DXVA is not crap as you insinuate on the Neowin thread, try decoding a L5.1 16 reference frame file and see if you can get any hardware acceleration from CoreAVC CUDA.

thats me and i didnt know that about dxva on nvidia (i dont use any form of dxva/cuda as i have a quad core) and the nvidia dxva being able to decode 16 ref frames has been added to and removed from svn multiple times thats really reliable. main issue imo is you cant use intermediate filters, im sure reclock counts as one and is very useful to a lot of people, tbh i dont see the point of things like ffdshow (video filters) if playing hd video but im sure there are people out there who like to use all sort of shitty filters which they cant with dxva

GTPVHD
31st August 2009, 13:46
Which would you prefer, smooth HD playback with DXVA, or mostly slideshow but you can use all those various filters you mentioned at Neowin unless you have a 3GHz dual core or a quad-core of lower speed? Think about it.

The Nvidia L5.1 16 reference frame playback is reliable enough, no one here has complained much about it. Again, choose between smooth playback or slideshow with all your filters.

As for Haali Media Splitter, I like to refer you to this.

http://lists.matroska.org/pipermail/matroska-devel/2009-August/003533.html

Splitter.ax is crashing around 1500 times per day on Windows 7.

wayland
31st August 2009, 13:59
isnt nvidia L5.1 16 ref frames os specific? link (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=1220) if so come again when 15 or more ref frames work on xp, and as far as filters go i dont think they are a good idea but im sure there are some crazy bastards running warpsharpen on 1080p material.

alexins
31st August 2009, 14:02
Media Player Classic HomeCinema (x86/x64), svn 1265 (http://www.xvidvideo.ru/content/view/840/1/)

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

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

•Fixed : Memory leak in libavcodec;
•Fix : subtitle menu not working in Spanish translation;
•Fix : Compiler Error on multi-bytes OS system. Replace European Character to \xXX style;
•Added : homepage link in the About box;
•Fixed : memory lead in DXVA decoder;
•Change : Russian translate(audio decoder properties).

wayland
31st August 2009, 14:02
the haali bit about my comment about haali spliiter being better? thats a fact until mpc-hc's supports ordered chapters

Mixer73
31st August 2009, 14:06
the haali bit about my comment about haali spliiter being better? thats a fact until mpc-hc's supports ordered chapters

For you perhaps but HMS causes havoc on Media Centre systems. Bugs in it that are older than one of my children! :D

Big cheers and clapclaps to the devs for all the hard work, getting a stable release out and still bashing away at it.

To the whiners: pull your head in. The guys here do this work voluntarily and assign priorities in the way they see as best. I personally couldn't thank them enough. MPC-HC has come on in leaps and bounds in the last few months, and we have 4-5 individuals to thank for the bulk of it.

wayland
31st August 2009, 14:13
No use being better when it's unstable to the point Microsoft gets 1,500 crash logs a day, doesn't support TrueHD etc etc.

a whole 1500 crashes pd from the hundreds of thousands if not millions of installed win7 systems, shocking. and ordered chapters is actually useful while truehd is frankly useless (anyone who cares will compress to flac to save a lot of space)

clsid
31st August 2009, 14:16
Microsoft also receives plenty of crash logs about MPC and its standalone splitters. Can you back up your instability claim about Haali with personal experiences, or are you just parroting numbers?

Haali is supposedly working on a new version, which will address several of the known issues and limitations of his splitter.

DigitalDeviant
31st August 2009, 14:42
while truehd is frankly useless (anyone who cares will compress to flac to save a lot of space)

Um, no. Some of us playback directly from disc so ripping to re-encode audio would be a major waste of time. Even then I'm sure some people have multiple TB worth of space and/or don't store movies permanently and don't really care about file size. Until then MPC's splitters still have some advantage over Haali's.

THX-UltraII
31st August 2009, 14:43
Activate auto-loading of subtitles and name the .srt file like your .mkv file (with different extensions of course).

thanks for your reply. I ll try this tonight. But I wonder if it will work, because I also have Haali Media Splitter installed. In the settings of Haali Splitter I have set subtitle language priority to dut,eng. Did this because this way MPC-HC shows Dutch subtitles when available and when NOT available MPC shows English subtitles (all this is for files which have subtitles baked in).

wayland
31st August 2009, 14:56
Um, no. Some of us playback directly from disc so ripping to re-encode audio would be a major waste of time. Even then I'm sure some people have multiple TB worth of space and/or don't store movies permanently and don't really care about file size. Until then MPC's splitters still have some advantage over Haali's.

eh, you can install haali splitter and still use mpc's m2ts splitter. unless they suddenly started releasing blurays in the mkv container:D

tetsuo55
31st August 2009, 15:17
a whole 1500 crashes pd from the hundreds of thousands if not millions of installed win7 systems, shocking. and ordered chapters is actually useful while truehd is frankly useless (anyone who cares will compress to flac to save a lot of space)

Microsoft also receives plenty of crash logs about MPC and its standalone splitters. Can you back up your instability claim about Haali with personal experiences, or are you just parroting numbers?

Haali is supposedly working on a new version, which will address several of the known issues and limitations of his splitter.There is no point in discussion a measurement system we know nothing about.

What we do know is, 1500 crashes a day is enough for MS to reserve one of its own devs for it and to contact the developers of haali.

We might be seeing the number one crash reason of a top 10, with the next runner up only causing 20 crashes per day, or we might be seeing the botton of a top 10, where the nr 1 causes millions of crashes per day.

Its all guesswork, but we can be sure MS is spending money and time on getting it fixed, which makes it fair to assume they feel this is a big issue.

clsid
31st August 2009, 15:37
MS has a whole team for it.
Hello, my name is Dominick Roselli and I am a developer working in the
Windows Error Reporting team at Microsoft.

I work with developers to help resolve issues with applications crashing in
the Windows ecosystem.

Mplayerc.exe has a high volume of crashes and I wanted to provide you with
some information about the problem.

The most recent version of mplayer experiencing this issue is:
DateTimeStamp
2008-12-10 07:14:31.000

szVersion
6.4.9.1

Here is the callstack and faulting instruction:
eax=03cbf544 ebx=01df54c0 ecx=68924193 edx=6888cffc esi=772f06eb
edi=01df5434
eip=0043144f esp=03cbf528 ebp=00000000 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
mplayerc+0x3144f:
0043144f c74218b0124300 mov dword ptr [edx+18h],offset
mplayerc+0x312b0 (004312b0) ds:0023:6888d014={quartz!VMR9::C
VMRInputPin::Receive (68924193)}

ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be
wrong.
03cbf57c 00666aee mplayerc+0x3144f
03cbf5bc 00666fe0 mplayerc+0x266aee
03cbf6ec 00667725 mplayerc+0x266fe0
03cbf750 00667801 mplayerc+0x267725
03cbf7d0 00667830 mplayerc+0x267801
03cbfa88 00669534 mplayerc+0x267830
03cbfe38 0066a57e mplayerc+0x269534
03cbfe54 0066a598 mplayerc+0x26a57e
03cbff3c 0067ce49 mplayerc+0x26a598
03cbff70 0063d940 mplayerc+0x27ce49
03cbffd4 7791b31a mplayerc+0x23d940
03cbffe0 00000000 ntdll!_RtlUserThreadStart+0x1b

Here are the assembly instructions leading up to the failure:
0:005> ub @eip L29
mplayerc+0x313d6:
004313d6 50 push eax
004313d7 6a08 push 8
004313d9 892d68e07800 mov dword ptr [mplayerc+0x38e068
(0078e068)],ebp
004313df 892d6ce07800 mov dword ptr [mplayerc+0x38e06c
(0078e06c)],ebp
004313e5 892d70e07800 mov dword ptr [mplayerc+0x38e070
(0078e070)],ebp
004313eb 892d74e07800 mov dword ptr [mplayerc+0x38e074
(0078e074)],ebp
004313f1 8b0f mov ecx,dword ptr [edi]
004313f3 6a04 push 4
004313f5 51 push ecx
004313f6 896c2424 mov dword ptr [esp+24h],ebp
004313fa ffd6 call esi
004313fc 392d78e07800 cmp dword ptr [mplayerc+0x38e078
(0078e078)],ebp
00431402 750a jne mplayerc+0x3140e (0043140e)
00431404 8b17 mov edx,dword ptr [edi]
00431406 8b4244 mov eax,dword ptr [edx+44h]
00431409 a378e07800 mov dword ptr [mplayerc+0x38e078
(0078e078)],eax
0043140e 8b0f mov ecx,dword ptr [edi]
00431410 8d542414 lea edx,[esp+14h]
00431414 52 push edx
00431415 6a10 push 10h
00431417 c7414470124300 mov dword ptr [ecx+44h],offset
mplayerc+0x31270 (00431270)
0043141e 8b07 mov eax,dword ptr [edi]
00431420 6a04 push 4
00431422 50 push eax
00431423 ffd6 call esi
00431425 8b13 mov edx,dword ptr [ebx]
00431427 8d4c2414 lea ecx,[esp+14h]
0043142b 51 push ecx
0043142c 6a08 push 8
0043142e 6a04 push 4
00431430 52 push edx
00431431 ffd6 call esi
00431433 392d7ce07800 cmp dword ptr [mplayerc+0x38e07c
(0078e07c)],ebp
00431439 750b jne mplayerc+0x31446 (00431446)
0043143b 8b03 mov eax,dword ptr [ebx]
0043143d 8b4818 mov ecx,dword ptr [eax+18h]
00431440 890d7ce07800 mov dword ptr [mplayerc+0x38e07c
(0078e07c)],ecx
00431446 8b13 mov edx,dword ptr [ebx]
00431448 8d442414 lea eax,[esp+14h]
0043144c 50 push eax
0043144d 6a10 push 10h

I cannot provide full debug symbolic information in the stack trace because
I do not have the debug symbols for this application. So unfortunately all
I can offer are the module offsets and some assembly instructions to start
us out. However, I'm hoping the following information can point you in the
right direction.

If you need any further assistance, please do not hesitate to contact me.

Thank you,
Dominick Roselli
SDE - Windows Error Reporting
Microsoft Corporation
domir@microsoft.com

_xxl
31st August 2009, 15:42
2008-12-10 07:14:31.000
szVersion
6.4.9.1
This file is from Guliverkli2 project? What about mpc-hc?

clsid
31st August 2009, 15:52
That undoubtedly has similar issues.

tetsuo55
31st August 2009, 16:03
Microsoft cannot see the difference between MPC and MPC-HC.

This is the main reason why the .exe name has changed starting with the new stable.

MPC-HC crashes too (happens to me all the time), so now with new exe name MS can collect data about MPC-HC.exe and give us info about the crashes.

avivahl
31st August 2009, 17:54
Microsoft cannot see the difference between MPC and MPC-HC.

This is the main reason why the .exe name has changed starting with the new stable.

MPC-HC crashes too (happens to me all the time), so now with new exe name MS can collect data about MPC-HC.exe and give us info about the crashes.Looking at the content of that e-mail, you guys might wanna release debugging symbols with each official MPC-HC release.

ctl-tx
31st August 2009, 17:56
I'm having trouble getting VSFilter 2.39 to work with MPC-HC 32bit in Win7 64bit. The most annoying thing is, I actually succeeded once! But then I foolishly checked "autoload subtitles" in the playback options (to do some testing) and lost it for good.
Since I can't seem to run CUDA or DXGA with my setup and MPC-HC's internal mkv spliter doesn't deal with ordered chapters, I decided to revert to my traditional MPC config. Haali spliter, VSFilter and ffdshow and CoreAVC for H264.
My installation procedure was as follows, the order may or may not be correct:
1. Install Haali. Set to autoload VSFilter.
2. Register VSFilter using regsvr32. The VSFilter.dll file is not in the Windows system directory, by the way.
3. Install ffdshow and CoreAVC.
4. Uncheck "autoload subtitles", mkv and H264 filters from MPC-HC.
5. Set VSFilter to always load. I did this after previous attempts failed.

Yet, no matter what I do, MPC-HC refuses to use VSFilter, it's either its internal subtitle filter, ffdshow's own unappealing filter or nothing, this is most frustrating.
Perhaps I should have registered VSFilter before installing Haali? Can anyone give me some suggestions on how to proceed?

diman1982
31st August 2009, 18:51
can anybody help me?
hello
how to make all videos always to open in mpchc with certain(0,91) zoom?
"remember last window size" option does not work.
version 1.2.1161

BetaBoy
31st August 2009, 18:52
Microsoft also receives plenty of crash logs about MPC and its standalone splitters. Can you back up your instability claim about Haali with personal experiences, or are you just parroting numbers?

Haali is supposedly working on a new version, which will address several of the known issues and limitations of his splitter.

Correct he is... and that includes removing thumbnail support which is 90% of the reported problems with it.

clsid
31st August 2009, 18:54
@ctl-tx
Solution can be found here:
http://www.codecguide.com/faq_subtitles.htm#item12

BetaBoy
31st August 2009, 18:54
thats me and i didnt know that about dxva on nvidia (i dont use any form of dxva/cuda as i have a quad core) and the nvidia dxva being able to decode 16 ref frames has been added to and removed from svn multiple times thats really reliable. main issue imo is you cant use intermediate filters, im sure reclock counts as one and is very useful to a lot of people, tbh i dont see the point of things like ffdshow (video filters) if playing hd video but im sure there are people out there who like to use all sort of shitty filters which they cant with dxva

Frame limits were removed in the 2.3 CUDA SDK which CoreAVC will support when 2.0 is released.

clsid
31st August 2009, 19:01
Correct he is... and that includes removing thumbnail support which is 90% of the reported problems with it.Bummer. Isn't it possible to fix those crashes? Because removing thumbnail support will probably make many HMS users unhappy.

STaRGaZeR
31st August 2009, 19:11
What are the steps required on a fresh install of Windows to get thumbnail extraction of a given file extension? Splitter and decoder are necessary, but do you need any registry modifications for .mkv and .mp4 for example?

ADude
31st August 2009, 19:26
Big cheers and clapclaps to the devs for all the hard work, getting a stable release out and still bashing away at it.

To the whiners: pull your head in. The guys here do this work voluntarily and assign priorities in the way they see as best. I personally couldn't thank them enough. MPC-HC has come on in leaps and bounds in the last few months, and we have 4-5 individuals to thank for the bulk of it.

I think you do not understand software development.

Everyone in this thread is a volunteer doing beta testing. Without beta testers, all the regular users would get buggy software. Beta testers help developers to do their job.

What you call "whiners" are simply beta testers who strongly advocate certain fixes or changes that they think will make MPC-HC better.

ADude
31st August 2009, 19:27
I can confirm this behaviour for the recent MPC-HC versions on XP 32 as reported by ADude. It came up at the same time when the "Launch files in fullscreen" mode was broken once (in 1222 or 1223), but although that has already been fixed for a while, the "tiny window" which appears after closing fullscreen mode still exists.

Should this be submitted to the bug tracker, or is it an already known bug in the queue to be fixed ?

tetsuo55
31st August 2009, 19:35
Should this be submitted to the bug tracker, or is it an already known bug in the queue to be fixed ?needs to be added to the tracker

ctl-tx
31st August 2009, 19:35
@ctl-tx
Solution can be found here:
http://www.codecguide.com/faq_subtitles.htm#item12

Thanks for the heads up. I'll give the "make directvobsub a preferred filter" method a try. I tried that once before, but when I selected VSFilter, two items appeared in the list, "directvobsub" and "directvobsub (autoloading version)". I left both checked and did not choose to prefer the autoloading version. I suppose that made the attempt fail.
Yet, before that attempt, I did manage to get the autoloading version to kick in once. But I can't remember how I did it. I also can't remember if it was the older MPC 6491 or MPC-HC that managed it.

Edit: There's one other thing I noticed about MPC-HC 32bit. I just confirmed it's still there in the latest unstable. If it used external filters for video, it isn't removed from memory after it's closed. Playing more videos using external filters just adds more instances of MPC-HC to the memory. This is on XP. I'll check it out on Win7 tomorrow.

3ngel
31st August 2009, 20:18
I want to signal a very strange situation concerning colorspace conversion.

This is the result of an .avs (simple directshowsource("test.grf") played in mpc and virtualdub
With the last row as ConvertToRGB32()

http://img149.imageshack.us/img149/7638/avscrop.png

This is the SAME filter chain (as in test.grf) played straight into mpc (no RGB32 final)

http://img168.imageshack.us/img168/4199/mpccrop.png

There is a remarkable discrepancies in the two color hue.

This difference remains using VMR7/9 (window/renderless) and EVR but is almost identical using haali render (altough some very very little color difference remains).

What's the matter?

buzzqw
31st August 2009, 21:14
tryed with MadVr?

BHH

3ngel
31st August 2009, 21:25
MadVR doesn't allow me to save the image (GetDib failed).

buzzqw
31st August 2009, 21:27
while watching you see a coloring issue with madVr ?

BHH

3ngel
31st August 2009, 21:33
Got around it in getting the screenshot. Yes, same exact issue as the others.
The only correct seems to be Haali.

sneaker_ger
31st August 2009, 21:51
Try to change the options "YUY Colorspace" and "Luma range" in Haali's Renderer. There are different ways of converting colors to RGB. Look into the AviSynth documentation under ConvertToRGB() for more info.

ADude
31st August 2009, 22:00
What is the status of MadVR and what is the status of MPC-HC support for MadVR ?

( I seem to remember some sort of situations where MadVR would not work well... )

3ngel
31st August 2009, 22:02
Another update.

In Vdub removing the RGB32() the image is exact as haali, so it's high probability an MPC issue (caused pheraps by the fact that Mpc does convert everything to YUY2? Infact Haali see YUY2 as input even if i've forced YV12 in decoder) 'cause vdub does disaply the YV12 as the same as Haali (and both the same as Avisynth RGB32().

clsid
31st August 2009, 22:15
Haali does not accept YV12 input iirc, so forcing the decoder will do nothing useful.

Casimir666
31st August 2009, 22:18
Looking at the content of that e-mail, you guys might wanna release debugging symbols with each official MPC-HC release.

Debugging symbols is keep for official releases, but Microsoft cannot send us the minidump because of privacy issues. Only WinQual certified software can have access to the dumps, but it cost between 100$ and 400$ per year to have a digital certificate.

St Devious
31st August 2009, 22:35
is there a subtitle editor or subtitle resync function in MPC HC ?

ADude
31st August 2009, 22:45
What is the status of MadVR and what is the status of MPC-HC support for MadVR ?

( I seem to remember some sort of situations where MadVR would not work well... )

I checked the MadVR thread, and the current problem is ... shock ... tearing.

And I remembered that the gotcha of MadVR is that it does everything using the GPU, in a strangely hypocritical fashion. When asked about the fact that it will never support DXVA, the reply is the same thing I have been saying, that DXVA is pointless because super fast CPUs now cost only pennies. And the thought never occurs that the same logic could be applies to doing everything in GPU shaders...

PS I submitted the "tiny window" bug to the bug tracker.