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

[JanWillem32]

For those that have missed me, I lost my Internet connection due to issues with copyrights.
The pictures I've posted have been removed, and I hope to resume normal work within a few days.

[pirlouy]

Please don't answer to Sina. Report his posts to admins. It would be enough...

[cca]

For those that have missed me, I lost my Internet connection due to issues with copyrights.
The pictures I've posted have been removed, and I hope to resume normal work within a few days.

Welcome back, and be careful. You see how much influence the copyright lobbies have...

[vood007]

Please don't answer to Sina. Report his posts to admins. It would be enough...

Reported him too. What a clown...

[mr.duck]

i'm a designer & this terrible design is not tolerable.
WHAT THE HELL?!?! LOL!

There are plenty of options already if you want a bloated, modern interface. Just use Windows Media Centre or something. Arcsoft total media thing or some other feature laden apps.


MPC is so outdated now, we could just refer to MPC-HC as MPC from now on and people will know what we mean.

[tetsuo55]

This discussion is not leading us anywhere.

@Sina:
Changing the name is not something to be taken lightly. Our name is well known all over the world. Changing it would be confusing to most of our users.

If you have a problem with the name not fitting into certain menu sections nicely than we can talk about using the short name in those areas.

MPC-HC is an open-source volunteer project. This means nobody gets payed and the changes to the source are made by people who do this for fun in their spare time.
You say you are highly skilled in design, i would gladly accept patches that make the gui changeble, and if a vote shows that many people like your default skin we can consider making it the default (as long as performance is not impacted)

For more information about how open source works you can read this: http://producingoss.com/

----

@ All.
Let's stop this discussion for now, when someone makes a patch, or a sound business-case for a name change we can re-open the discussion.

[cyberbeing]

