I guess this qualifies as trolling. It's becoming increasingly clear
that Microsoft will not be able to deliver on this promise, at least not
in the way they made it seem at first. I'm not sure if Microsoft was the
one who did the trolling, or me. I actually expected that we'd get full
GUI integration of Linux applications including accelerated graphics,
but it was always clear that it wasn't going to work as well as
natively.
In any case, there is no need to frighten any users. The time when you
can run only "Windows Store Apps" on Windows (== the end for mpv and
many other applications on Windows) will come soon enough.
The "faster than native" statement is based on other people's real
experience of software running faster in Linux VMs than native windows
ports, by the way.
MPlayer isn't all too well-known anymore. It does not make sense to
"advertise" with it (and it actually never did).
The GPU comment needed clarification. I think originally, it was just to
signal that you'll have a bad time with Intel. Make that broader.
I don't think MPlayer/mplayer2 and Libav are well-known enough anymore
to warrant such a prominent place in the top-level README file of this
project. It's just useless noise to most users. So I've moved these
things to the FAQ.
Update some other minor things.
I think DASH playback tends to work much better with FFmpeg's DASH
demuxer, which requires libxml2.
For nvdec, FFmpeg git master now requires the external nvidia headers,
since the builtin ones were removed.
Apparently some people want this. Actually making it compile is still
their problem, though, and I expect that build with FFmpeg upstream will
occasionally be broken (as it is right now). This is because mpv also
relies on API provided by Libav, and if FFmpeg hasn't merged that yet,
it's not our problem - we provide a version of FFmpeg upstream with
those changes merged, and it's called ffmpeg-mpv.
Also adjust the README which still talked about FFmpeg releases.
Unfortunately I'm also adding the full text of the LGPL license text,
because the GPL one was already present in this repository, and I don't
want to imply that the GPL somehow has priority.
Now you need FFmpeg git, or something.
This also gets rid of the last real use of gpu_memcpy(). libavutil does
that itself. (vaapi.c still used it, but it was essentially unused,
because the code path isn't really in use anymore. It wasn't even
included due to the d3d-hwaccel dependency in wscript.)
This broke screensaver/powersave inhibition with at least KDE and
LXDE. This is a release blocker.
Since fdo, KDE and GNOME idiots seem to be unable to reach
a consensus on a simple protocol, this seems unlikely to get
fixed upstream this year, so revert this change.
Fixes#4752.
Breaks #4706 but I don’t give a damn.
This reverts commit 3f75b3c343.
It's an ancient X11 protocol extension that apparently nobody uses
anymore (desktop environments in particular have replaced it with
equally bad protocols that require tons of dependencies). Users keep
complaining about it being a required dependency.
The impact is likely minimal to none.
Fixes#4706 and other annoying people.
This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg
git is required. Libav has no release with the new APIs yet, so for
Libav git as of a few weeks or months ago or so is required if you want
to use Libav.
Not much actually changes in hwdec_vaegl.c - some code is removed, but
the reindentation inflates the diff.
Reduces the ifdeffery, which is good and will avoid silent breakages, or
weird behavior if a lib is omitted.
Also reorder the x11_common.c include statements.
We have direct rendering with hardware decoding now (so no SSE4 for
memcpy from GPU memory required), and also OpenGL drivers are not so
much of a problem anymore with ANGLE being default.
We're too lazy to maintain a full changelog, but there are still a bunch
of places which document specific changes. A user really should check
them on each update, even if there are transition periods (including
printing warnings etc.) for most changes. It's a good idea to give them
more exposure by adding them to the README.
We don't support this anymore.
This tries to exit in a controlled way after command line options are
applied in order to honor logging options and, in case of libmpv, not to
kill the host. Not sure if it would be better to just vomit text to
stderr and call abort().
This is actually all bullshit. There are many factors that can ruin the
video playback experience (and most outside of our or the user's
control).
One thing that makes sense is that this declares incompatibility with
Windows XP (fixes#2473).
The Copyright file explains the whole license mess. The earlier change
was apparently confusing, because the link reading "details" merely
linked to the GPLv2 license instead of explaining anything. In fact, I
meant to link to the Copyright file in the first place.