🎥 mpv is a free (as in freedom) media player for the command line.

mpv logo


External links


mpv is a free (as in freedom) media player for the command line. It supports a wide variety of media file formats, audio and video codecs, and subtitle types.

There is a FAQ.

Releases can be found on the release list.

System requirements

  • A not too ancient Linux, Windows 7 or later, or OSX 10.8 or later.
  • A somewhat capable CPU. Hardware decoding might help if the CPU is too slow to decode video in realtime, but must be explicitly enabled with the --hwdec option.
  • A not too crappy GPU. mpv's focus is not on power-efficient playback on embedded or integrated GPUs (for example, hardware decoding is not even enabled by default). Low power GPUs may cause issues like tearing, stutter, etc. The main video output uses shaders for video rendering and scaling, rather than GPU fixed function hardware. On Windows, you might want to make sure the graphics drivers are current. In some cases, ancient fallback video output methods can help (such as --vo=xv on Linux), but this use is not recommended or supported.


For semi-official builds and third-party packages please see mpv.io/installation.


There is no complete changelog; however, changes to the player core interface are listed in the interface changelog.

Changes to the C API are documented in the client API changelog.

The release list has a summary of most of the important changes on every release.

Changes to the default key bindings are indicated in restore-old-bindings.conf.


Compiling with full features requires development files for several external libraries. Below is a list of some important requirements.

The mpv build system uses waf, but we don't store it in the repository. The ./bootstrap.py script will download the latest version of waf that was tested with the build system.

For a list of the available build options use ./waf configure --help. If you think you have support for some feature installed but configure fails to detect it, the file build/config.log may contain information about the reasons for the failure.

NOTE: To avoid cluttering the output with unreadable spam, --help only shows one of the two switches for each option. If the option is autodetected by default, the --disable-*** switch is printed; if the option is disabled by default, the --enable-*** switch is printed. Either way, you can use --enable-*** or --disable-** regardless of what is printed by --help.

To build the software you can use ./waf build: the result of the compilation will be located in build/mpv. You can use ./waf install to install mpv to the prefix after it is compiled.


./waf configure
./waf install

Essential dependencies (incomplete list):

  • gcc or clang
  • X development headers (xlib, xrandr, xext, xscrnsaver, xinerama, libvdpau, libGL, GLX, EGL, xv, ...)
  • Audio output development headers (libasound/ALSA, pulseaudio)
  • FFmpeg libraries (libavutil libavcodec libavformat libswscale libavfilter and either libswresample or libavresample)
  • zlib
  • iconv (normally provided by the system libc)
  • libass (OSD, OSC, text subtitles)
  • Lua (optional, required for the OSC pseudo-GUI and youtube-dl integration)
  • libjpeg (optional, used for screenshots only)
  • uchardet (optional, for subtitle charset detection)
  • nvdec and vaapi libraries for hardware decoding on Linux (optional)

Libass dependencies (when building libass):

  • gcc or clang, yasm on x86 and x86_64
  • fribidi, freetype, fontconfig development headers (for libass)
  • harfbuzz (required for correct rendering of combining characters, particularly for correct rendering of non-English text on OSX, and Arabic/Indic scripts on any platform)

FFmpeg dependencies (when building FFmpeg):

  • gcc or clang, yasm on x86 and x86_64
  • OpenSSL or GnuTLS (have to be explicitly enabled when compiling FFmpeg)
  • libx264/libmp3lame/libfdk-aac if you want to use encoding (have to be explicitly enabled when compiling FFmpeg)
  • For native DASH playback, FFmpeg needs to be built with --enable-libxml2 (although there are security implications, and DASH support has lots of bugs).
  • AV1 decoding support requires dav1d.
  • For good nvidia support on Linux, make sure nv-codec-headers is installed and can be found by configure.

Most of the above libraries are available in suitable versions on normal Linux distributions. For ease of compiling the latest git master of everything, you may wish to use the separately available build wrapper (mpv-build) which first compiles FFmpeg libraries and libass, and then compiles the player statically linked against those.

If you want to build a Windows binary, you either have to use MSYS2 and MinGW, or cross-compile from Linux with MinGW. See Windows compilation.

Release cycle

Every other month, an arbitrary git snapshot is made, and is assigned a 0.X.0 version number. No further maintenance is done.

The goal of releases is to make Linux distributions happy. Linux distributions are also expected to apply their own patches in case of bugs and security issues.

Releases other than the latest release are unsupported and unmaintained.

See the release policy document for more information.

Bug reports

Please use the issue tracker provided by GitHub to send us bug reports or feature requests. Follow the template's instructions or the issue will likely be ignored or closed as invalid.

Using the bug tracker as place for simple questions is fine but IRC is recommended (see Contact below).


Please read contribute.md.

For small changes you can just send us pull requests through GitHub. For bigger changes come and talk to us on IRC before you start working on them. It will make code review easier for both parties later on.

You can check the wiki or the issue tracker for ideas on what you could contribute with.


