Media Player Classic - BE Win32/x64

[huhn]

windowed fullscreen is usually used in that case.

[hajj_3]

Is there any way for Task Manager to show the application name as "MPC-BE" instead of the filename of the video you are playing as shown in this screenshot:

https://i.ibb.co/JjynF1gZ/task-manager.png

[StainlessS]

Is there any way for Task Manager to show the application ...
Would seem to make more sense, perhaps with filename appended with some separator between.

[v0lt]

Is there any way for Task Manager to show the application name as "MPC-BE" instead of the filename of the video you are playing as shown in this screenshot:
This looks like a Windows 11 bug. Use Windows 10. :p

[hajj_3]

This looks like a Windows 11 bug. Use Windows 10. :p

Here are my settings (mpc-be64-settings.reg) for you to try and replicate it: https://turbobit.net/0004brlrcdqj.html

At the moment it currently shows as MPC-BE x64 in task manager but earlier it didn't as shown in the screenshot above.

[huhn]

does not seems to be default:
https://i.ibb.co/Swrfw9Cg/image.png

but there is something wrong going on anyway there is no way to be running this with 47 mb ram use...

[varekai]

@varekai, Aleksoid1978
Ask the author of PotPlayer to support top-down RGB bitmaps.

I did ask the author for this and today new version released PotPlayer 1.7.22769 [26-01-14].
Pause PotPlayer now supports AVC screendump.
PotPlayer pausing AVC
https://i.imgur.com/QhJLalO.png

Also, thank you very very much for MPC Video Renderer, you have no idea how liberating it is to not have to use cumbersome madVR.

Best regards,
varekai

[Amuat]

How weird is it that I finally got 23.976 working by having both Wait VBlank and Adjust the frame on at the same time? I'm using the MPC-HC automatic full screen modes and also have VSync forced on in NVidia CP (stutters like hell without it regardless of other settings). Even this combination didn't work with 806; like other solutions tried, it worked for a very short while, then started stuttering after some 300+ frames in. Eventually it got to the point where the TV started to lose connection every time when going full screen with 23.976 videos and I just had to give up and relegate them back to 24 fps mode. But with my new 810, the aforementioned solution seems to work perfectly...

[kirakami]

Nvidia has broken something so badly that 23.976 fps videos don't play properly on any player if you have g-sync monitor. All 23.976 fps videos cause micro-stutters and panning shot judders and if you enable 1% lows in nvidia overlay, you can see the 1% lows fluctuating around 19-21 fps. The only workaround is to enable motion interpolation like nvidia smooth motion or hopperrender which fixes micro-stutters and panning shot judders but has its own set of issues since it is interpolating frames which inevitably cause scene-change artifacts or image distortion in videos. 29.97 fps and 60 fps videos don't cause micro-stutters but can still cause panning shot judders.

[clsid]

VSync MUST be enabled in the player profile, and GSync MUST be disabled in the player profile. VRR is not supported.

