No. But there is the OSC (on-screen-controller), which lets you control playback with the mouse. Requires mpv to be compiled with Lua support.
There are some 3rd party GUI frontends listed here.
Tearing is a very annoying artifact that makes it look like the video has a horizontal line across the video. The video isn’t properly joining on that line. The line can be fixed or moving. Sometimes it’s not a line, but a bunch of blocks. It can be unnoticeable if there is no movement, but very apparent if the camera moves e.g. at low speed.
Tearing is generally not something a video player can do anything about. It depends on the hardware, drivers, the video output selected in mpv (VO), and possibly the desktop environment / compositor.
Changing the compositor settings can sometimes help with tearing.
Never seen it tearing.
Whether tearing happens with OpenGL may depend on the backend and how it interacts with the GPU and the compositor via the swap chain. Try with playing the --angle- options, which configure the d3d swapchain. You can also try various with --opengl-backend=NAME, where NAME is the name of the backend. dxinterop seems to perform best generally, but it will crash randomly with some older buggy Intel drivers. The deprecated --vo=direct3d should roughly behave like --angle-renderer=d3d9.
Nvidia should generally not tear. Sometimes, it tears in windowed mode, but not in fullscreen (solution unknown). There are additional problems on multimonitor systems.
- Try enabling
ForceFullCompositionPipeline. - Try with and without a compositor.
-
Try disabling the composite extension in xorg.conf:
Section "Extensions" Option "Composite" "Disable" EndSection - Set the performance mode to maximum performance. Energy saving often interferes with proper vo_opengl operation, and sometimes even appears to cause tearing.
Try
--vo=vdpau.-
To fix tearing under KDE, create file
/etc/profile.d/kwin.shwith content:export __GL_SYNC_TO_VBLANK=1 export __GL_YIELD=USLEEP
If your Xorg-server is older than ABI version 23, or your kernel is older than version 4.5, or your nvidia driver is not up to date, then you will inevitably get tearing due to the lack of PRIME buffer synchronisation. You cannot fix this tearing with any of the other methods described on this page. Assume fetal position and cry, or switch to using your Intel GPU instead.
Intel tears out of the box. However, most of the time, tearing with the gpu vo (the default) can be fixed by enabling a compositor. If this doesn't apply to you, try the following options.
-
Try enabling SNA and the
Unfortunately, this can cause stability issues - GL applications sometimes randomly crash. Somewhere, there’s a claim that addingTearFreeoption.i915.semaphores=1to your kernel parameters fixes the crashes. - Try disabling SNA by using UXA (on older hardware).
- Try
--x11-bypass-compositor=no - Try
--vo=xv --xv-adaptor=N, and try 0 or 1 forN. This may fix tearing if the other methods fail, but keep in mind that using Xv with mpv is strongly discouraged. Try
--vo=vaapi. Although this is Intel’s native video output method, it seems to fix tearing only very rarely. Do keep in mind though that thevaapivo does not provide the high quality rendering that thegpuvo is capable ofTry
--vo=sdl. This will likely use your 2d acceleration, which means that this won't fix tearing if you experience tearing with any of the non-gpuVOs. As withvo=vaapi, it doesn't offer the features thatgpuoffers.- If you are using Xorg's new "modesetting" driver and are not using a compositing window manager (for example, you are using a plain window manager such as Awesome without a desktop manager like Gnome or KDE), you might need to run a compositor during video play-back. Compton might solve the issue if started with its glx backend:
- Install Compton from a package manager or compile from source
- Start Compton in a terminal as follows:
compton --backend=glx - Start mpv
- The official drivers (AMDGPU-PRO/fglrx) are completely broken; so just avoid them altogether.
- With amdgpu, you need to enable the TearFree option (either via
xrandr --set TearFree onor via xorg.conf) to prevent tearing when not in fullscreen, unless you are using a compositor. - If you still get tearing in fullscreen mode when using vulkan, add `option "EnablePageFlip" "off"` to the `Device` section of your `xorg.conf`.
- Unrelated, but if you have performance issues, try
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level.
Since mpv normally renders video with shaders rather than fixed function video hardware (it does that for the sake of quality and consistency), the GPU hardware and the quality of its drivers is very important for mpv to function well.
We're only portraying the situation on Linux. The author doesn't know the situation on Windows. Apple is completely incompetent and evil in the graphics area, please don't buy their products.
These seem to work pretty well. There are some consistent issues, but there is hope. Their discrete GPUs are usually powerful enough to handle even advanced render settings at high resolutions and frame rates.
Unknown. Might work well, but may cause additional problems in theory. Since open source amdgpu drivers work pretty well (and supposedly better than amdgpu-pro in some cases), it's possible that they only provide an additional source of problems.
In any case, you can switch to amdgpu drivers without losing much.
Their hardware is relatively weak, and their drivers are chaotic. If you manage to pick the right driver versions, things will probably work very well up to medium settings. However, there are frequent problems (some of them seemingly never being fixed), and it is known that driver release versions have bugs not present in git. Also, they always start new drivers instead of improving what they have, which will make your life as Intel user stressful.
Not recommended. However, if your PC is a laptop, you should probably prefer pure Intel over hybrid graphics, at least at this time.
No. Their hardware may be pretty good, but their drivers are problematic. They are closed source and tend to replace system libraries at installation. In addition, they tend to be behind the open source APIs (for example, there is still no presentation feedback at all in their GL implementation). Nvidia drivers also seem to cause frequent system stability problems. There are weird quirks like huge user-noticeable timeouts at initialization, which shouldn't exist at all.
While Nvidia used to be recommended in the past (at least by the author), it keeps getting worse.
Why would you buy a device that was designed to spy on you for the purpose of making megacorps even richer? That's kind of stupid, you know.
Anyway, all mobile GPUs are bad, both in the hardware implementation, drivers, and the fact that mobile devices are not very powerful, unless you're fine with them draining your battery in minutes.
There are many "embedded" or "mini computer" boards with powerful ARM chips. Consumers usually run Linux on them. They are all trash in all aspects.
Although mpv has some support for RPI and Rockchip devices, which may or may not work well for you.
I am using NVIDIA G-Sync on Windows and running mpv in fullscreen mode reduces the frame rate of other displays
This is likely caused by the way G-Sync interacts with Windows’ compositor. Using --opengl-backend=win should fix this because mpv gets an exclusive fullscreen window that way. The compositor unredirects exclusive fullscreen windows and is not forced to run at their frame rate.
The OSC requires Lua support. Install either one of Lua 5.1, 5.2 or LuaJIT, including development headers, and rebuild mpv. mpv does not and is unlikely to ever support Lua 5.3.
If you didn’t build mpv yourself, ask the packager to enable Lua.
Also note that the OSC is invisible by default, but it should appear once you move the mouse over the mpv window.
Use --force-window.
GNOME is most likely the most popular desktop environment on linux, and it defaults to Wayland on most distributions. This is unfortunate because there are many GNOME Wayland-specific issues with mpv that users mistake for being mpv or wayland bugs when in fact it's a GNOME problem. Until these are issues are fixed upstream, GNOME mpv users should specifically use the Xorg session or another Wayland compositor if they want a bug-free experience. Below is a short list of known issues.
- GNOME wayland is known to potentially have random vsync spikes and mistimed frames. This happens in both wayland and xwayland and only in GNOME. Until at least this is fixed, we can't even begin to consider recommending GNOME wayland.
- GNOME wayland has no server side decorations because they do deliberately do not support the xdg-decoration protocol which is a proper upstream protocol. Users can use
--gpu-context=x11eglor--gpu-context=x11to get decorations on GNOME wayland or use another compositor that supports xdg-decoration. - GNOME wayland does not support the zwp idle inhibit manager protocol. This means that screen blanking will occur during video playblack depending on the user's settings. A workaround is to use launch mpv with the gnome-specific
gnome-session-inhibit.
In short if you use GNOME Wayland and encounter an issue, please double check that it is actually an mpv issue before reporting it. A good rule of thumb is to check if it also occurs in both a wlroots-based compositor (i.e. sway) and weston. If so, it is probably our bug, but if not, GNOME is likely to blame.
Clearly they are, see previous FAQ entry. They consider their "desktop" to be a separate platform (they consider non-GNOME desktops like KDE on the same level as win32 and OSX). It's unknown why GNOME puts lots of effort into ensuring a very basic level of compatibility (like using Wayland instead of their own protocol), but stubbornly refuse to implement other very simple standard mechanisms that help with integration (like the window decoration or idle inhibit protocols).
On the other hand, the methods they provide for integrating with GNOME are technically bad and unacceptable, such as depending on GTK and giving it control over your window just to render CSDs, or needing dbus for disabling the screensaver during playback.
Is GNOME's apparent behavior stupid or evil? You decide. The end result is that the "Linux Desktop" remains a dumb shit show. Writing software only for win32 or OSX is a much nicer experience, thus bad consequences for Linux.
Apparently, some screensavers do not use standard APIs, and require weird mechanisms in ALL software that needs to inhibit the screensaver. I guess their thinking was, "there is a very popular way to inhibit the screensaver that we interoperate with well, so let's go out of our way to put a stop to that." These do not sound to me like people whose software you should trust on your computer.
See for example: https://www.jwz.org/xscreensaver/faq.html#dvd
Joke (?) aside, if you need to run xscreensaver-command (for XScreenSaver) or xdg-screensaver (for GNOME?), you can write a Lua script to do so. Also see: https://mpv.io/manual/master/#disabling-screensaver
Only consider using Wayland with mpv if you pass the following criteria.
- You don't use a NVIDIA graphics card. No GBM means no real wayland support (EGLStreams doesn't count).
- You don't use GNOME (see the above section).
- You (probably) need to be on at least EGL 1.5. Users on EGL 1.4 have had several reports of performance issues and mistimed frames/jitter spikes. It isn't 100% certain that this is the cause, but it's probably safer to just use X11 if your hardware is EGL 1.4. If you really need Wayland, you can give
--vo=wlshma try although it will have worse quality.
If you pass all of that, then Wayland should perform just as well as X11 and you can pick whatever you like better. mpv does its best to be independent of specific desktop environments and compositors, so we only support upstream wayland-protocols and not other desktop specific libraries or compositor specific protocols. Certain wayland compositors only support certain wayland-protocols, so they may not have every feature the mpv wayland backend supports. Here's a quick list of some notable protocols mpv uses and what compositors support what.
- xdg-decoration (used for server side decorations): Plasma and Sway/wlroots
- idle-inhibit (used for preventing screen blanking): Plasma and Sway/wlroots
- presentation-time (used for presentation feedback): Sway/wlroots and Weston
The VO (video output) using GPU shader based rendering was renamed and updated a few times. Currently, the following things hold true:
- --vo=gpu is essentially the default (replaces --vo=opengl)
- --profile=gpu-hq is for selecting a preset with advanced scaling and so on (replaces --vo=opengl-hq and --profile=opengl-hq)
- GPU supports multiple backends, like d3d, opengl, vulkan (they are used by default in that order); use --gpu-api=vulkan to force e.g. vulkan, use --gpu-context=... to select specific backends.
- use --hwdec=auto or --hwdec=auto-copy instead of anything else
- make sure all hwdec backends are compiled in
- make sure the file you're playing can be hardware decoded at all (this is for example not the case with 10 bit h264 video)
- some codecs need to be explicitly enabled with --hwdec-codecs
First off: DO NOT USE THESE VOs. They are broken and old. There is no reason to use them. Just don't override the VO selection and use the default. Some users seem to think using these VOs is required for hardware decoding. This is not true. If you want hardware decoding, use --hwdec=auto, which may use some of these APIs for decoding. (On older Nvidia drivers, you may need --gpu-context=x11 in addition.)
These VOs use rather old video output APIs, which have been mostly abandoned by their vendors. In particular, vaapi is known to be thoroughly broken in most Intel drivers. It's not surprising to see major bugs and problems, and mpv can do nothing about it.
In some cases, using them might be justified for performance (they might use a hardware overlay, most often these are just emulated with shaders though).
You need to build FFmpeg with mmal support - this is not enabled by default in FFmpeg. mpv also needs to be compiled with mmal, and the Broadcom firmware libEGL. Otherwise hardware decoding and scaling cannot be enabled.
You can check whether the FFmpeg (libavcodec) linked to mpv is built with mmal with mpv --hwdec=help|grep mmal. Before mpv 0,.28, this might have been called rpi instead of mmal, and the hwdec help output does not indicate whether FFmpeg actually was built with support. If the output is empty, FFmpeg was not correctly built. You can check whether mpv was built with mmal with mpv --vo=help|grep rpi.
It's rather complicated to get this to build correctly because RPI userland is a mess. Don't ask us for help, because we don't know your specific system. Keep in mind that the firmware libEGL and Mesa's libEGL (as often shipped by distros) are incompatible.
Once all this is done, run mpv with mpv --hwdec=rpi --vo=rpi file.mkv. Otherwise mpv might use software decoding, which tends to be too slow.
If you get the error mmal: mmal_vc_port_enable: failed to enable port vc.ril.video_render:in:0(I420): ENOMEM, try increasing gpu_mem in /boot/config.txt.
Pretty much like anything else, just pass the playlist URL to mpv. Note that you need a link to the actual playlist (https://www.youtube.com/playlist?list=...), NOT to a video in the playlist (https://www.youtube.com/watch?v=...&list=...&index=...). You can get that link by clicking on the title of the playlist on the right.
mpv is a command line program and doesn’t provide an actual GUI. You need to start it with a media file. On Windows, you can create a file association with the Open with… context menu. Also, if you start mpv.exe from explorer.exe, it will enter pseudo-gui mode. For Linux, a mpv.desktop file is provided.
You can also start mpv with mpv --player-operation-mode=pseudo-gui. You play files by dropping them on the window.
Check available format of video by youtube-dl:
youtube-dl --list-formats <link>or
youtube-dl -F <link>
For example:
youtube-dl -F https://www.youtube.com/watch?v=SYM-RJwSGQ8 [info] Available formats for SYM-RJwSGQ8: format code extension resolution note ... 251 webm audio only DASH audio 149k , opus @160k, 4.29MiB 135 mp4 854x480 480p 1159k , avc1.4d401e, 25fps, video only, 16.02MiB 247 webm 1280x720 720p 1372k , vp9, 25fps, video only, 20.12MiB 136 mp4 1280x720 720p 2318k , avc1.4d401f, 25fps, video only, 30.37MiB 248 webm 1920x1080 1080p 2402k , vp9, 25fps, video only, 35.54MiB 137 mp4 1920x1080 1080p 3770k , avc1.640028, 25fps, video only, 55.70MiB 22 mp4 1280x720 hd720 , avc1.64001F, mp4a.40.2@192k (best) ...Choice format and type
mpv --ytdl-format [format code] https://www.youtube.com/watch?v=SYM-RJwSGQ8For 1280x720:
mpv --ytdl-format 22 https://www.youtube.com/watch?v=SYM-RJwSGQ8You can mix different video+audio:
mpv --ytdl-format [video format code] + [audio format code] linkFor mp4 1080p video (3770k) and webm audio (149k, opus @160k):
mpv --ytdl-format 137+251 https://www.youtube.com/watch?v=SYM-RJwSGQ8
You can also use the special aliases bestvideo and bestaudio, and also use conditionals. (See youtube-dl --help for a full documentation). As an example, if you always want to use the best video stream but only up to 1440p - and falling back to the best single-file format when not playing DASH streams - you can use something like this:
ytdl-format=bestvideo[height<=?1440]+bestaudio/best
By default, volume is changed by scrolling horizontally. If you want to use vertical scrolling for that (rather than seeking), put this in your input.conf:
AXIS_UP add volume 2 AXIS_DOWN add volume -2
Run mpv in input test mode:
mpv --input-test --force-window --idle
Generally FFmpeg, simply because it has more features. Don't expect subtitles to work on Libav. Libav support may be broken at times, because they did not yet add certain FFmpeg API changes which mpv relies on.
Do not confuse Libav with e.g. libavcodec. libavcodec is a library that is provided by both the FFmpeg and Libav projects. Their APIs are almost the same, with subtle differences.
-
Install mpv as an app with Homebrew:
$ brew cask install mpv
-
If you need an alias in Applications/Launchpad, open a Finder window at /usr/local/Caskroom/mpv/your_mpv_version/. In there the mpv.app bundle has been generated. While holding Cmd+Alt, drag this .app into the Applications folder.
-
Use
dutito associate files with the application:$ brew install duti $ duti -s io.mpv avi all $ duti -s io.mpv mkv all $ duti -s io.mpv mp4 all
With mpv 0.18.1, volume control was forced to softvol, and the --softvol option was removed. PulseAudio volume control (as in changing the per-client volume in the server) is not used anymore. The following things change with this as perceived by users with default settings:
- changing volume in mpv now affects only the current mpv instance
- volume is not saved across all instances (though it will be saved for the current instance/media file if you use the watch-later feature)
- volume is not limited to 100% anymore
- you cannot use mpv volume controls to set the volume higher than your current PulseAudio volume settings
It is recommended that you use a separate, non-mpv key binding to control your global volume.
If you want the old behavior, you have to switch you key-bindings manually to the audio output volume controls:
- open your input.conf (see here for default location)
- add the following lines:
9 add ao-volume -2 0 add ao-volume 2
- or replace any occurrences of
volumewithao-volume - don’t forget that lines starting with
#are commented (the default input.conf has all entries commented) - note that mpv 0.18.1 had a bug that made PulseAudio “stuck” if the step was
1and not2- this has been fixed in later versions - options like
--volumecan never influence the server value - you can do the same with the mute key binding (
mute->ao-mute)
You can also grab all volume bindings from the default input.conf to change all volume bindings.
Note this this also works on other audio outputs and platforms. Which kind of volume ao-volume controls depends entirely on the audio API. Some APIs make it the global system volume, some make it per-client or per-stream private volume.
For technically inclined people: there was also a branch adding change that would have allowed to change all key bindings with a single option, but it hasn’t proven popular so far: https://github.com/mpv-player/mpv/commit/7621a028bf555c9ed0430501bc6eac2fa204114c
In mpv 0.21.0 the default OSC layout was changed to bottombar, along with other settings that worked better with it.
Create a lua-settings/osc.conf text file inside mpv’s configuration directory and use the following settings:
layout=box
seekbarstyle=slider
deadzonesize=0
minmousemove=3scalewindowed=1 as before with scalewindowed=1.5.
If you were using those layouts already and want the scale back as it was before 0.22.0, calculate it with 𝑥/1.5 where 𝑥 is the old value. So if are looking for the equivalent to scalewindowed=1, use these lua-settings/osc.conf:
scalewindowed=0.666
scalefullscreen=0.666The mpv youtube-dl wrapper script calls youtube-dl -J on URLs that begin with http(s). This returns a direct media link from which mpv streams directly. Nothing is downloaded to disk. Once playback starts, youtube-dl has exited and is not active anymore.
See the manual for available options: https://mpv.io/manual/master/#options-ytdl
Starting with mpv 0.30.0, some cache options have been removed (--cache-default, --cache-initial, --cache-seek-min, --cache-backbuffer, --cache-file, --cache-file-size), or changed (--cache does not take a size in KB anymore). This is a consequence of removing the stream cache, which was a ringbuffer of input data between demuxer and network level.
Caching is now done on the demuxing layer (between demuxer and decoder), which is controlled by separate options: --cache-secs, --demuxer-readahead-secs, --demuxer-max-bytes, --demuxer-max-back-bytes. Instead of --cache-file, --cache-on-disk is available.
The reason for the stream cache removal was that it mainly wasted memory, reduced performance, increased code complexity, and tended to cause weird bugs due to the cache layer not reflecting some of the underlaying stream's behavior exactly.
This is a limitation of the Windows platform. There are two so-called subsystems on Windows: the GUI subsystem and the CLI subsystem. A Windows executable can only use one of them. If a program uses the CLI subsystem, it can attach to the console, print messages there and receive input. However, such a program will always open a console window of its own if it is not already being run from one. A program using the GUI subsystem on the other hand will not attach to the console it is being called from, and control will immediately return to the command prompt. To work around that limitation, mpv has a separate executable, called mpv.com, which uses the CLI subsystem and redirects input and output for mpv.exe. Since Windows looks for executables with the .com suffix first (by default; defined by the %PATHEXT% variable), just typing mpv without a suffix on the command prompt will run mpv.com and you will get console output as expected.
Either pass all files to mpv, e.g. run this in the directory with the files:
mpv *.*Or use a script like https://github.com/mpv-player/mpv/blob/master/TOOLS/lua/autoload.lua .
Lua 5.3 is a different language from 5.1 or 5.2. Simply switching to Lua 5.3 would probably break most user scripts. The changes that make 5.3 incompatible are larger and have a greater impact than the changes that were done from 5.1 to 5.2 (or between LuaJIT and 5.1/5.2). This is especially due to the introduction of the integer type. Moreover, this would mean dropping LuaJIT support, as LuaJIT supports the 5.1/5.2 language only.
This is _not_ a matter of porting mpv's Lua code to 5.3. The problem is with the language the Lua interpreter accepts, and how it is incompatible with hundreds of 3rd party Lua scripts outside of the control of the mpv developers.
Supporting both languages for a time would be theoretically possible. But it would require separate backends, and significant effort to avoid the symbol conflicts between Lua 5.2 and 5.3 (maybe even impossible to do with distro-provided libs), so it won't be done.
RAR is an archive file format like zip. It is proprietary and there is not much code around that can handle it fully. Everyone should use the 7zip format instead - there is no reason to use rar. The time of proprietary file formats designed to sell software that handles it ought to be over. RAR is basically a relic of the past.
Multimedia related, it is unfortunately somewhat common to distribute large video files in uncompressed multi-volume RAR archives. This is almost the absolutely worst way to distribute media anyone could come up with. It's stupid because it requires support in every media player (limiting your choices), _will_ be inefficient in some ways, and is an absolutely unnecessary relic from the past, where it was stupid too. Apparently the people creating these live in the past.
It is somewhat expected from media players to handle these. mpv currently does so through libarchive. Unfortunately its support for multi-volume archives is not very good.
Please do not report bugs about this to mpv. Pester libarchive for better uncompressed/multi-volume RAR support instead.
mpv before release 0.30.0 had some special code for uncompressed RAR for this purpose. This code was lifted from VLC, but VLC removed this code years ago. This code used to work better, but was unacceptable to keep for maintenance reasons. It is unlikely that this code is readded.
DVD menu support existed since early times, but was removed because it was a maintenance nightmare. It affected unrelated parts of the player deeply, and prevented improving more important features. In addition, it never worked well. Later, DVD menu support was added again using rewritten code (and then Bluray menu support). However, despite the rewrite, it still affected the player core (preventing improvements in other areas), and it still did not work well.
The opinion of the developers is that menu support is cursed, and not worth implementing anyway. In addition to the monumental effort required to make it work well, only very few users benefit from it. It is a fact that playing DVDs/BDs gives a much better user experienced when ripped to files, which precludes menu support.
As a consequence, mpv only has some fallback support for optical media discs. Please don't report issues to it, as there is little chance of any improvements done to it.
If you are a developer and want to improve DVD/BD support in mpv, you are welcome to do so. But please try to keep the code isolated, so it does not affect the playback core too much. Most code related to it must be isolated in a separate module (for example stream_blurray.c, although it's allowed to change the layer at which the module is implemented). Ask on the developer IRC.
The relation between the two projects is mostly historic. They should be considered two separate projects. mpv and MPlayer are different software, incompatible to each other. There is no overlap in developers and other project members between MPlayer and mpv. mpv is not a drop-in replacement for MPlayer, and the command line switches and behavior are different.
MPlayer users should not expect that mpv is in any way similar to it. Both are CLI video players, and have common roots, but in some areas there are radical differences. An old and outdated summary of changes can be found here: https://github.com/mpv-player/mpv/blob/master/DOCS/mplayer-changes.rst
mpv is based on MPlayer's code. At first, there was the mplayer2 project, which forked away from MPlayer roughly in 2008, and went different ways from it. (It was renamed to mplayer2 only a few years later, causing general confusion.) In 2012, some newer developers, who joined mplayer2 development around 2011, forked mplayer2 again. This second fork was then renamed to mpv.
The reason for this fork was disagreement over the direction of development. While MPlayer focuses on maintenance and not breaking old code and features, mpv wanted to go into the other direction, modernization. This included merciless removal of code/features that were not considered worth maintaining due to being obscure and unused, or rewriting existing code to clean it up and to reduce bugs. Reducing maintenance burden by replacing MPlayer code with FFmpeg mechanisms was also a priority. mplayer2 was stuck between those positions - first going for mpv's direction, but then remaining stagnant with slow development. The mplayer2 project soon went inactive after the mpv fork, and is completely gone today.
We consider mpv's radical approach successful, making the code easier to work with, removing bugs, and making it easier to add new features. We added modern features wanted by users in exchange for removing large amounts of features barely anyone used anymore.
One result is that mpv development has nothing to do with MPlayer development anymore. They are completely separate projects. The mplayer2 period might have contributed to the relative isolation between the two projects. After all these years of going separate directions, merging MPlayer and mpv back into one project wouldn't make sense.