The examples simple.c and cocoabasic.m can be compiled without
installing libmpv. But also, they didn't use the correct include path
libmpv programs normally use, so they couldn't be built with a properly
installed system-libmpv. That's pretty bad for examples, which are
supposed to show how to use libmpv correctly.
So do some bullshit that symlinks libmpv to a "mpv" include directory
under the build directory. This name-mismatch is a direct consequence of
the bullshit done in 499a6758 (requested in #539 for dumb reasons). (We
don't want to name the client API headers directory "mpv", because that
would be too unspecific, and clashes with having the mpv binary in the
same directory.)
If you have spaces or other "unusual" characters in your paths, the
build will break, because I couldn't find out where waf hides its
function to escape shell parameters (or a way to invoke programs
without involving the shell). Neither does such a thing to be
documented, nor do they seem to have a clear way to do this in
their code.
This also doesn't compile the Qt examples, because everything becomes
even more terrible from there on.
C++ is the worst language ever, and allows throwing any type, even if it
doesn't make sense. In this case, we were throwing char*, which the
runtime typically treats as opaque, instead of printing it as message if
such an exception was not caught.
Do so by using mp_subprocess(). Although this uses completely different
code on Unix too, you shouldn't notice a difference. A less ncie thing
is that this reserves an entire thread while the command is running
(which wastes some memory for stack, at least). But this is probably
still the simplest way, and the fork() trick is apparently not
implementable with posix_subprocess().
If the stdout or stderr write callback is NULL, then don't redirect this
stream. Preparation for the next commit.
Not sure what to do on Windows; it seems STARTUPINFO doesn't allow
redirection only one of them. So just let them write nothing. For our
intended use-case (next commit), this is probably sensible.
This is only needed for switching video track with `_`, since Cocoa
automatically handles cleaning up the application's presentation options when
quitting the process.
Fixes#1399
Tags keys are case-insensitive. Before commit 8048374a, the casing of
whatever FFmpeg returned was used (it was quite random). But since the
change, the values in --display-tags decides. Consider this an
accidental feature, and make the output nicer by capitalizing
the tag names.
The way we use rectangle textures (required by VDA for no reason) works
onl in OpenGL 3.0 or higher. Below that, the shader will fail to
compile. We could add support for older OpenGL versions, but that would
be a major pain.
This normally doesn't matter; mpv itself always creates OpenGL 3.2
contexts on OSX. But it could matter if a client API user uses
vo_opengl_cb, and gives it a 2.1 context (which OSX also allows you to
create).
This may or may not be useful for client API users.
Fold this API extension into the previous API bump. The previous bump
was only yesterday, so it's ok.
Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could
make the whole thing to explode. The API user was asked to avoid such
situations by calling it only in "good moments". But this was probably a
bit too subtle and could easily be overlooked.
Integrate the approach the qml example uses directly into the
implementation. If the OpenGL context is to be unitialized, forcefully
disable video, and block until this is done.
For some codecs, we need to invoke a codec parser (because libavcodec
will run into trouble otherwise). This was done based on the Matroska
codec field.
But this ignores handling of vfw-muxed files, which use a pseudo-codec
to signal presence of vfw structures, which we must unmangle to get the
real codec. Handle this by rearranging the code.
This fixes at least mp3-in-mkv for vfw-muxed files; typically old files.
Creating a plain Handle() should yield a NULL mpv_handle.
Also, remove the redundant non-const definition of the conversion
operator. At least in this situation it's not needed.
Also, add include guards around qthelper.hpp.
Use queued signals instead of QEvent for the wakeup notification. This
is slightly nicer, and reduces the chance that the event (QEvent::User)
could clash with other code using the same event.
Also switch to modern connect() syntax.
Destruction (e.g. when closing the window) was a bit broken. This commit
fixes some possible crashes, and should make lifetime management
relatively sane. (Still a bit complex, though. Maybe this code should be
moved into a tiny library.)
QtQuick runs the renderer on a separate thread. This thread is rather
loosely connected to the main thread. The loose separation is enforced
by the API, which also makes coordination of initialization and
destruction harder. Throw refcounting at the problem, which fixes it.
The refcounting wrapper introduced in the previous commit is used for
this.
Also contains some general cleanups.
If a filter exists, but has no metadata, just return success. This
allows the user to distinguish between no metadata available, and filter
not inserted.
See #1408.
This message can happen a lot for mkv files which index clusters in the
seekhead (which is also broken non-sense, but that's a different story).
Also remove a duplicate define from matroska.h.
There's no reason why parts of this demuxer would be in a separate
source file. The existence of this code is already somewhat questionable
anyway, so it may as well be dumped into a single file.
Even stranger that demux.c included mf.h for no reason (it was an
artifact from 2002 when the architecture was uncleaner).
This attempts to increase user-friendliness by excluding useless tags.
It should be especially helpful with mp4 files, because the FFmpeg mp4
demuxer adds tons of completely useless information to the metadata.
Fixes#1403.
Until now, these options took effect only at program start. This could
be confusing when e.g. doing "mpv list.m3u --shuffle". Make them always
take effect when a playlist is loaded either via a playlist file, or
with the "loadlist" command.
This message is printed when the audio device advertised a channel map,
but couldn't set it - which is probably a dmix bug (we'll never know,
ALSA doesn't take bug reports).
Print the requested map, so that the user (maybe) can make a connection
when seeing the message and the actually used channel map, which might
be less confusing. Or at least less useless.
Instead of just failing during channel map selection, try to select a close
layout that makes most sense and upmix/downmix to that instead of failing AO
initialization. The heuristic is rather simple, and uses the following steps:
1) If mono is required always prefer stereo to a multichannel upmix.
2) Search for an upmix that is an exact superset of the required channel map.
3) Search for a downmix that is the exact subset of the required channel map.
4) Search for either an upmix or downmix that is the closest (minimum difference
of channels) to the required channel map.
The details of the non-linear transformation from/to BT.2020's constant
luminance system don't really make sense with any other gamma curve,
since changing the gamma curve completely breaks the chroma channels.
Apparently this is what users would expect.
Going the way of least resistance (in terms of messing with this old,
rarely used code), sorting them by some kind of addition timestamp
(called priority in the patch) is the easiest.
Fixes#1390.
On uninitialization, the player will unselect all subtitles, and then
destroy the subtitle decoder. But it didn't correctly remove the
subtitle decoder from the OSD state, so it could happen that it would
access it after the decoder was destroyed.
Could lead to random crashes when switching files often.
Fixes#1389.