Windows tweak: (https://www.reddit.com/r/Windows11/comments/1kgp7ar/cause_and_solution_to_windows_24h2_related/)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
"OverlayMinFPS"=dword:00000000

[KrazyLurt]

Is Mpc-Hc / Be with madVR 0.92.17 / Test Build 208 able to use dynamic metadata for DV profiles? Or is (the horrible UX and UI), Energy Media Player the only real alternative for that? That would be a shame because mpv, Mpc-Hc / Be is such great players overall.

[clsid]

madVR does not support DV. You need to use MPCVR for DV (which converts it into HDR).

[KrazyLurt]

madVR does not support DV. You need to use MPCVR for DV (which converts it into HDR).
Thanks buddy, yeah long time user of MPC VR, it's awesome, just wondered if there where another option for using the dynamic metadata of DV. I assume converting to HDR exclude the dynamic metadata similar to mpv that converts DV to HDR10.

[clsid]

Both support dynamic metadata.

[KrazyLurt]

Both support dynamic metadata.
Thanks! Maybe I used the incorrect terminology and should have wrote the DV RPU. Because for example this test file
Dolby Vision Lake Dynamic Changes Test (Profile 8.1) 23.976fps
https://drive.google.com/file/d/1-8C0ZYnIhEqOVJQ532hIJobP5XR6A7gj/view
results in visual differences in contrast, saturation and such with Energy Media Player. It does not with mpv or MPC-HC with MPCVR.

[Amuat]

Damn you kirakami, you jinxed it! No but seriously, worked for several days, then just suddenly... didn't (I have never used GSync btw, only VSync). But yeah, you are probably right, I did start to see some minor artifacts even before it completely broke down, so it wasn't "working perfectly" after all, even for that very brief period. Kind of a shame (to put it mildly) if it's really the case that NVidia or Windows or whatever has some inherent problem with 23.976, as it's the standard frame rate for films.

[huhn]

if a dev still cares i got VVR working now. i need to test it a display that does vrr correctly not the TV but it's working.

i just had to quad the frame rate to 96 so it doesn't fail around with LFC.
the problem is the media player and the low frame rate.
so i forced deint on lavfilter and added ffdshow and forced deint there too (avisynth didn't work and should have been a more graceful solution) so i get 96.
after that i disabled all swap effects and it is already working decently.
the last and most important step was using a reshacked version of mpc-hc to trick the GPU driver into not using the mpc-hc nvidia profile.

rtss can be used to smoothing the frame times.

[SeeMoreDigital]

It recently came to my attention that there's a lossy version of DTS:X aka: DTS:X UHD Profile-2.

Needless to say, the video plays fine in MPC-BE 1.8.9 [git 2025-12-30 - d888b6672] but the audio does not.

Link to sample muxed within the .mp4 container: https://mega.nz/file/GOBTHIwK#Vrrwuj_i-K86Gk6CPtm9aC8iYXHn6Y8Gvqp1QkYywao

[v0lt]

It recently came to my attention that there's a lossy version of DTS:X aka: DTS:X UHD Profile-2.

Needless to say, the video plays fine in MPC-BE 1.8.9 [git 2025-12-30 - d888b6672] but the audio does not.

Link to sample muxed within the .mp4 container: https://mega.nz/file/GOBTHIwK#Vrrwuj_i-K86Gk6CPtm9aC8iYXHn6Y8Gvqp1QkYywao
The latest ffplay.exe does not recognize the audio codec in your file.

[hajj_3]

I was wondering what your thoughts are about possibly integrated Symphonia in the future? https://github.com/pdeljanov/Symphonia

It is a rust-based audio decoding library like ffmpeg

[lvqcl]

I was wondering
But why?

[v0lt]

I was wondering what your thoughts are about possibly integrated Symphonia in the future? https://github.com/pdeljanov/Symphonia
You can write your own DirectShow source filter for audio files. Just one more. And use it in any DirectShow player.

[Sunspark]

The rust frenzy is too ideological for me right now.

But that aside, nobody is beating ffmpeg. Their headstart is years-long and they're getting patches from giants like tencent now.

[huhn]

it either has AC3 nor dts listed.
it is so far behind it can not be used to playback a dvd...

not even aac is glitch free and the source for that is there github page...

then it has benchmarks with codec it supposedly can not even decode correctly...

just why?

[SeeMoreDigital]

The latest ffplay.exe does not recognize the audio codec in your file.
Thanks for confirming the reason for the issue...

[s0meone_new]

Hungarian translation updated:
https://limewire.com/d/zDQRh#F981INe2kI

[huhn]

is it possible to look into the dvd soft telecine frame time issue.
these very common 23p dvd can have frametimes for video which will results in massive judder. with deint forced it may not care about the repeat flags (which is actually preferable under many situations).

is it maybe possible that a 23p stream with repeat flags is retimed to 23p for proper playback?
a dvd stream with mpeg2 23p and repeat flags should always be save to assume that it is real 23p as long as the repeat flags are present switching to 29i is BTW. possible at any moment.

[Amuat]

So if I understood correctly from a previous conversation, there seems to be pretty much a consensus that in most cases (where applicable) it's a good idea to always output 10-bit through GPU, but I'm still unsure if I should use auto 8/10 or also always 10 as texture format, and if not the latter, why exactly?

[huhn]

16 float.
how and where this is sued in mpcVR is not known to me but to do stuff really mathematically accurate you need at least that.

it's for better dithering accumulated errors from scaling, ycbcr -> rgb conversation and such stuff. don't expect much even with 10 bit it doesn't show the typical 10 bit banding so i doubt setting this to 8 actually make it use 8 but everywhere there is no measurable difference between 10 and 16 anyway so just use it.

10 bit output would generally be better then 8 bit assuming a perfect end device. end devices are not perfect at all they are far far from it.

[Amuat]

Thank you for your input. I think it was clsid who advised against it to minimize errors. So if clsid also cares to contribute, why do you two see this differently?


10 bit output would generally be better then 8 bit assuming a perfect end device. end devices are not perfect at all they are far far from it.

So are you saying that even the latest high-end devices are not for the most part particularly well suited for 10-bit output, or are you thinking on a much wider scale of devices old and new, budget and high-end?

[clsid]

It should be set to "auto 8/10".

Forcing 16bit will break/disable certain stuff, but you guys are stubborn anyway, so go ahead and shoot yourself in the foot. Or for those who think just because when number A is bigger than number B, then A must be better, shoot yourself in both feet.

It would be better if this option was removed, or ignored when using VP and limited to 100% shader processing.

[Sunspark]

Good test.
My result:
EVR - bad
EVR-CP -good(if use 16-bit float surface), bad if 8
madVR(bicubic60) - good
MPC VR DX9 -good(if use 16-bit float surface), bad if 8
MPC VR DX11 - good.

P.S. Verdict - EVR-CP/MPC VR DX9 with 16-bit float surface and MPC VR DX11 is the same quality as madVR bicubic60. So - we don't need to process chromium ourselves, DXVA2/D3D11 Video processor do it not bad :)

It's strange, because Aleksoid in that post at https://forum.doom9.org/showthread.php?p=1877825 found that there were cases with the test done at that time where 16 was better..

[huhn]

with VP on the error has been done by limited 10 bit VP out. yes.

that doesn't change that float 16 dithered to output bit deep is better.

btw. mpcVR has banding issue on window mode when the GPU is send 10 bit because it is send 10 bit in window mode which is been buggy with nvidia forever.

bigger is not always better.
It's strange, because Aleksoid in that post at https://forum.doom9.org/showthread.php?p=1877825 found that there were cases with the test done at that time where 16 was better..

yes i also see it like that but why doesn't dx11 need 16 where dx9 needs it. it is ignoring it and uses it or something? disabling dithering also doesn't do anything in DX11 mode in DX9 it does...

displaying a 16 bit gradation test with 10 bit buffer that isn't dithered is impossible it's 1023 visible steps simple math.

Thank you for your input. I think it was clsid who advised against it to minimize errors. So if clsid also cares to contribute, why do you two see this differently?
and he is correct it minimizes error.

So are you saying that even the latest high-end devices are not for the most part particularly well suited for 10-bit output, or are you thinking on a much wider scale of devices old and new, budget and high-end?
yes even newer TV are very very flawed.
you have to test this

[Klaus1189]

Out of curiosity. Can you help this guy?
https://forum.videohelp.com/threads/420128-Unknown-AVI-codec-pyv5-need-help

I have never seen a file like that, but maybe you can analyze this kind of file.
https://cloud.mail.ru/public/zXvg/QeNHM847E

[v0lt]

Out of curiosity. Can you help this guy?
https://forum.videohelp.com/threads/420128-Unknown-AVI-codec-pyv5-need-help

I have never seen a file like that, but maybe you can analyze this kind of file.
https://cloud.mail.ru/public/zXvg/QeNHM847E
Use ffmpeg.exe or ffplay.exe. If this doesn't work for you (it didn't work for me), contact the developer of that codec.

[Aleksoid1978]

Someone asked about HDR Tonemap. You can try it for testing as a post-resize shader with the test build I posted, which has the SetHDRMetaData() call removed.
In the shader, set maxDisplayNits to whatever the display can handle, and maxContentNits to the "Maximum Content Light Level" value from the video; if there isn't one, set it to 1000.0.
https://github.com/user-attachments/files/25590595/MpcVideoRenderer-0.9.20.2505_git2026.02.26-84ce3d7.zip
https://github.com/user-attachments/files/25617836/ToneMap.zip

[huhn]

HDR -> HDR tone mapping "works"

[clsid]

I still think the dynamic tonemapping (HDR passthrough with reduced MaxCLL) would be a good addition to renderer options. For the many monitors with bad internal tonemapping ability.
Could be just a simple dropdown option, something like: HDR output peak nits = Original/600/500/400/300/200

When the renderer does it, SetHDRMetaData() could be adjusted with the modified MaxCLL.

So if you do change your mind one day, here is a fork from which some code could possibly be re-used:
https://github.com/thefallentree/mpc-VideoRenderer/pull/1

That one also gives a choice between a few different tonemapping algorithms. Perhaps that would also be a nice addition?

[Sunspark]

Wait for V-Blank before Present
The renderer will wait for a V-Blank event before calling Present. This allows for more accurate frame output timing. This allows the SyncOffset graph to more accurately reflect frame output jitter.
This setting may affect video smoothness. Disabled by default to avoid annoying users with a sawtooth graph.

Adjust the frame presentation time
The renderer will wait additionally before displaying a frame to more accurately hit the required display refresh time. This setting helps smoothly play interlaced video with double the frame rate (50/60 fps) on displays with a high refresh rate (120 Hz and higher).

Wondering if Wait for V-Blank is intended to be used with a specific presentation path? E.g. Exclusive mode vs windowed mode which uses the DWM compositor, and also D3D9 vs D3D11 for both modes?

[Aleksoid1978]

I still think the dynamic tonemapping (HDR passthrough with reduced MaxCLL) would be a good addition to renderer options. For the many monitors with bad internal tonemapping ability.
Could be just a simple dropdown option, something like: HDR output peak nits = Original/600/500/400/300/200

When the renderer does it, SetHDRMetaData() could be adjusted with the modified MaxCLL.

So if you do change your mind one day, here is a fork from which some code could possibly be re-used:
https://github.com/thefallentree/mpc-VideoRenderer/pull/1

That one also gives a choice between a few different tonemapping algorithms. Perhaps that would also be a nice addition?

Who needs this, and in what situations? More information would be great, as would tests, preferably with comparison screenshots.
I posted a build and shader above, just for testing. The result: only one user responded, and even then, they just said it "worked."

[clsid]

It is not something you can easily capture in screenshot, would need actual photos.
But dynamic tonemapping is what most madVR users use. But of course that has more advanced tonemapping options.

At least the ability to choose tonemapping algorithm seems easy to copy, and that is not directly related to dynamic tonemapping ability.

[huhn]

Who needs this, and in what situations? More information would be great, as would tests, preferably with comparison screenshots.
I posted a build and shader above, just for testing. The result: only one user responded, and even then, they just said it "worked."

sorry i do not use a system that needs it. so all i had to add was there is nothing it does wrong what so ever it was rolling off highlights as i excepted it would do. and there are quite a number of cheaper screens that really really really need that...

you can look up the issues with Nintendos new "console" and there HDR "calibration" issue and setup to do something similar for the games.

[DailyLama72]

I switched from mpc HC to mpc be.
Much better with audio, subtitles etc

I used the mpc video renderer and I use an sdr projector.
First everything looked fine. Then I noticed that some hdr movies look very dark.
I played with the nits config. One movie needs 50 nits, the next 100, one even 200 nits.
Since I don't want to change settings for every hdr movies I changed to madvr.
I have no problem with madvr hdr to sdr in mpc HC.
But in mpc be I have very often a brightness change. It's unwatchable.
Since it works fine in mpc HC it seems it can't be the madvr settings.
What can cause these brightness changes in mpc be when using madvr to play hdr to sdr? What behaves different than mpc HC?

Another strange thing: mpc HC correctly using the downscaling settings of madvr. But mpc be using the upscale settings for the same movie, first downscaling 4k to 0x0, then upscale to full hd. Abd yes, it's using the same madvr settings as I see in realtime which profile group in madvr it uses.

[Aleksoid1978]

Test version with HDR Tone map - https://disk.yandex.ru/d/1ID4GrXutRO7NA

[huhn]

is it possible that for "passthrough" the nits can be unlocked which run the ToneMap.hlsl but still darker so user can use that to roll of this is not one of the. reinhard seems similar but not the same.

reinhard, mobios and hable remind me of hdr SDR settings for mpv.
mobios doesn't seem to be build for that?

[Amuat]

and he is correct it minimizes error.

Not the case that "I need proof or I'm gonna use 16 FP" (which I didn't use to begin with), but still very curious what are some typical errors introduced?


Another thing: there has been quite a lot of talk of FSE not truly being FSE in Win 11, but nevertheless I decided to experiment with it inspired by huhn's comment of 10-bit output being buggy in windowed with NVidia. Seems generally somewhat smoother (and yes, I do have full screen optimizations disabled in the exe), but what's more, this has been clearly the longest run of 23.976 actually working with 23 Hz instead of having to use 24, hope it lasts. Only downside I've noticed thus far is that you have to always go full screen twice as the mouse pointer sticks on with first try, but this is a very minor annoyance.

[huhn]

Not the case that "I need proof or I'm gonna use 16 FP" (which I didn't use to begin with), but still very curious what are some typical errors introduced?


Another thing: there has been quite a lot of talk of FSE not truly being FSE in Win 11, but nevertheless I decided to experiment with it inspired by huhn's comment of 10-bit output being buggy in windowed with NVidia. Seems generally somewhat smoother (and yes, I do have full screen optimizations disabled in the exe), but what's more, this has been clearly the longest run of 23.976 actually working with 23 Hz instead of having to use 24, hope it lasts. Only downside I've noticed thus far is that you have to always go full screen twice as the mouse pointer sticks on with first try, but this is a very minor annoyance.

i can take a cemara out and show the issue.
i have a very very cheap smart phone somewhere around.

we had just "fun" with ffv1 you can test it with this: https://drive.google.com/file/d/1RaA9h1Lfpa-6i_V8rs9qYBxT1W5DYu-n/view not my file. this is 16 bit a similar result would happen if you would apply a deband filter if it isn't been applied in 16 bit and then dithered it will not do a proper job and still bands the same type of banding you get if you don't dither. with mpcVR in dx9 you can test all of this very precisely. with DX11 something happen that shouldn't you will not get banding with 10 so something forces it to dither before it is written int eh first 10 bit int buffer you can not truncate a gradient without adding banding.

there is no real point to FP32 except it could be faster cause the GPU does math in FP32 anyway (FP16 needs special code and will not perform well on old cards.) and can just store the results not needing to do truncation conversation, bit shifting or anything for the cost of Vram and memory bandwidth.

you can also test this in madVR if you want madVR can be limited to 10 bit in the trade performance options really not recommended and everything in madVR works anyway with the normal bit deep with no risk at all.

with FSE you can not show the player controls which will trigger the issue fake or real does not matter here. real FSE will not allow overlays the fake FSE will be affectted by steam overlay nvidia over amd overlay and so on beating the point of been exclusive but i'm sure you can see why they did that change.

[Sunspark]

It's kind of fascinating how challenging a field video rendering really is. Lots of papercuts.

[clsid]

Test version with HDR Tone map - https://disk.yandex.ru/d/1ID4GrXutRO7NA
There are clear differences between the algos, so feels like a good customization option for users to play with.
Any reason why the nits value isn't an integer in the option GUI?

What is the SetHDRMetaData behavior in this test build?

Bug? The OSD sometimes shows 0 as (second) nits value. Also after switching back to passthrough.

[clsid]

Can you split the tonemap algorithm choice into a separate dropdown and also use that algo for HDR->SDR?

HDR10: disabled/passthrough/local tonemap/ignore [...] Nits
Tonemapping: ACES/Reinhard/etc