MPC-HC x86 2938@JanWillem32 + CMS Test v5 (http://www.mediafire.com/?tp57vj8tuw962k5)

I finally took some measurements with a freshly calibrated profile, and it seems my previous assumptions were incorrect.

madVR + 3DLUT (Gamut_Measurements Only) = 2.36 Avg Gamma, 0.76 Avg DeltaE 30-100 IRE

Ambient Bright + Inverse Encode = 2.26 Avg Gamma, 1.708 Avg DeltaE 30-100 IRE

Ambient Dim + Inverse Encode = 2.54 Avg Gamma, 1.427 Avg DeltaE 30-100 IRE

Primary and secondary DeltaE are much worse than madVR as well.

I will contact with Graeme Gill again to find better fitting CIECAM02 parameters.

Any progress using CIECAM02 to make a fast transform (instead of full correction) with Graeme Gill's improved parameters?

[janos666]

Here is a working copy: 2947@JanWillem32+CMSTestv6 (http://www.mediafire.com/?lwalxjpb182cdux)

Changes:
- 16-bit 3dlut texture for 16-bit surface mode (Half Floating Point option) and 32-bit texture for 32-bit surface mode (Full Floating Point option). -> CMS should work with Intel IGPs and old VGAs too (again).
- The 3dlut creation should consume less system memory now and should be slightly faster. -> Theoretically. Let me know your experience.

To be honest, I am not even sure about what did he meant with that "fast transform". But I think it covers my idea: use the CIECAM transform on some (like 256 gray or 256+256+256 R,G,B colors instead of all colors in the 3DLUT) and use the result to set up a new lut-based transfer function (precalculated numbers from an external software, zero real-time CIECAM02 calculations in MPC-HC).
It would greatly improve the speed but MAY BE decrease the quality a bit, so I don't want to change the current parametric curve (and real-time pixel processing) based transfer until we decide if we want to keep this Inverse Encode thing or not.
And it won't be necessary if we have to cache the 3dlut texture on the HDD anyway. (It depend on the user experiences with the "Lookup Quality" option. -> High Quality is slow anyway, even with pure-power curves.)
I would get it working first before I try to optimize the speed. But may be it will be the same thing. I am not yet sure how CIECAM02 works.

I am currently trying to make new (bigger and better) dither matrix (for the Full Float mode, and leave the old for the Half Float mode...)


How do you calculate those dE values? What is your reference? What is the dE number with pure-power curves?

[cyberbeing]

To be honest, I am not even sure about what did he meant with that "fast transform". But I think it covers my idea: use the CIECAM transform on some (like 256 gray or 256+256+256 R,G,B colors instead of all colors in the 3DLUT) and use the result to set up a new lut-based transfer function (precalculated numbers from an external software, zero real-time CIECAM02 calculations in MPC-HC).
It would greatly improve the speed but MAY BE decrease the quality a bit, so I don't want to change the current parametric curve (and real-time pixel processing) based transfer until we decide if we want to keep this Inverse Encode thing or not.
Real-time pixel processing I assume would apply the entire CIECAM02 visual appearance model to all colors. Do you actually want to be doing this? It goes way beyond just a gamma curve and will actually change the chromaticity of pixels based on their surrounding pixels in real-time. Generating this calculation still takes 42 seconds with high lookup quality. A couple times even ate up ~1GB of RAM, but other times there was no memory increase? Not sure the explanation for that. In any case, if it stays like this, it would never be practical to use.

Was anything with the CIECAM02 Inverse Encode calculation actually changed in this build? It appears about the same as your last build. I'll do some measurements later, but I wouldn't be surprised if the results were the same as my previous post.

How do you calculate those dE values? What is your reference? What is the dE number with pure-power curves?
They were calculated in ColorHCFR.

The Grayscale is referenced with D65.
The Primaries and Secondaries are referenced with the REC.709 Primaries and Secondaries.

Neither is referenced with gamma afaik.

[skampy]

Would anyone be able to tell me why I am not able to play the following video? MPC-HC simply crashes before it begins to play (Media Player Classic - Home Cinema has stopped working). Here are video details:

General
Unique ID : 225750044276386840738155841697198440217 (0xA9D5E084813EC941B45E34F397FCFF19)
Complete name : J:\Movies 3\Red Cliff - Part I (Blu-Ray DTS-MA).mkv
Format : Matroska
File size : 23.4 GiB
Duration : 2h 25mn
Overall bit rate : 23.1 Mbps
Encoded date : UTC 2011-02-26 10:02:38
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 25mn
Bit rate : 21.0 Mbps
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.559
Stream size : 21.3 GiB (91%)
Title : x264 2pass @ 21030 kb/s
Writing library : x264 core 114 r1913 5fd3dce
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=21030 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Codec ID : A_DTS
Duration : 2h 25mn
Bit rate mode : Variable
Bit rate : 1 636 Kbps / 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossless / Lossy
Title : Mandarin DTSHD-MA 5.1
Language : Chinese


But I have countless others that I can play that are nearly exactly similar, including the following which has the same FPS:

General
Unique ID : 231596594054338785825904625798090131484 (0xAE3BE1AD4F16D81288E2A7ECF1B5081C)
Complete name : I:\Movies 2\The Descent (Blu-Ray DTS-MA).mkv
Format : Matroska
File size : 14.7 GiB
Duration : 1h 43mn
Overall bit rate : 20.4 Mbps
Encoded date : UTC 2011-01-11 06:29:20
Writing application : mkvmerge v4.4.0 ('Die Wiederkehr') built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 43mn
Bit rate : 18.7 Mbps
Width : 1 920 pixels
Height : 818 pixels
Display aspect ratio : 2.35:1
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.497
Stream size : 13.2 GiB (89%)
Title : x264 2pass @ 18730 kb/s
Writing library : x264 core 112 r1834 a51816a
Encoding settings : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.05:0.15 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=18730 / ratetol=1.0 / qcomp=0.70 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Codec ID : A_DTS
Duration : 1h 43mn
Bit rate mode : Variable
Bit rate : 1 561 Kbps / 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossless / Lossy
Title : English DTSHD-MA 5.1
Language : English

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1h 43mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 142 MiB (1%)
Title : Commentary
Language : English


Any ideas? :(

[janos666]

apply the entire CIECAM02 visual appearance model to all colors.
Yes, that's what I did. It processes colored pixels (every pixel in the 3DLUT texture one-by-one).
It goes way beyond just a gamma curve and will actually change the chromaticity of pixels based on their surrounding pixels in real-time.
It was easier to do and sounded better for the first time.
Do you actually want to be doing this?
Now that it proved to be inefficient (on both performance and quality sides), I guess I will come up with something else.

A couple times even ate up ~1GB of RAM, but other times there was no memory increase? Not sure the explanation for that.

It was Jan's idea to change the compiler settings to static memory management. It won't remain like this.

Was anything with the CIECAM02 Inverse Encode calculation actually changed in this build? It appears about the same as your last build.

I tried to tweak the CIECAM02 view condition settings according to the ArgyllCMS settings.

But you shouldn't bother yourself with measuring the result. I will either change the whole CIECAM02 thing or rip it out.


But, if you have any time to spare with measuring and/or subjective comparing, I would ask you to compare the Pure Power results:
Vanilla build <--> My build with Low Quality LUT (basically the same with some small changes to improve quality without penalty).
My build with Low Quality LUT <--> My build with High Quality LUT. ("Brute force" improvement: higher LUT size - let me know if you find it inefficient)
(And keep your usual calibration LUT! I want a test with heavy image manipulation anyway...)

I have an old excel sheet for parsing the results: yCMS_Argyll_comp_v0.2.rar (http://www.mediafire.com/?2ulovtjb00d9hsb) but HCFR is as good as any (until you have a colorimeter)...

[G_M_C]

Here is a working copy: 2947@JanWillem32+CMSTestv6 (http://www.mediafire.com/?lwalxjpb182cdux)

[...]


I've tried this one. It just crashes on my machine. The process is simply killed, disappears from the desktop and Win7-64 makes an error report to MS. No error message whatsoever, it just terminates.
More precise info: The crash occurs after some/a few minutes into my video. So the video DOES start, plays ok for a few minutes, and then the above happens. Tested video's are all H264 (720p/1080p/1080i). MPC's video decoder (DXVA). Outputted on secondary screen through HDMI. Audio streamed.

Renderer settings (most of em anyway);
Full screen D3D
dithering level 9
10 bit output
full floating point precision
Ambient (dim) 2.35
trc type =pure power
wp adapt state = medium
lookup quality = high
No BPC (what is that anyway ?).

Shaders: the combined shaders Janwillem advises (4:2:0 up-sampling into the -> 4:2:2 up-sampling)

Graphics board: HD 5770. Cat 10:12.

PS: Tried setting to medium precision FP, medium precision lookup etc. That seems to work. But not finished testing yet.

[janos666]

The Full Floating Point Precision + High Lookup Quality options together produce a very large 3dlut texture (somebody may call it "insanely big").
The Half Floating Point Precision mode creates half precision textures which need less system and VRAM.
(Half Precision otherwise requires equal or slightly more CPU time because the lcms result is always full precision and only the texture is half precision, so it has to be converted into half precision first which is an extra step...)
The Lookup Quality controls the size of the 3dlut which greatly affects the system and VRAM consumption as well as the startup time.

BPC = Black Point Compensation -> Eliminates black crush on relatively low contrast displays. (It needs cLUT profiles, won't work with matrix profiles.)


@G_M_C
I think you should update your VGA driver to 11.02WHQL

UPDATE: I solved the CIECAM02 performance problem, so one less thing to worry about.

[mr.duck]

Can it be possible to use MPC-HC to watch a TV program that is being recorded (TS file, MPEG2)? The problem is that MPC can only play the first few mins and then it stops and you have to reopen the file to get the new length to play a bit more. The TS file is constantly being updated so I want to make MPC just keep playing as there is more video available.

Just make the seekbar greyed out and start playing 5 sec from the end of the file would be fine. Does that sound like a good idea?

[G_M_C]

The Full Floating Point Precision + High Lookup Quality options together produce a very large 3dlut texture (somebody may call it "insanely big").
The Half Floating Point Precision mode creates half precision textures which need less system and VRAM.
(Half Precision otherwise requires equal or slightly more CPU time because the lcms result is always full precision and only the texture is half precision, so it has to be converted into half precision first which is an extra step...)
The Lookup Quality controls the size of the 3dlut which greatly affects the system and VRAM consumption as well as the startup time.

BPC = Black Point Compensation -> Eliminates black crush on relatively low contrast displays. (It needs cLUT profiles, won't work with matrix profiles.)


@G_M_C
I think you should update your VGA driver to 11.02WHQL

UPDATE: I solved the CIECAM02 performance problem, so one less thing to worry about.

I dont know if updating drivers is the solution, but will do later.

Question for all;
Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

[CSMR]

I've made some changes to this click behavior...

Basically, if you have any bars(caption/seekbar/control/information/status/ etc), then you can click to pause/resume, but if you don't have any bars like preset->minimal mode, the mouse will be used to move window instead. So if you like Borderless/FrameOnly mode and also want to click pause/resume, turn on any bar from View menu will do that.
Current build 1.5.1.2953 works like this. I'm not sure this is ideal.

With some bars (e.g. status), you can move the window via status. So activating them and having mouse pause/resume is workable. Other bars (e.g. seek) you can't move the window with. With only seek, for example, there is no way to move the window, since mouse pauses/resumes.

A quick fix for this would be: if any bars are active that allow moving the window, mouse pause/resume is active, otherwise mouse moves the window.

However I don't think it's intuitive that this behavior changes when bars are removed or added. Whether you can move the window or pause or resume with mouse on the main area shouldn't depend on what information you choose to display. Instead can't there be a setting? Default is non-minimal mode, usual bars, and mouse pause/resume. Using minimal mode implies ability/desire to tweak, so an extra setting is not a problem.

[janos666]

I dont know if updating drivers is the solution, but will do later.

Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

The Full Floating Point option doesn't work properly with some old AMD drivers. I can't remember exactly but may be it was fixed somewhere around 10.12 (or earlier?). I test the debug builds with 11.02WHQL (HD5850 1Gb).

I would wait with that decision until the dithertexture gets updated with a bigger matrix and higher precision numbers, and the Inverse Encode curves are finalized.
(The High Quality setting is mainly for the Inverse Encode curves because they usually lay further from the usual display TRC.)

[Hera]

Where did subtitles go with Haali Renderer? I don't get that option with Athlon, NV6600, and XP. I do with Athlon II, 4250 Mobile, and 7.

[djesteban]

I am trying to play an .avs script in mpc-hc x64 after installing avisynth x64. I get an error saying Cannot render the file. Now, avisynth x64 seems to work fine since I can use it with dgdecnv x64, so is this a problem with mpc-hc x64 where avs script reading is disabled?
I found this feature request ticket number (http://sourceforge.net/apps/trac/mpc-hc/ticket/447) on the sourceforge for mpc-hc, any chance of getting this working in future release?

Thanks, cheers

[GrofLuigi]

I can't find the explanation for some recent changes in the changelog. In my .ini file some new things appeared.

1) FastSeek=1

What does it do? What does 0 do?

2) New lines of keymappings

Before:

CommandMod5=904 b 27 "" 5 0 0
CommandMod6=903 b 25 "" 5 0 0

After:

CommandMod5=902 3 27 "" 5 0 0
CommandMod6=901 3 25 "" 5 0 0
CommandMod7=904 b 27 "" 5 0 0
CommandMod8=903 b 25 "" 5 0 0

(the first two I had defined previously and forgotten what exactly they do, but I am sure I need them badly).

Are the new commands same/similar to before? Can they interfere?

GL

[G_M_C]

I dont know if updating drivers is the solution, but will do later.

Question for all;
Is there a objective visible difference on your TV or other device you actually watch the movie on between using 'Half Floating Point Precision + High Lookup Quality lookup' and 'Full Floating Point Precision + High Lookup Quality' ?

I quote my own post for janos; Can we agree that the difference between half en full (as per my question) is negligible? If so, i'll leave it to half floating point precision untill the reason for crashing is more clear. Cause Half Floating Point Precision + High Lookup Quality doesn't crash (watched two full movies without crash).

[janos666]

If so, i'll leave it to half floating point precision untill the reason for crashing is more clear.

It depends on many things, like: display characteristics, profile type and quality, color sensor accuracy, your profiler software and your profile creation settings (and your calibration practice), your personal taste (smoothness or accuracy), etc.

I think the Half Floating Point with Medium size is more than enough in most cases.
So, you don't have to worry with either Full precision + Medium LUT size, or Half precision + High LUT size.

I think I would prefer Full precision + Medium size because it takes less time to start the playback.


***
Remember, that the existence of an option itself doesn't mean that you have to use it. It only means that you are free to test it and it's available if you feel that you need it. So, don't push it!
***


You can check the results with these test videos: http://www.avsforum.com/avs-vb/showthread.php?t=948496.
I usually use the first 4 videos from the Additional directory and the black/white clipping from the Basic Settings folder.

[hoborg]

Hi.
Can somebody compile MPC mpeg splitter to output WVC1 as {D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53} instead of {31435657-0000-0010-8000-00AA00389B71} like LAVF do?
Just for test interlaced VC-1 with PDVD10 decoder.

Thanks.

[G_M_C]

It depends on many things, like: display characteristics, profile type and quality, color sensor accuracy, your profiler software and your profile creation settings (and your calibration practice), your personal taste (smoothness or accuracy), etc.

I think the Half Floating Point with Medium size is more than enough in most cases.
So, you don't have to worry with either Full precision + Medium LUT size, or Half precision + High LUT size.

I think I would prefer Full precision + Medium size because it takes less time to start the playback.


***
Remember, that the existence of an option itself doesn't mean that you have to use it. It only means that you are free to test it and it's available if you feel that you need it. So, don't push it!
***


You can check the results with these test videos: http://www.avsforum.com/avs-vb/showthread.php?t=948496.
I usually use the first 4 videos from the Additional directory and the black/white clipping from the Basic Settings folder.

The LUT; If someone doesnt use his own LUT, is the windows 'standard' used (in my case sRGB / 4:4:4 YUV) ? Cause my plasma has been ISF calibrated (sRGB for PC input, and 709 for HD video, D65 etc. if i remember correctly). So if my PC just outputs one of those, as close to the standard as possible, im good.

Hmmm, do i actually need the LUT in my case I wonder :confused:

[janos666]

The LUT; If someone doesnt use his own LUT, is the windows 'standard' used (in my case sRGB / 4:4:4 YUV) ? Cause my plasma has been ISF calibrated (sRGB for PC input, and 709 for HD video, D65 etc. if i remember correctly). So if my PC just outputs one of those, as close to the standard as possible, im good.

Hmmm, do i actually need the LUT in my case I wonder :confused:

It asks Windows for a profile first and creates a standard sRGB profile if there is no response.

If you don't have any ICM profiles for you display then I suggest to turn OFF the CMS in MPC-HC. (At least for HD videos, because you mentioned Rec709 but SD NTSC and SD PAL/SECAM are all different.)

Without having an ICM file, some kind of "calibration report" or post-calibration measurement data, I can't say more.

This is not a simple question. The IFS guy adjusted the hardware controls. But...
- What is the effective precision of the hardware processing?
- What controls does your hardware offer?
- What was his real target? (I doubt he aimed the real sRGB curve. And the gamma<-vs->scaled_inverse is another religious question for Rec709, etc.)
...and so on...


If you really care about quality and color accuracy, I suggest to buy an own sensor (be careful: a WCG display requires spectrophotometers and spectros requires extra care when you use them on high contrast displays...) and do the calibration and/or profiling for yourself.
The ISF guy may has an expensive instrument but your hardware will drift more in one month that this difference.
He may has routine but he doesn't know every single displays like you can know your own display.
His aim is probably the "good enough to get paid" and not the "as good as anybody could do it".


I personally prefer to skip the entire calibration if possible (or choose a target which is as close to the native characteristics as possible), construct a high quality profile and use high quality software processing.
It gives you the freedom to easily adapt to any source materials (starting from AdobeRGB to sRGB and Rec709 or PAL...) and the calibration+profiling process is also more convenient without the profiling step.
However, it doesn't mean that it's a good practice for every hardwares or that I don't change anything in the hardware menu...


And I could continue it for pages but this is not that froum topic.

[Matching_Mole]

I have a quick question about th EVR renderer and its action on color without the color management feature activated.
Currently I resize video and convert it into RGB32 in FFDshow. In MPC I use the EVR Sync renderer and set up the Video Frame option in "Normal Size" in order to avoid any re-resizing from the renderer. But, even if the data are already in RGB32 when they are sent to the EVR presenter, do it make additional conversion/operation on the data and if yes what are they?

NB: obviously I set up all the video options in Catalyst Center of my old ATI 2600 XT in "Use Application Setting".

With the last developments (and thanks to the developers for all their works!) I'm a little lost to know what actions are actually done by the renderers. And it seems that the CMS developments concern only VMR9 and EVR Custom, do you plan to add it to other renderer as EVR-Sync (from my understanding no).

[janos666]

Why do you use EVR-Sync on the first place?
Did you try EVR-CP with different V-sync options?

I could see some people who struggled with EVR-Sync. And the solution was (for their sync problems!) to use EVR-CP instead.

For me, it's the best to disable V-sync or use V-sync with the Accurate V-sync option (desktop Radeon). On my laptop (mobile Geforce), I use V-sync + Alternate V-sync.

And don't forget to try the Full Screen Exclusive mode and/or disable Aero.

I think the EVR-Sync renderer is outdated in many ways. If I were in the position to make this decision, I would rip it out, because it's abuser (you think you should use it for best sync but no, you would probably be better with the EVR-CP sync options while you give up the other benefits of EVR-CP...).

[Matching_Mole]

Why do you use EVR-Sync on the first place?
Did you try EVR-CP with different V-sync options?

I use EVR Sync since one year or more in my HTPC because it give me a perfect playback with almost no stuttering (99% of time) and absolutely no tearing. And have this result took a lot of time in order to find the exact correct timing in Powerstrip for each movie fps (so 23.976, 24, 25, 29.976 and 30fps) because I don't want to use reclock.

I chose EVR sync at this time because I didn't find the correct set up in EVR custom to have the same stability in the results. But maybe now the things are better and I can try again!

[Leslie Pierce]

howd to install codecs to windows media player

[ikarad]

I found a problem with ffdshow 3760 and mpc-hc
https://sourceforge.net/apps/trac/mpc-hc/ticket/1187
The back right channel (speaker) and the LFE crossover channel are swapped. I found a workaround for this problem by using the swap channel options to swap the LFE and Back right channels.

I try with ffdshow since 3361 and thre is the same problem. I try
with different version of mpc-hc (1.2.2972 until the last 1.5.1.2931) and
There is the same problem
(I haven't tried with older version of ffdshow and mpc-hc)

I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only

here http://forum.doom9.org/showpost.php?p=1481175&postcount=13095
Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.


Gleb Egorych has tested with other players as mpc-hc and there is not the bug. He said that the bug is due to mpc-hc.

I don't know if it's a bug of ffdshow or mpc-hc and I post bugreport here (bugtracker https://sourceforge.net/apps/trac/mpc-hc/ticket/1187) and in the topic of ffddhow (and bugtracker of ffdshow)

[oddball]

Sorry if this has already been bought up but if I enable D3D Fullscreen (My preferred playback method) it takes AGES to exit the player. Especially if I am playing video. Sometimes it takes as long as 10-15 seconds to exit. I ttired a clean install of various flavors from 2499 onwards but it's the same. I wonder if this is an issue with the latest Nvidia drivers.

EDIT: It's not just D3D mode. Even when the player is doing nothing (Just open it. Leave it for a little bit then try to exit) it takes ages to exit.

EDIT: I think I solved it. I followed the FAQ about disabling the 'Hide CD/DVD-ROMS' menu problem and it seems to have fixed it. It now exits correctly with no lag/not responding. I think it might have something to do with having VirtualCloneDrive installed (Recent addition to my setup).

[Aleksoid1978]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]

I propose to do so:
x86 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema]
x64 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema x64]

This is better for different x86 and x64 version - in this we can have different settings, speciality for External Filters.

Waiting for your opinion :)

[fastplayer]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]
Remove "Gabest" from the key and shorten it to "MPC-HC" resp. "MPC-HC64".

[nevcairiel]

Renaming the registry keys will cause everyone to lose their settings. I also don't think its required to seperate them. There is no real reason why anyone would run both x86 and x64 on the same system. You pick one that works best for you, and then stick to it. And even if they did, it would probably cause alot of confusion why the settings didn't stick when changing it in one version.

[fastplayer]

Renaming the registry keys will cause everyone to lose their settings.
I probably should've mentioned that I assumed this change was in preparation for a new official MPC-HC version which could transfer the old settings. :)

[Mercury_22]

To all - what you think about different key in registry for x86 and x64 ???
Now we have - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic]

I propose to do so:
x86 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema]
x64 - [HKEY_CURRENT_USER\Software\Gabest\Media Player Classic Home Cinema x64]

This is better for different x86 and x64 version - in this we can have different settings, speciality for External Filters.

Waiting for your opinion :)
Remove "Gabest" from the key and shorten it to "MPC-HC" resp. "MPC-HC64".
Totally agree with both

