Media Player Classic - Home Cinema (MPC-HC) - v1.7.13

[LigH]

Fast seeking usually depends on several factors: Correct interleaving, correct keyframe index (if the container supports it), GOP length. Unfortunately you did not tell us any technical details of the files which give you issues (means, a MediaInfo report), so it is not easy to give you a general solution, regardless of the file format.

If your file has a container which supports a keyframe index, then the "fast seek" option will have an impact: When enabled, the player will seek to the closest GOP start where decoding can start immediately, but the position where the playback starts may be a bit inaccurate, slightly distant from the time you clicked; otherwise, the player will seek to the last GOP start before the time you clicked, and then decode without display to the exact position, before the playback continues. This may be the case for e.g. AVI, MKV, MP4; but not M2TS, this container is packet oriented, there is no index, the player will always have to search for a valid playback start (to avoid decoding errors).

I would not know any reason immediately why e.g. the VLC player can handle such issues better.

[Solon8]

Originally Posted by LigH

Fast seeking usually depends on several factors: Correct interleaving, correct keyframe index (if the container supports it), GOP length. Unfortunately you did not tell us any technical details of the files which give you issues (means, a MediaInfo report), so it is not easy to give you a general solution, regardless of the file format.

If your file has a container which supports a keyframe index, then the "fast seek" option will have an impact: When enabled, the player will seek to the closest GOP start where decoding can start immediately, but the position where the playback starts may be a bit inaccurate, slightly distant from the time you clicked; otherwise, the player will seek to the last GOP start before the time you clicked, and then decode without display to the exact position, before the playback continues. This may be the case for e.g. AVI, MKV, MP4; but not M2TS, this container is packet oriented, there is no index, the player will always have to search for a valid playback start (to avoid decoding errors).

I would not know any reason immediately why e.g. the VLC player can handle such issues better.

Thank you for your reply.

I did not give technical details because the files vary a lot. They are MKVs most of the time, but it happened just as much with MP4.
I would say it actually happens to all big files of several GBs.

A typical example:

Video
ID                          : 1
Format                      : AVC
Format/Info                 : Advanced Video Codec
Format profile              : High@L4.1
Format settings, CABAC      : Yes
Format settings, ReFrames   : 4 frames
Codec ID                    : V_MPEG4/ISO/AVC
Duration                    : 1h 59mn
Bit rate                    : 10.0 Mbps
Width                       : 1 920 pixels
Height                      : 1 040 pixels
Display aspect ratio        : 1.85:1
Frame rate mode             : Constant
Frame rate                  : 23.976 fps
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Scan type                   : Progressive
Bits/(Pixel*Frame)          : 0.210
Stream size                 : 8.19 GiB (75%)
Writing library             : x264 core 67 r1162M f7bfcfa
Encoding settings           : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=10036 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Language                    : English
Default                     : Yes
Forced                      : No

For this one, if I go directly to 01:28:00, MPC freezes and stops for a few seconds, while VLC plays instantly.
I also noticed going forward takes longer than going backward, or going forward again. Seems like MPC needs to load stuff, then it's okay.

[LigH]

You only reported the analysis of the video stream here, not the container. At least you mentioned MP4 and MKV as usual formats... If you remultiplex MKVs with mkvmerge, and MP4s with MP4Box (or matching GUIs each), does the copy play better?

[Solon8]

Originally Posted by LigH

You only reported the analysis of the video stream here, not the container. At least you mentioned MP4 and MKV as usual formats... If you remultiplex MKVs with mkvmerge, and MP4s with MP4Box (or matching GUIs each), does the copy play better?

Hi,

No, remuxing doesn't help.

[LigH]

Maybe it's just an issue of disk caching, or swap file usage due to different RAM requirements... if seeking takes a longer time in one attempt, but not in another (especially seeking two times with the same player and getting different UI delays), I would suspect different amounts of disk activity during each attempt, which may not directly be related to actually seeking in the media file, but managing other needs of your system.

[flashmozzg]

