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.
