MPC-HC is a superb media player but it is not surprising to see this happen. Interest in maintaining open source Windows applications written in C/Win32/C++/MFC is going to keep dropping as there are not as many people with the skills or motivation to do it. Especially for something as complex as a media player.
Even on the Linux side I have seen a drop in the number of full blown media players being developed, they are mostly front ends to things like mpv and mplayer.
It's definitely bittersweet. I have a soft spot for raw Win32 programming. On Windows, I'd rather see a program written in Win32 than in something like WPF or XAML, so it's sad that there isn't much interest in developing Win32 programs these days. This news about MPC-HC came as a shock, because I thought it was popular enough to stay around. Still, I'd rather see a cross-platform program than one that only works on Windows, and unfortunately, MPC-HC falls into the latter category.
Making front-ends to existing back-ends makes a lot of sense to me. I don't really see the advantage of writing a monolithic media player from scratch as opposed to leveraging existing back-ends.
I knew I should have clarified that I don't think it is a bad thing they are "just" front ends to mpv :)
I agree with you that there isn't much (if any) advantage to doing it all again with a new media player core. I would rather all the expertise is put into mpv to be honest and then let others build front ends that do all the extra bits.
Plus, legal streaming video/audio has become ubiquitous in the US, and Chromecast/Fire TV/Roku are far cheaper than building a Home Theater PC (or even converting an old video game console or Linux box into one).
As an aside, I got a $60 Xiaomi Mi box and love it. It has Netflix, runs Android and is a Chromecast client (you can send videos to it). It's about the same price as a Chromecast for a ton more functionality, I highly recommend it.
I haven't tried the Roku/Fire etc though, so they may be good too.
Eh, it's Android, presumably it'll still run Kodi, and, hell, if I can't get my $800 phone to be supported for two years, I'm not going to mind my $60 TV watcher.
My 2 year-old Roku is on the same OS version as my 1 month-old one. Only difference I ever notice is that the new one is a little bit faster / more responsive.
What about MPV do you see as in the spirit of MPC-HC? I'm a user of MPC-HC because of its DirectShow support and nice native UI. MPV has neither of these.
You can't use madVR with mpv.io which is a deal breaker for many (better scaling algorithms, better dithering, display calibration with 3DLUT, HDR conversion/processing and so on).
That's misleading. You can't use madVR with mpv, but that doesn't mean you can't have high quality scaling and dithering. madVR has NGU, which mpv doesn't have, and it has error-diffusion dithering, which mpv doesn't have, so if you need those, the lack of madVR support could be a deal breaker, but the difference in quality between those algorithms and the ones in mpv is fairly subjective. I feel like all the trendy super-resolution algorithms introduce too many ringing, aliasing and strange watercolour-like artefacts, so I much prefer mpv's EWA Lanczos filter, though if you want, there are a number of super-res algorithms available as mpv user-shaders, including SSimSuperRes and NNEDI3. See: https://github.com/mpv-player/mpv/wiki/User-Scripts#pixel-sh...
mpv supports display calibration and HDR conversion as well. You can load a 3DLUT for display calibration if you want, but for mpv, you would more likely load an ICC profile and have it generate the correct LUT automatically. You can even just let it pick up the ICC profile configured in the operating system. As for HDR, there are a number of built-in tone mapping algorithms: https://mpv.io/manual/master/#options-hdr-tone-mapping
I'll grant you that you can take advantage of calibration in mpv if you can generate a ICC profile containing 3dlut data, I didn't know that.
I disagree on a couple of points though. Jinc may in fact produce noticeable ringing (while NGU doesn't), and neither produce aliasing so asserting the opposite seems strange. The difference in sharpness is also quite obvious. On top of that mpv's anti-ringing filter is very basic in comparison.
HDR processing also seems quite limited and requires a lot of hand-tuning compared to madVR.
If it works for you, great, but it would be disingenuous to say that both programs are at a feature parity.
So, going through the "missing pieces" list you provided earlier, the only thing that actually holds is probably just NGU. You can insist that it's a "deal breaker" for you, fine. But attacking others being disingenuous simply because they don't agree is probably too much.
Context for others: NGU is a proprietary algorithm created by the author of madVR.
> HDR processing also seems quite limited and requires a lot of hand-tuning compared to madVR.
I'll admit I haven't watched any HDR content in mpv yet, but it supports all the standard tone-mapping algorithms (hable, reinhard, etc.) and apparently the default algorithm (mobius) was chosen for its colour accuracy.
I'm not saying madVR doesn't have its strengths. Error-diffusion dithering is strictly more accurate than what mpv does, and for people who like super-resolution upscalers, madVR tends to have a larger selection and faster implementations. Still, it would be disingenuous to say that madVR has a larger feature-set than mpv. They have different feature-sets. mpv's convolution-based upscalers are much more tunable and its colour management is more advanced, since it can use an ICC profile to auto-generate a LUT for any input gamut, rather than relying on an external CMS for this.
Now, the general consensus is that they should be changed gradually, rather than all at once. Some obviously bad keybindings have been removed this way (eg. Esc->quit.) If you create an issue for your most hated keybind, it can probably be changed.
I know I should probably raise this on the Github issue, and I'm posting this without having even looked at MPV yet to see if this is how it's already done or if there's any issues with this approach, but why not take the approach of 'profiles'? Ship with (at least) 2 profiles baked in - 'MPV legacy' and 'MPC-style'. Add more as desired. That way those who simply want to jump to a familiar system can choose MPC-style, those who want to stick with what they're familiar with from using MPV can, and the rest can customise as desired.
Any gradual changes just mean gradual changes to a keybind file. Anyone who doesn't like them can simply use their own keybind file from previous versions, or from their own modification.
Though rather than being baked in, these bindings have to be manually copied over the user's input.conf. mpv's config profiles don't extend to input.conf at the moment.
I find MPC key binding a lot better than VLC. I use skip ahead by 10 seconds a lot and using simple arrow key on MPC is very convenient compared to VLC where you need to hit a combo every time.
SMPlayer can barely even be considered an mpv front-end and I hope nobody who uses it will ever make an mpv bug report again. It's a gigantic pile of hacks from the MPlayer age, and it “interfaces” with mpv using the most horrible method possible (embedding the mpv window and sending keystrokes to it)
Perhaps from the implementation standpoint, but from the user standpoint it's second to none. For example, it's the only one I know that supports dual subtitles (--secondary-sid in mpv). For more advanced features, it also allows you to pass CLI flags to mpv, e.g. for things like `--video-stereo-mode=sbs2l` (subtitles and UI for 3D videos).
Also, enable "Run mpv in its own window" under Preferences -> Advanced. This removes all the issues caused by the default mode of embedding the mpv window (such as subtitles being on the video and not in the black bars).
Congrats on spamming HN very successfully. You've done by far the best of the spammers I've seen. But I doubt this community is likely to click those links and using is.gd isn't great for SEO, so I'm not sure what you're going for.
MPV is great but I wish the ecosystem around it was a little better (at least on Windows). There are a bunch of different GUI players but nothing definitive like a MPC-HC, VLC or PotPlayer.
The main reason I use BE instead of HC is the seekbar preview. I'm so used to it from online video players that not having it in my desktop player seems odd.
Like many forks in open-source, MPC-BE was forked off because of an internal conflict in the team. MPC-BE is made up of all the Russian developers from the former MPC-HC team after a complete breakdown in communication (i.e. drama).
MPC-HC is already so fast, I doubt that claim is even true. I just double-clocked on a video file after a cold boot, the UI shows up almost instantly, and the playback starts after around a second.
To all those asking why BE? It really has NOTHING to do with speed. To simply put, BE was well maintained and continuous bug fixing. From my perspective HC has seen the writing on the wall ever since BE forked.
Not only does it look better, it plays files better then HC by default. Not sure HC has improved since then, back in the day BE would handle AVI, rmvb, WMV, much better without the need of fiddling around with settings and filters.
The writing for MPC-HC was on the wall a lot longer than when MPC-BE was forked. There's no future for a player that's not cross-platform, case-in-point:
> MPC-BE is the only thing I really miss on Mac.
And HC definitely improved after BE was forked. While BE chose to keep maintaining their own decoding filters the HC team chose to completely switch to an internal build of LAV Filters. MPC-HC also had a lot of performance improvements to the internal subtitle renderer.
MPC-BE regularly backported these improvements though, so the fact that MPC-HC died also affects MPC-BE.
MPC-HC was always my go-to. Starts up instantly and the performance was always superb, much better than VLC in seeking. I don't know what it is, but more often than not, VLC pauses for a moment when seeking to a random part of the file, while MPC-HC has always been instant.
Fortunately, I believe MPC-HC will still likely be updated if necessary, or forked and updated if need be. I know I haven't updated mine in years and haven't had any problems.
I wonder if this is still a problem (I haven't used VLC in a while.) That message box is shown when fontconfig rebuilds its font cache, but libass has been able to run without fontconfig since 0.13.0 (October 2015.) I guess it depends on whether the current release version of VLC still needs it.
With some malformed files I have notice that VLC has a tendency to handle it when mplayer did not, so I always assumed that the delay in VLC is to more complex seeking that sacrifice performance for robustness.
I haven't used MPV enough to see if this case is still true.
Damn. I remember all the debates on /a/ (4chan anime board) on what are the best options and presets... for watching anime. Looking back it was kind of silly but we were able to do that because the player was so well built.
In case anyone's seeing this using SVP3 and had no idea that 4 had released, 4 is well worth paying for, it is far less hardware intensive (SVP3 would choke getting high bitrate 1080p videos to 60fps, SVP4 handles the same files like a dream - anecdotal but better than nothing), the interface of the main application has been... improved (kinda subjective, but it's definitely more idiot proof) and it even supports VLC now if you swing that way.
It reimplements mpc-hc UX using qt for the UI and libmpv for the heavy lifting. The issue with this one is that it doesn't have public builds yet, but it has been in active development for years.
> K-Lite contains a custom build of MPC-HC that contains additional fixes and improvements compared to the officials builds. This will continue in the future. The internal codecs that MPC-HC uses are also still actively maintained.
Very unfortunate, MPC-HC was so simple to use, has a slick UI inspired by MS Media Player and to quickly review/seek videos it was the very best. (much faster than VLC for that task)
I really want to use mpdn because it uses WMF but I haven't gotten results with it like I have using MPC-HC and madvr. Anybody know any other program that's as advance as mpc, compatible with madvr and uses Windows media foundation over directshow?
An excellent player with a ton of great features. However I'm not sure if it ever caught up to VLC in terms of performance. Specifically it was around 10x slower at seeking in H.264 video compared to VLC. When used on low performance machine (Pentium 4 @ 3 GHz + 7200 rpm HDD), this resulted in a sub-second seek time in VLC compared to over 5 seconds in MPC-HC when viewing 10Mbit bitrate video. Especially annoying when I wanted to rewatch a single moment over and over again.
I doubt it. Mpc according to many on doom9 and other video player forums in combination with madvr filters provided objectively better quality frames. They post side by side comparison pictures in high resolution and mpc comes out as a better choice if you care about picture quality. Also about performance I don't think mpc is as bloated as vlc is and recall many having complaints of vlc using a lot of ram and cpu whereas mpc seems pretty lightweight. I can't stress enough how much vlc is losing out on not having madvr equivalent add on type to enhance picture quality though, the hardware utilization to push out the perfect pixel is nuts, not to mention built in smooth motion
MPC-HC is just a DirectShow frontend, or at least, that's how I used it. Filters do most of the work.
And no one seems to care about DirectShow anymore but that's mostly because everything works fine.
It will die eventually, because Microsoft is trying hard to kill DirectShow (to replace it with something inferior...) and the opensource guys mostly go to mplayer, but for now, updates are not really necessary.
Calling MPC-HC just a DirectShow frontend is almost as inaccurate as saying mplayer is just a UNIX frontend.
Just as mplayer is using POSIX APIs, MPC-HC is using the DirectShow API to run its filter graphs, but it actually provides a lot of internal decoders and filters (mostly based on ffmpeg/libavcodec), and if memory serves me right it even has its own renderer, and pretty much customizes its graph building, so you don't get a default DirectShow graph.
To be honest, the DirectShow code provided by Microsoft usually ends up providing very little besides the Renderer (unless you're using an external renderer like madVR or Haali) and the glue code.
Media Foundation ain’t that bad. I coded some moderately advanced stuff with it, custom stream sources, custom transforms — it was fun, and it run well.
I can see how it was inferior back in 2007. The first version of MF was shipped with Vista, and Vista… Let’s just say many people were disappointed with it. Nowadays however, when you only need to support Windows 7+, MF is fine.
I really like PotPlayer. mpv is great but requires a bit of tinkering, whereas PP comes with some ready to go defaults and as much flexibility as MPC-HC.
EDIT: I just realized you said "Isn't MPC-HC for Windows, and Brew for macOS?" which threw me off.
I am currently on Windows and use MPV, I don't see why it should be exclusive in any way.
The dotfiles are compatible, and same goes for lua scripts. So there's no trade off at all that I've found. And it's nice to be able to just clone my dotfiles and have it work in OS X, and same for Windows.
I agree. MPV is very customisable, and it's great to have a video player that works just how you want it, regardless of the system you're using.
EDIT: Yeah, I was just pointing out the fact that, if you're using MPC-HC, then you're probably using Windows. In which case, whilst MPV is a good alternative, you wouldn't be installing it with (Home)brew, which is a package manager for macOS.
If you don't mind sending telemetry data to their HQ in Korea then sure it's a nice media player.
Article 5 (Collection and Use of Data and Other Information)
(1) Daum may collect and use data from the computer of Users as a part of its product support services that are provided to Users in connection with the Software. Data that may be collected solely include the type of computer and type of operating system used on the computer, memory capacity, type of graphic card, Directx version, media player version, type of webcam and TV reception card.
(2) Daum will use the above collected data only for the purpose of improving the Software or providing service or technology that is suitable to the user environment of the User and will not use such data for any other purposes.
Well, nuts. I really liked MPC-HC as part of the CCCP. I'll check out some of the alternatives offered in this thread. Hopefully one follows the slim design and flexibility of MPC.
I don't think it really matters what the acronym means. It's a project name, like VLC (which is VideoLAN Client, to save you the trip ;) ) and its known BY the acronym.
Even on the Linux side I have seen a drop in the number of full blown media players being developed, they are mostly front ends to things like mpv and mplayer.