Hello. I was wondering what happened to the MPC-HC project? It's been really long time since the last release. Is the (ever-decreasing) team waiting for something?
Anyway, I have a problem related to madVR and not sure if it's MPC fault or something's else: when I right-click (to open context menu) while in fill screen exclusive mode, the video goes black and MPC starts eating all avaiable 32 bit memory (about 3,8GB) and producing 60% CPU load. I have to manually terminate it from Task Manager (the player is still somewhat responsive, but won't close by itself). I'm on Win 10 x64, using MPC-HC 1.7.10 x86. Don't remember this problem before.

[ryrynz]

It slowed down a bit, use the nightlies if you want updates, they're plenty stable.

[huhn]

Originally Posted by flashmozzg

Hello. I was wondering what happened to the MPC-HC project? It's been really long time since the last release. Is the (ever-decreasing) team waiting for something?
Anyway, I have a problem related to madVR and not sure if it's MPC fault or something's else: when I right-click (to open context menu) while in fill screen exclusive mode, the video goes black and MPC starts eating all avaiable 32 bit memory (about 3,8GB) and producing 60% CPU load. I have to manually terminate it from Task Manager (the player is still somewhat responsive, but won't close by itself). I'm on Win 10 x64, using MPC-HC 1.7.10 x86. Don't remember this problem before.

AMD user?

change the prerendered frames to 6. rendering -> windowed mode -> "how many video frames shall be presented..." 6 or lower.

it is an old getting bug in the amd driver.

[flashmozzg]

Originally Posted by huhn

AMD user?

change the prerendered frames to 6. rendering -> windowed mode -> "how many video frames shall be presented..." 6 or lower.

it is an old getting bug in the amd driver.

Thanks! That worked! Don't remember having this issue few months ago though) I updated both madVR and my drivers since then so I'm not sure what exactly triggered it) Maybe madVR changed defaults or something in the update when it changed settings UI.

Originally Posted by ryrynz

It slowed down a bit, use the nightlies if you want updates, they're plenty stable.

Just interesting what's keeping them from deciding that "this" month they'll finally release a stable version postpone new features (if there are any)/risky updates for a bit and releasing what they have as a new stable. I saw some small activity on GitHub, but the is no indication of next stable release (the last one being almost 1 and a half years old) and the date in their roadmap on trac is 8 months late.

[Octo-puss]

There's probably hardly anyone left working on the project.
Whoever was the leader probably disappeared too, otherwise we'd have an official word regarding the status long time ago.

[vBm]

Word about MPC-HC was in a dire need of developers was published back in '12.
At the moment only XhmikosR and kasper93 are semi active, you know ... LIFE has happened and not everyone has spare time anymore. Official statement will be drafted and published on MPC-HC's website when the time is right and when there are news to report.

[jkauff]

Originally Posted by vBm

Word about MPC-HC was in a dire need of developers was published back in '12.
At the moment only XhmikosR and kasper93 are semi active, you know ... LIFE has happened and not everyone has spare time anymore. Official statement will be drafted and published on MPC-HC's website when the time is right and when there are news to report.

In the meantime, the nightlies are very stable and include things like the latest LAV filters. I'm not sure more features are needed at this point, and for those who do need new features there's always MPC-BE. In other words, no complaints here.

[olli66]

hi guys, can anyone help me to understand one thing reagarding the output levels (0-255 / 16-235)?
I thought I understood it but now and had everything set up correctly as far as my understanding goes but well...when I activate madvr the picture gets washed out.
I have my TV set to video levels (16-235). My Windows desktop is set to 32bit, 12bpc and YCBCr444 (which only allows a limited levels setting). MadVR is set to 16-235 so everything in the chain is set to limited (16-235), right? But when I play a video in mpc-hc with madvr ON the dark levels are way too bright and get washed out. It looks like a haze over the picture. When I leave madvr OFF the blacks are black. When I choose 0-255 in madvr the blacks are black again, the haze is gone. But what is happening now? I play a video that has limited range, my desktop is put to limited range and to my understanding the player should be set to limited range as well? Is there any level crushing/shifting happening now when I set madvr to 0-255?

[nevcairiel]

When you set everything to limited, then you get double-limited, and everything looks washed out.
Its important to know that a PC, by default, is always 0-255, hence why its also called "PC levels" in some cases. There is no way to change that, Windows just works like that, and so does practically every other application.

So when your TV expects limited levels, and you set your GPU to limited, then the GPU will compress the 0-255 desktop levels to 16-235 on output. When you set madVR to 16-235 as well, then madVR will output 16-235 by itself, and then the GPU will compress it again, and you get double-compressed.
So the short answer is, set *either* your GPU to limited, or madVR, never both - there is literally no situation where both limited would ever make sense. If you can't set your GPU to full, then set madVR to full.

[olli66]

wow, thanks for the perfect explanation!
since I have no other option than limited on my PC when I choose 4:4:4 I now set my madvr settings to 0-255
how will it work in other applications like Powerdvd and what happens to photos in general? oh by the way I just found out that I was not getting real 4:4:4 (downloaded a test pattern). I lowered the desktop bit depth from 32bit to 16bit and now I see the 4:4:4 test patterns correctly.
one other thing: movies on consoles: I have set my consoles to FULL (0-255) and my TV to FULL too. is this correct for gaming AND watching movies?
EDIT: I just tested on my PC with PC monitor: I have the desktop set to FULL and madvr set to FULL, too, no double-limiting there...
thanks again!!!

Originally Posted by nevcairiel

When you set everything to limited, then you get double-limited, and everything looks washed out.
Its important to know that a PC, by default, is always 0-255, hence why its also called "PC levels" in some cases. There is no way to change that, Windows just works like that, and so does practically every other application.

So when your TV expects limited levels, and you set your GPU to limited, then the GPU will compress the 0-255 desktop levels to 16-235 on output. When you set madVR to 16-235 as well, then madVR will output 16-235 by itself, and then the GPU will compress it again, and you get double-compressed.
So the short answer is, set *either* your GPU to limited, or madVR, never both - there is literally no situation where both limited would ever make sense. If you can't set your GPU to full, then set madVR to full.

[Asmodian]

Do not lower the desktop bit-depth to 16-bit! 4:2:2 is better than that.

[olli66]

I read that 16bit more than do for videos and pictures unless you work with HDR pictures in Photoshop/Lightroom, I don't play games on this PC and I don't edit HDR photos on this display so the question is: 16bit and 4:4:4 or 32bit and 4:2:2 ?
also I am still unclear about HDR: Once Powerdvd supports Ultra 4k blu-rays should the desktop be set to 32bit to experience HDR?

Originally Posted by Asmodian

Do not lower the desktop bit-depth to 16-bit! 4:2:2 is better than that.

[LigH]

These "16 bit per pixel" are just an average due to the YUV 4:2:2 chroma subsampling: You have one 8-bit luminance (Y) value vor every single pixel, and two 8-bit chroma difference values (U and V) for two adjacent pixels, which sums up to 32 bits per 2 pixels.

This is not at all related to 16 bit RGB desktop modes, which provide only 5 bit for red and blue, and 5 or 6 bit for green. You will see obvious banding or dithering here!

Furthermore, if you talk about HDR or High Bit Depth, it doesn't even mean 16 bits per pixel, but 16 bits per component: 16 bit red + 16 bit green + 16 bit blue = 48 bits in total. More than a monitor can display.

Conclusion: Always keep your monitor RGB mode at 32 bit.

[olli66]

I don't know why but I couldn't select 4:4:4 AND 32 bit desktop before (only 16bit) but now it is set to 4:4:4 and 32bit, should do right?
only the levels are now limited (16-235) but as long as I am only watching movies and pictures that should do, right?

[Selur]

Any chance of a new nightly build with current updated libav?
(having trouble decoding 12bit hevc 4:4:4 content, see: https://forum.doom9.org/showthread.php?t=174314)

Cu Selur

-> Okay forget that, enabling Y416 in Libav solved my issue.