And maybe solve this related bug too
There is a problem with the default player when there are both (x86 & x64) MPC-HC versions on a system :
If I set one version, let's say x86, as default player for all (any) formats if I open the other one (x64) and I just go to "Formats" (options --> Formats) without changing anything (nothing it's selected) and then close it (the x64 version) the first version (x86, which was set as default player for all formats) it's NOT anymore the default player for all formats

Can somebody do something about this ?

EDIT: I'm guessing that maybe there is a "64" missing in the x64 version format association

Yep, it would indeed probably be better to let the x64 build use "mplayerc64.extension" instead of "mplayerc.extension" for its file associations. Should be an easy change for the devs.

[boyumeow]

I agree with nevcairiel that we do not need to run both x86 and x64 on the same system especially there is x64 ffdshow, unless U are testing or trying to run with other programs that do not have 64bit support. Thanks.

[mark0077]

Because many filters / renderers don't support x64, wouldn't having both mpc versions sharing the same settings cause problems?

For example I use the 64bit version of mpc and ffdshow recently to get better avisynth script frame rate conversion performance, but of course in that config I can't use reclock or madVR. Its not a big deal for me but I don't know if sharing settings between the two is acceptible to everyone, maybe most but not all... especially if they intend to use both versions slightly differently as I do... using different renderers etc. If madVR and reclock had x64 versions it wouldn't be an issue for me :) to have them sharing the same settings which would make more sense but x64 hasn't and probably never will fully catch up? Would it be much work to make it optional, like when x86 mpc version is started, and then later an x64 version, couldn't the x64 version ask, do you want to use the same settings as x86 version or not with the warning that not all settings may work between the two because of lack of x64 versions of particular filters / renderers.