GPLv2 "or later" by default, LGPLv2.1 "or later" with --enable-lgpl. See details.


This software is based on the MPlayer project. Before mpv existed as a project, the code base was briefly developed under the mplayer2 project. For details, see the FAQ.


Most activity happens on the IRC channel and the github issue tracker.

  • GitHub issue tracker: issue tracker (report bugs here)
  • User IRC Channel: #mpv on irc.freenode.net
  • Developer IRC Channel: #mpv-devel on irc.freenode.net
  • LGPL relicensing

    LGPL relicensing


    • What, why?

      The mpv project (a MPlayer and mplayer2 fork) is relicensing its code base from GPLv2 or later to LGPLv 2.1 or later. For that, we're asking MPlayer, mplayer2, and mpv contributors to give us permission. This includes occasional or one-time contributors. For reasons why we are doing this and for details on the relicensing process see the sections below.

    • How do I give my permission?

      Posting something informal like

      I agree that my past contributions to mpv, mplayer2, or MPlayer are relicensed to 
      the GNU Lesser General Public License (LGPL) version 2.1 or later

      in this github issue or per email to wm4 ([email protected]) should be sufficient. (I've also sent a lot of mails via a private mail account, because the gmail one looks like it could be dismissed as spam too easily.)

      If you post on a github issue, and your github account doesn't show your real name or an email address you used for MPlayer development, please make sure to identify yourself so that we can link you to specific MPlayer contributions!

      If you don't want to give permission to relicense some specific parts, but don't mind that the core is relicensed in general, it's possible that we negotiate a list of files or a list of commits we're allowed to relicense. This could explicitly exclude parts you want to keep GPL. You could also choose to state that relicensing any code still remaining in mpv is fine (this would exclude anything that is still in MPlayer, but not mpv).

    • I never contributed much and I don't even know if my code is still there. Why did I get email about this / why was I pinged on github? Do I even have to give my permission?

      Some people say that their contribution was too minor and uncopyrightable, or that their code was replaced or refactored. This could be true. But we are not lawyers. It's not always sure what constitutes a minor/uncopyrightable change, or when new code is considered to be derived from some piece of replaced/refactored code. So getting as many agreements as possible is very helpful for us, even if the original authors of a patch think it doesn't matter, or it was a minor patch many years ago. Please respond to relicensing requests, even if you think it's not necessary!

      It's also possible that you were asked, even though you did not contribute to MPlayer directly. For example you could have contributed to a different project, and MPlayer incorporated some of its code. That code would still be copyrighted by you (at least partially), so we need to ask for relicensing permission.

    • Were the email for relicensing requests sent automatically?

      No. Every single of them was sent manually. They were sent only to people for which there was at least a chance that their agreement would be required.

    • Did the MPlayer project agree with this?

      Most of the MPlayer developers agreed (including original and current developers). Most contributors who have been asked so far agreed as well. See the status of MPlayer contributors.

    • Do you assume non-replies mean agreement (OpenSSL style relicensing)?

      No. Copyright law doesn't work this way. If someone doesn't reply, and he has copyright on parts we want to relicense, we will have to remove their code to succeed.

    • What happens if I don't agree?

      Then the entire relicensing of mpv will fail. If there are only some cases, we'll probably try to remove the code of contributors who have not agreed (if possible). My plan B would be writing a new player from scratch.

      Note that it might be fine to agree to relicensing of only some parts. We're mostly interested in relicensing the core, so a LGPL libmpv is possible. Also see the next FAQ entry below.

    • Will all of mpv be relicensed?

      Most likely only the core and components required for libmpv. For example, it's unlikely that the X11 windowing code, the V4L TV code, or the DVD code get relicensed. These parts will remain GPL, and will not be compiled in LGPL configurations. On the other hand, many patches touching X11 also added code to other parts of the player, such as adding new options (which would later be supported by other windowing code) - we'd still want to relicense those changes.

      Due to the aforementioned messy licensing state of the VO windowing backends, it looks like mpv CLI LGPL will be unusable on some systems (e.g. X11), while LGPL libmpv will hopefully be useful.

      In addition, the following parts were removed from mpv, and we won't ask for relicensing those parts: mencoder, the GUI, Linux 2.4 kernel drivers (!), dozens of decoder library wrappers, the win32 codec loader, ancient video outputs, filters, the build system, documentation in general, and imported libraries such as a bunch of mpeg decoders. Some libraries were moved to separate projects and have already been relicensed a long time ago, like libswscale and libass. mpv is highly reliant on FFmpeg for decoders and demuxers, which probably accounts for most of the core code removed.

    • Will the license of MPlayer change?

      Definitely not. To make it easier for us, we're skipping a lot of MPlayer code in the relicensing that is not used by mpv anymore (and that was not used to derive new mpv code from it). This is possible because mpv dropped large parts of MPlayer code (see previous question). All this means that even if you'd apply the relicensing agreements to MPlayer, you wouldn't get anything working out of it.

    • Do I lose the rights to my code?

      No, you retain copyright and own your code. The effect is merely that others (the mpv project) can use your code under LGPL instead of only the GPL.

    • I made contributions to MPlayer, but I wasn't contacted?

      Please reply to this github issue or send email to give your agreement/disagreement.

    See also VLC's LGPL relicensing FAQ.


    The reason is mostly that the player got turned into a library (libmpv), and the associated problems of a GPL lib for a library user. Here's a detailed list of reasons why this is desirable, alternatives, and some discussion:

    • The main reason is easily the fact that mpv prefers embedding video by accessing the host application's OpenGL context. This means the host application has to link to libmpv directly and run in the same process as mpv, just for the GL context. This is called the opengl-cb API in libmpv. While technically possible in many cases, sharing some sort of video context (like an OpenGL context) over process boundaries is fragile and complex, so linking to libmpv is required.

      MPlayer on the other hand embeds an OS window over process boundaries (with the -wid option). This is becoming technically unfeasible, and the libmpv opengl-cb API sidesteps many issues with it.

      While mpv can still be embedded using the "old" method (and by using e.g. the JSON API), we prefer the opengl-cb, and don't want license issues to hamper this. Nor do we want the rendering method to have an influence on the application's license.

    • MPlayer always provided the slave mode, which allows closed source application to use MPlayer's playback capabilities. And there are even examples of this happening (MPlayerX). So MPlayer being GPL did not prevent it to be used from non-GPL applications. It follows that the MPlayer projects and its developers at least tolerate slave mode being used from non-GPL applications. I see no reason why this difference should be made just with the technical difference of in-process vs. out-of-process and C API vs. text protocol. Thus allowing libmpv to be used from non-GPL application is just natural. Relicensing to LGPL would achieve this.

    • GPL-incompatible dependencies such as OpenSSL are a big issue for library users, even if the library user is ok with the GPL. OpenSSL specifically is not compatible with the GPL, unless all involved GPL projects include an OpenSSL exception (but this is equivalent to a license change, so why not just use the less problematic LGPL). Note that not-GPL does not mean closed-source. There are many potential users who want to stick to other open source licenses that are not GPL.

    • Even many GNU libraries don't force GPL on the user (consider glibc, Guile, gettext, GNU lightning, GNU pth).

    • LGPL is almost like GPL, except it gives more freedom to the library user. This should be a rather inoffensive change (compared to e.g. changing it to BSD). Since (lib)mpv is a complete player, rather than something like a multimedia library, the "freedom" of libmpv isn't in danger either. For example, if you wanted to add a filter or a decoder to your playback chain, you would have to do that in libmpv itself (licensing the addition as LGPL), rather than making it a closed-source part of your evil proprietary application.

    • Even if libmpv were to stay GPL, it would not necessarily lead to more applications going open source. It's far more likely such an application would choose something like libvlc or gstreamer as backend instead. This could even happen with potential libmpv users which are open source, but not GPL, as its authors might want to escape from the complications of the GPL license. Likewise, existing non-GPL applications, which just want to integrate video playback as another feature, would obviously not be able to pick a GPL libmpv (libmpv isn't that attractive as they would relicense to GPL just to use it). My conclusion is that libmpv going LGPL would give back more to the open source community than a GPL libmpv.

    • VLC did it too, and nothing bad happened.

    • Parts of MPlayer code have been relicensed/"extracted" under more liberal licenses before: libswscale (LGPL), libass (ISC)

    • An exception for non-GPL libmpv usage might work. This would be a GPL linking exception. It'd require as much effort as a switch to LGPL, so we might as well change to LGPL.

    • Some libmpv user opinions: https://github.com/mpv-player/mpv/issues/2033#issuecomment-249429195 and https://github.com/mpv-player/mpv/issues/2033#issuecomment-249426616

    Relicensing process

    We will ask mpv, MPlayer, and mplayer2 developers for their agreement. We will probably skip contributors who contributed documentation or website changes only (MPlayer has extensive documentation in multiple languages, all in the main code repository). We will also skip developers who have contributed only to now-removed code (such as vo_svga.c or libswscale).

    We will also ask people who have contributed single patches a long time ago, as long as their code was used as base for further developments. It's important and appreciated that these people give their agreement as well.

    So far I think it's ok to relicense a source file if:

    • all current contents of the file are written by authors who agreed with the LGPL switch

    • removed contents do not count, as long as new code was not "derived" from it (such as simple refactoring)

    • care has to be taken that lines, which merely went through cosmetic changes or refactoring, are considered as "current content" (i.e. mere git blame output is not necessarily meaningful)

    • Authors which only did minor cosmetic changes of some sort do not have a copyright on the file (consider code reindenting). Extreme care has to be taken here - copyright always sticks, even with simple changes. It's not clear when a change is uncopyrightable. Most seem to agree that entirely cosmetic changes, e.g. pure whitespace changes, are not copyrightable. Some set the bar for copyrightable much higher.

    Further, some projects which have gone through relicensing claim there is a threshold above which relicensing can be done without the rest of the developers agreeing:

    • VLC thinks 99.99% of the code must be covered and 99% of all developers (https://mailman.videolan.org/pipermail/vlc-commits/2011-November/010353.html)
    • Dolphin and Mozilla think only 95% of all contributors must have agreed (https://dolphin-emu.org/blog/2015/05/25/relicensing-dolphin/ http://blogs.fsfe.org/ciaran/?p=58)

    Relicensing plan

    The actual relicensing will be done as follows:

    • Phase 1: broadly probe for consent (done)
      • ask everyone who submitted a patch to mpv
      • contact everyone who wrote a major piece of code and ask for permission
    • Phase 2: ask every contributor (mostly done, waiting for potential late replies)
      • go through the commit list, and look at every single of those ~44k commits
      • if the commit message says the patch was by someone else (or we know it was by someone else or copied from somewhere else), contact that external controbutor as well
      • if the code is most likely still present in mpv (directly or refactored), and not in code we don't want to relicense, make sure that person was contacted
    • Phase 3: actual relicensing (mostly done)
      • try to relicense each source file
      • go through every change to that file, and make sure that for each change (unless it was completely removed) the author was contacted and agreed
      • if that is not the case, do one of those things, depending on what's possible:
        • guard the code as GPL-only (so it won't be compiled for LGPL binaries)
        • remove/replace the code
        • declare the change as trivial
        • fail the relicensing and go with plan B, and write a new player
      • in some cases, code might have been copied from other source files or projects, which complicates this step
    • Phase 4: verification and finishing up (done, relicensing of some optional parts is still pending)
      • add a preliminary --enable-preliminary-lgpl3 configure option (done)
      • post to mplayer-dev-eng mailing list for anyone who wants to verify (done)
      • let it sit for a few weeks or so (done)
      • make the LGPL change final by renaming the configure option to --enable-lgpl and updating the main copyright notice (done)

    More information

    Other arguments pro-LGPL: https://github.com/mpv-player/mpv/issues/2033#issuecomment-249429195 https://github.com/mpv-player/mpv/issues/2033#issuecomment-249426616

    MPlayer developers status: https://github.com/mpv-player/mpv/issues/2033#issuecomment-249416217

    MPlayer thread: http://lists-archives.com/mplayer-dev-eng/39326-relicensing-mplayer-or-parts-of-it-to-lgpl.html

    VLC LGPL switch reasons & FAQ (yes, they mostly apply to us too): https://www.videolan.org/press/lgpl.html

    VLC reasons against GPLv3 (also mostly applies to us): http://www.videolan.org/press/2007-1.html

  • Color Management (OS X): Image is too dark

    Color Management (OS X): Image is too dark

    I have compared the icc-profile= setting of mpv to Apple’s native QuickTime Player X on OS X 10.9.1 and found that the resulting colors are basically correct, but the image is too dark.

    The following images are from a scene from Lars von Trier’s Melancholia. The first image is from QuickTime Player X:


    This image is from a h.264 file (in an mp4 container) extracted from the BluRay version of the movie. I have compared it to the DVD version (played in Apple’s DVD Player) and to the version from the iTunes store, and the colors are exactly the same in these three versions and also match high quality still images I have from this movie.

    So this image is arguably the reference and shows how the colors should look like.

    The next image is from the same mp4 file, played in mpv without color management:


    This image makes it very obvious why color management is a must; aesthetically, it’s basically another image (technically, it’s too red and too saturated).

    The third image is again from the same mp4 file, played in mpv with color management (using the default rendering intent, which is absolute – choosing another intent does not fix the problem discussed here):


    As you can see, compared to the QuickTime version, the colors seem to be more or less correct now, but the image is obviously too dark.

    Now I wonder if this is a deficiency of the liblcms2.2.dylib library that mpv uses, or if it's just that mpv uses liblcms2.2.dylib with incorrect or suboptimal parameters?

    Could somebody familiar with this part of the mpv code base comment?

  • HDR tonemapping producing subpar results with default config

    HDR tonemapping producing subpar results with default config

    mpv version and platform

    Windows 10 1809

    mpv 0.29.0-107-gd6d6da4711 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects built on Sun Dec 16 00:57:00 UTC 2018 ffmpeg library versions: libavutil 56.24.101 libavcodec 58.42.102 libavformat 58.24.101 libswscale 5.4.100 libavfilter 7.46.101 libswresample 3.4.100 ffmpeg version: git-2018-12-15-be60dc21

    Reproduction steps

    Attempt to watch HDR content on SDR monitor

    Expected behavior

    Accurate reproduction of colours and brightness levels

    Actual behavior

    Colours (particularly in the red spectrum) are not accurately reproduced, light often behaves unnaturally and visibly shifts mid-scene

    Log file


    Sample files

    If someone can tell me how to losslessly cut an mkv with HDR metadata intact I can provide samples

    From what I can tell, tonemapping with mpv currently has two major issues what make it rather unpleasant to the end user: Reds are awful, I don't know if there's something special about this part of the spectrum but mpv does not play well with them at all - at least with the default settings. I've found I can improve reds dramatically by tweaking some settings such as the following but this comes with the cost of interfering with the rest of the film. tone-mapping-desaturate=0 hdr-compute-peak=no

    Here are some examples of reds/yellows not behaving correctly, I'll be using madVR as a pseudo reference as I don't have the SDR BD on hand and they seem to have no such issues with their tonemapping solution. These examples are from The Dark Knight 2008, mpv (default) has no HDR-specific config, mpv (tweaked) users the aforementioned config from the previous paragraph. Full gallery for easier viewing: https://imgbox.com/g/DvoY5yAjFH Examples:

    Fire - madVR: https://images2.imgbox.com/db/c3/TRqmFfaz_o.png mpv (default): https://images2.imgbox.com/50/1b/L9crP04w_o.png mpv (tweaked): https://images2.imgbox.com/e6/0d/HROmk5iG_o.png

    Explosion - madVR: https://images2.imgbox.com/5d/0d/KzBne9Hd_o.png mpv (default): https://images2.imgbox.com/a8/8a/kDpQb97n_o.png mpv (tweaked): https://images2.imgbox.com/e4/5b/eji8jTxh_o.png

    Secondly, hdr-compute-peak often causes noticeable shifts in brightness throughout the film even when there's not much going on. I noticed this while watching The Big Lebowski for example, while they were standing around talking the brightness suddenly shifted and it was very noticeable and uncomfortable. Here's an example of it shifting dramatically within a few frames, again, from The Dark Knight 2008: https://images2.imgbox.com/75/a9/LuuoGHun_o.png https://images2.imgbox.com/a9/0c/SpBDirqQ_o.png

    One thing in paricular that I've noticed about this is it's at its most egregious during sudden shifts, such as cutting from a dark scene directly to an explosion; perhaps it would be possible for mpv to scan ahead of time so such shifts can be accounted for?

  • Black crush and color deviations with some ICC profiles

    Black crush and color deviations with some ICC profiles

    Continuation of the discussion in #534.

    Some ICC profiles are experiencing black crush when used in mpv, in particular ones that use complex transfer curves rather than simple pure powers.

    Proposed solutions including reworking the 3DLUT/lcms mechanism to pick a connection space more gracefully.

  • Make

    Make "sphinx" the default for 'tscale' interpolation!

    Example video to make my point: https://www.youtube.com/watch?v=MonFNCgK4WE [Mad Max - Fury Road "Retaliate" Trailer] Just when looking at the first half minute or so You will notice the excessive amounts of blurring that takes place with the new default of "tscale=mitchell". The same trailer with "tscale=triangle" however, is way more sharp while still being very smooth. So, for me at least, "tscale=triangle" is the perfect compromise between smoothness & sharpness (and trust me when I tell You that I've tried them all...). IMHO, mpv's defaults should satisfy the needs of the majority of users; while "tscale=mitchell" may be a little bit smoother, the blurriness it causes could scare away users that don't bother checking out each and every tscale option that there is.

    I'm interested to hear what You guys think about this and whether You think that there is an even better tscale option other than triangle.

  • vo_opengl: generate 3DLUT against source and use full BT.1886

    vo_opengl: generate 3DLUT against source and use full BT.1886

    This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide).

    This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles.

    The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit.

    Fixes #2815.

  • macOS opengl-cb backend

    macOS opengl-cb backend

    this is a WIP and attempts to fix various annoying macOS bugs and the very long standing fullscreen regression completely. it still needs testing and some fix-ups.

    this will definitely fix: #5478, #5393, #5152, #5151, #4615, #4476, #3746, #3739, #2392, #2217 and possibly fixes: #3978

    feel free to test and report unknown bugs. for now one just needs to set --vo=opengl-cb, ~~though if the mpv core is too fast you might get a "No context set." error.~~

    there are a few things to do where i don't know how to solve them yet and i might need some help. TODO cocoa-cb:

    • ~~proper cocoa-cb init routine, (--no-config --vo=opengl-cb fails since no context yet)~~
    • ~~cocoa-cb vo option or comparable~~ (just compile time flag, uses vo=opengl-cb)
    • ~~doesn't draw when minimised, off screen, different space etc.~~
    • ~~get a hide (and unhide) event for windowless playback~~
    • ~~remove "[opengl-cb] icc-profile-auto is not available with opengl-cb" warning in an acceptable way~~
    • ~~change lux scale~~ (db0fb3c48b12f09170231fccd2c91687d9ce21db)
    • ~~remove "Taking screenshot failed." warning, appears on screenshot (window), not too happy with the window screenshot code~~
    • ~~on shutdown wait for animations to finish~~
    • ~~performance data buggy~~
    • ~~ICC profile switching leads to flicker in some cases (with icc-profile-auto=no, most likely an Apple bug)~~

    TODO Build:

    • ~~flag to deactivate cocoa-cb~~
    • ~~dynamic developer path for static_swift~~
    • ~~set build target min system requirements~~

    things i will fix soonish:

    • ~~fullscreen animation stretches video to target aspect ratio~~
    • ~~crashes on video stream switch to no-video (related to "hide and unhide event for windowless")~~
    • ~~implement none-native fs~~
    • ~~add license headers~~
    • ~~(deactivate the early flush on macOS)~~

    TODO misc:

    • ~~add a deprecation warning for the old opengl cocoa backend?~~
  • "video-sync=display-resample" leads to choppy output...

    File in question: http://videos.hd-trailers.net/BVS_DTRL1_REV_ONLINE_VERSION-1080p-HDTN.mp4 (Warning: ~ 200 MB)

    Every other file I've tried plays just fine. Also, there seems to be nothing unusual about the file in question...

    And since having to set the "video-sync" option is going to be a requirement for interpolation in the future, I'm kinda stuck if more & more files are going to show this choppy behavior going forward!

    PS: The file plays correctly when not setting "video-sync=display-resample" (i.e. using the default).

  • build: add meson build support

    build: add meson build support

    Since github doesn't let you reopen after a force push, here's a new PR. This is a continuation of https://github.com/mpv-player/mpv/pull/7897 that's rebased and updated for the newer build stuff that happened since then.

    So given some recent developments, I think there's now a clear advantage to switching to meson. Namely, libplacebo will play a significant role in mpv's core rendering since vo_placebo will probably replace vo_gpu sometime in the future. In light of that, it would be nice if development between libplacebo and mpv was made as smooth as possible. libplacebo uses meson as its build system and one nifty feature meson has is its subprojects feature. Using that feature would make it extremely easy to test changes in libplacebo and mpv. Of course, this would require porting mpv's build system to meson so here we are.

    This now depends on meson 0.60.

    Working (should be):

    • [x] Linux
    • [x] BSD
    • [x] Windows
    • [x] macOS
    • [x] All non-specific OS options/features


    • [x] Fix win32-internal-threads (that's a mess)
    • [x] Implement FULLCONFIG variable (lists every enabled feature in the build)
    • [x] add meson builds to CI
    • [x] fix BSD libmpv linking error
    • [x] getting the macOS swift code to actually compile
    • [x] wait for the 0.60 meson release to land in the rolling-release distros
    • [x] sort out macOS Swift linking
    • [x] cleanups/formatting
    • [x] More testing
  • Gapless playback of mp3s

    Gapless playback of mp3s

    Am I overlooking an option in the man page to accomplish this? The decoder I'm using in mpv is the default mpg123.

    Gapless playback occurrs in Qmmp if the mpg123 decoder plugin from the Qmmp Plugin Pack is installed and when playing mp3s using mpg123 itself (gapless option is on by default).

    I'm at a loss for why it isn't working in mpv.

  • Implement NNEDI3 with GPU backend

    Implement NNEDI3 with GPU backend

    NNEDI3 works with a Vapoursynth port of the original script, but you must use vspipe --y4m script.vpy >> output.raw and then take a long walk. It would be amazing to implement NNEDI3 into MPV in such a way that it used the GPU through opencl or otherwise.

  • User shaders: problems with linearize macro

    User shaders: problems with linearize macro

    Important Information

    • mpv 0.35.0-21-gead8469454 Copyright © 2000-2022 mpv/MPlayer/mplayer2 projects built on Thu Nov 24 12:53:09 2022; libplacebo version: v5.229.1-33-g7ead30d
    • windows 10, vo=gpu-next, gpu-api=d3d11

    Reproduction steps

    Play this video https://www.youtube.com/watch?v=sVi1go-hqh0, or any similar with very bright details with alt-scale https://github.com/garamond13/alt-scale user shader. Upscaled with and without clamp after linearize.

    Expected behavior

    Normal image, identical to the image produced by mpv or libplacebo scaling, in both cases with and without clamp after linearize.

    Actual behavior

    Without clamp very bright parts can get colorful blocky artifacts. With clamp there are no such problems.

    Sample files

    Images are screenshots of above video upscaled with alt-scale 2x, than screenshots were cropped and upscaled with nearest.

    clamp clamp

    without clamp no clamp

    Also, what I'm getting here. Is this normal / expected behavior and if so, is clamping here normal / expected thing to do. And could there be similar issue with delinearize?

  • mpv secondary-sid blocks sub selection cycle in osc

    mpv secondary-sid blocks sub selection cycle in osc

    Important Information

    • mpv version:
    $ mpv --version
    mpv 0.35.0 Copyright © 2000-2022 mpv/MPlayer/mplayer2 projects
     built on UNKNOWN
    FFmpeg library versions:
       libavutil       57.28.100
       libavcodec      59.37.100
       libavformat     59.27.100
       libswscale      6.7.100
       libavfilter     8.44.100
       libswresample   4.7.100
    FFmpeg version: 5.1.2
    • Linux Distribution and Version: Debian testing
    • Source of the mpv binary deb https://www.deb-multimedia.org bookworm main non-free
    • Window Manager and version
    $ kwin --version
    kwin 5.26.3
    • GPU driver and version nvidia blob 510.85.02

    Reproduction steps

    mpv Starship_Troopers.mpeg --no-config --sid=1 --secondary-sid=2

    Expected behavior

    When you click subs icon it should cycle through availible subs

    Actual behavior

    On sub switch when next sub id is used by secondary-sid it displays error in terminal: "Track 2 is already selected." And you are unable to cycle to the next sub stream in that direction.

    Log file


    Sample files


    I should note that cycle with j/J works fine - it just skips over subs that used as secondary. So I made some modifications to osc to add button for secondary subs and made it use mp.commandv('cycle') to switch both subs. Here is diff against master https://0x0.st/oklS.diff

  • "mjpeg" codec introduces green lines on the top and/or bottom of certain jpeg images

    Important Information

    • mpv version: mpv-x86_64-v3-20221204-git-4574dd5 (but mpv has had this issue for a long time)
    • Platform and Version: Windows 11 x64 (I didn't test on Linux or macOS)
    • Source of the mpv binary: SourceForge

    Reproduction steps

    Use mpv --hwdec --hwdec-codecs=mjpeg --keep-open to open the attached sample images below.

    Expected behavior

    Images should be displayed without green lines.

    Actual behavior

    1.jpg is displayed with green lines on the top and the bottom. 2.jpg is displayed with green lines on the bottom.

    sshot-1 sshot-2

    Log file

    1.jpg.txt 2.jpg.txt

    Sample files

    1 2

  • I wonder if there are other options for

    I wonder if there are other options for "reset-on-next-file"

    When I drag a file to the mpv with the mouse, the playback will continue the Settings of the previous file, such as ab-loop.I hope I can cancel ab-loop when playing the next file, but reset-on-next-file=ab-loop doesn't seem to work, so is there any way to solve it?

    I wonder if there are other options for "reset-on-next-file"

  • Video displacement and crash when toggling fullscreen

    Video displacement and crash when toggling fullscreen

    Important Information

    • mpv 0.35
    • macOS 12.6.1
    • Homebrew
    • Similar issue #8490
    • Related issues #10311
    • Happens with any video

    Reproduction steps

    $ defaults write com.apple.universalaccess reduceMotion 1 # seems to have no effect anymore
    $ defaults write -g NSWindowResizeTime -float 0.001 # seems to have no effect anymore
    $ mpv --config=no --native-fs=no --pause any-video.mp4
    Press "f" successively.

    Expected behavior

    The video should go in and out of fullscreen instantly.

    • No transition effects
    • No delays
    • No visual flickers

    Actual behavior

    • A non-fatal crash happens every time entering fullscreen (see attachment)
    • The menu bar is displayed prematurely for one frame (see attachment)
    • The video is displaced for one frame (see inline and attachment)

    The frames "..02" and "..03" should never happen. Display should go directly from "..01" to "..04".

    Switching to native fullscreen introduces a transition effect, and sometimes even lags, so this is an undesirable option as it makes mpv feel sluggish (even though it may not be at fault).

    Log file

    mpv.log crash.log

    Sample files

    Happens with any video.


    Displacement frames:

    0103 0203 0303

    See zip file for all frames.


  • --d3d11va-zero-copy=yes with hdr10, the video causes a green stripe of 1 pixel at the bottom of the screen

    --d3d11va-zero-copy=yes with hdr10, the video causes a green stripe of 1 pixel at the bottom of the screen

    I noticed that when watching an HDR 10 video, a green stripe appears at the bottom of the screen, I found out by brute force that the --d3d11va-zero-copy and --hwdec=d3d11va parameter causes this if they are used together

    I checked on a clean build only with these keys

    --d3d11va-zero-copy=yes --tone-mapping=bt.2446a --vo=gpu-next --hwdec=d3d11va --log-file=~~global/mpv.log

    last build. https://sourceforge.net/projects/mpv-player-windows/files/64bit-v3/ log https://fex.net/ru/s/at7aee3

    Имя устройства DESKTOP-884EQSO Процессор AMD Ryzen 3 5300U with Radeon Graphics 2.60 GHz Оперативная память 8,00 ГБ (доступно: 7,33 ГБ) Код устройства 6CE0BADE-A012-4D65-9B92-02BE6C3DC232 Код продукта 00330-80000-00000-AA269 Тип системы 64-разрядная операционная система, процессор x64 Перо и сенсорный ввод Для этого монитора недоступен ввод с помощью пера и сенсорный ввод

    Выпуск Windows 11 Pro Версия 22H2 Дата установки ‎22.‎10.‎2022 Сборка ОС 22621.900 Взаимодействие Windows Feature Experience Pack 1000.22638.1000.0

    image image image

Free and open-source media player written in C++

Liquid Media Player Free and open-source media player written in C++. Currently in development. Build Guide Windows Install the MSYS2 Building Platfor

Sep 20, 2022
Hack to allow live streaming from wyze cameras to vlc or mpv on your desktop.
Hack to allow live streaming from wyze cameras to vlc or mpv on your desktop.

Wyze Cam Live Streaming This is a hack to allow live streaming from a wyze cam on your local network. Installation - New! The simplest fix for wyze ev

Dec 7, 2022
mpv to vlc converter (for anilabx-lite-windows)

mpv-to-vlc Simple CPP project, created for AniLabX-Lite (requested by @themrlokopoff) Compiling Open project in Visual Studio Select "Release" version

Aug 18, 2021
TIP (translate it, please) is a plugin for VLC media player that helps you to study languages by watching videos.

vlc-tip-plugin TIP (translate it, please) is a plugin for VLC media player that helps you to study languages by watching videos. Features The plugin a

Oct 11, 2022
Jellyfin Desktop Client based on Plex Media Player
Jellyfin Desktop Client based on Plex Media Player

Desktop client using jellyfin-web with embedded MPV player. Supports Windows, Mac OS, and Linux. Media plays within the same window using the jellyfin-web interface unlike Jellyfin Desktop. Supports audio passthrough. Based on Plex Media Player.

Nov 30, 2022
A clone of Media Player Classic reimplemented in Qt.
A clone of Media Player Classic reimplemented in Qt.

Media Player Classic Qute Theater A clone of Media Player Classic reimplemented in Qt. Media Player Classic Home Cinema (mpc-hc) is considered by many

Dec 7, 2022
theora-player is an embeddable theora video player C++ library based on the libtheora sample. It has no audio support at this moment.

theora-player Description theora-player is an embeddable theora video player C++ library based on the libtheora sample. It has no audio support at thi

Jun 18, 2022
media server based on c++11, support webrtc/rtmp/httpflv/websocket flv

cpp_media_server A media server is writen by C++11, and the network io is writen by Boost.Asio. It support rtmp/httpflv/websocket(flv)/webrtc. preinst

Jun 30, 2022
Smartstreaming is a high-performance and scalable streaming media server.

1. introduction Smartstreaming is a high-performance and scalable streaming media server. 2. design | io | Coroutine | | transport | tcp/udp/srt/quic

Jan 7, 2022
Official repository of the ISO Base Media File Format Reference Software

ISO Base Media File Format (ISOBMFF) This repository is the official repository for the ISO Base Media File Format Reference Software. The ISO base me

Nov 15, 2022
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support

Vita-Media-Player An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support 1080i output supported on the PSTV natively and on the

Nov 25, 2022
Video player for 3ds
Video player for 3ds

Video player for 3DS Patch note v1.0.1 Added allow skip frames option v1.0.0 Initial release Summary Video player for 3DS Performance 256x144(144p)@30

Nov 21, 2022
A simple but powerful multimedia player library designed for Qt Quick.

QtMediaPlayer A simple but powerful multimedia player library designed for Qt Quick. Features Full-featured multimedia player Cross-platform: support

Nov 29, 2022
GB Studio Extended Nominal Player Adaptation/Interface
GB Studio Extended Nominal Player Adaptation/Interface

gbsenpai gbsenpai - GB Studio Extended Nominal Player Adaptation/Interface - is a project to port the GB Studio player to additional, non-GB/GBC platf

Oct 24, 2022
Yakuza Arcade Machine Player - play Virtua Fighter 5: Final Showdown on PC, using Yakuza 6 files.
Yakuza Arcade Machine Player - play Virtua Fighter 5: Final Showdown on PC, using Yakuza 6 files.

Yakuza Arcade Machines Player Yakuza Arcade Machines Player is a launcher that allows you to run Virtua Fighter 5: Final Showdown, standalone and nati

Nov 26, 2022
🤟Super fast H.264/H.265 FLV player
🤟Super fast H.264/H.265 FLV player

??Super fast H.264/H.265 FLV player

Dec 7, 2022
simple mp4 player based on rockchip rv1109 platform

mp4player RV1109平台上实现一个简单的 mp4 播放器,主要是本人使用的开发板QT无法播放mp4,应该是没有编译qst所致,因而想利用rockchip平台自有的 功能实现一个简单的播放器。 base目录包含一些基础框架实现,包含信号,线程,时间等,线程和消息泵的实现非常非常简单,因而不

Jul 17, 2022
Implement a universal video player based on FFmpeg

qiaopcmusic 实现一个万能视频播放器 添加依赖方式: To get a Git project into your build: Step 1. Add the JitPack repository to your build file Add it in your root build.

Oct 15, 2021
FFmpeg powered audio player in node.js

sange FFmpeg powered audio player in node.js prerequisites node.js cmake sudo apt install cmake c++ compiler sudo apt install g++ gcc ffmpeg sudo apt

Nov 25, 2022