[Virtual_ManPL]

I support idea of using different keys for each version
x86 - [HKEY_CURRENT_USER\Software\MPC-HC]
x64 - [HKEY_CURRENT_USER\Software\MPC-HC64]

I use 64bit versions of MPC-HC, LAVFSplitter and Xvid.

ffdshow, CoreAVC, MainConcept, CyberLink & Haali splitter have also 64bit versions.
So it's quite large group to choose your favorite decoder or splitter.

[v0lt]

Why do you have two versions of the player with different settings? :confused:

[mark0077]

Why do you have two versions of the player with different settings? :confused:

Because some software like filters / renderers arn't x64 yet, hence the difference in settings. mpc 32 bit pointing to reclock and madVR isn't going to work with mpc 64 so identical settings isn't 100% possible for everyone. Even large pieces of software like photoshop has seperate settings for its 32 and 64 bit versions, I assume for similar reasons with some plugins not being 64bit yet etc..

[HoP]

i don't know its a bug or no but if subtitle started with quote( ' ) it cant be displayed
i haven't this problem with PotPlayer
http://www.pixelz.fr/2/9/7/e1d9727acff61213b4923dff4aefd.jpg

[pdanpdan]

@HoP - It's an error in the subtitle file - it should be 1, not '1

[HoP]

@HoP - It's an error in the subtitle file - it should be 1, not '1

yes..i know but mpc should display it like other players(ex.PotPlayer)

[fastplayer]

yes..i know but mpc should display it like other players(ex.PotPlayer)
No, it shouldn't. That SRT is not "valid":
http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format
http://www.matroska.org/technical/specs/subtitles/srt.html

[Sebastiii]

Hi.
Can somebody compile MPC mpeg splitter to output WVC1 as {D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53} instead of {31435657-0000-0010-8000-00AA00389B71} like LAVF do?
Just for test interlaced VC-1 with PDVD10 decoder.

Thanks.

Hi,

Aleksoid make a patch for it, i have started it too but his approach is better.

Now we have a setting in registry : VC1_Decoder_Output in
HKEY_CURRENT_USER\Software\Gabest\Filters\MPEG Splitter for standalone Filter
HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Filters\MPEG Splitter for MPC-HC soft.

1- Standard Connection (Microsoft DMO) "{31435657-0000-0010-8000-00AA00389B71}"
2- Cyberlink PDVD Codec "{D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}"
3- Arcsoft Codec "{629B40AD-AD74-4EF4-A985-F0C8D92E5ECA}"

A dialog menu will be add soon :)

Standalone Filter, MPC-HC and reg file can be downloaded here :
MPC_vc1_Filter_Reg (http://www.mediafire.com/?jne6w47060dw7rc)

Thank you Aleksoid :)
Sebastiii.

[nevcairiel]

That would all not be needed if the MPEG Splitter just wouldn't be so dumb and support multiple media types.
These Hacks make everything just worse.

[Sebastiii]

Effectively, would be nice, i don't know how to do this :(
I hope that eventually can be made :)

But for sure like with this patch connection is working outside MPC-HC.

Seems Lavf has an issue (for now) : http://forum.team-mediaportal.com/719214-post68.html

Thanks,
Sebastiii.

[nevcairiel]

VC-1 will always have broken timestamps. The MPC-HC MPEG Splitter will actually be worse. LAV Splitter does not need Frame-Time correction when using EVR. MPC-HC Splitter does, at least when being used with Internal decoder, ffdshow or MS DMO Decoder.

There is still controversy where the VC-1 timestamps should be fixed. I decided to fix them in the splitter, but i didn't offer options to turn it off.

I think i will offer an option in LAV Splitter to disable the VC-1 timestamp fixing code, maybe the PDVD decoder requires the broken timestamps and fixes them itself (and double fixing results in breaking).

I'll create a test build later today with the fixing code turned off, so you guys can throw it at your VC-1 with the PDVD decoder and see what happens.

[Sebastiii]

Ok nice nevcairiel :)
Thank you m8,
Seb.