For some reason, schedule_resize() can be called with everything set to
0. The code couldn't handle wl->window.aspect set to 0, converting NaNs
to integers. Just work this around.
(I have no idea what I'm doing. This is probably a corner case caused
by my broken-ish wayland setup.)
Closing the video window sends CLOSE_WIN, which is normally mapped to
the "quit" command. The client API normally disables all key bindings,
and closing the window does nothing. It's simply left to the application
to handle this. This is fine - an embedded window can not be destroyed
by user interaction.
But sometimes, the window might be destroyed anyway, for example because
the containing window is destroyed. If this happens, CLOSE_WIN should
better not be ignored. We can't expect client API users to handle this
specially (by providing their own input.conf), so provide some fallback
for this pseudo key binding. The "quit" command might be too intrusive
(not every client necessarily handles "unexpected" MPV_EVENT_SHUTDOWN),
but I think it's still reasonable.
Enable asynchronous reading for external files. This excludes subtitle
files (so it's effectively enabled for audio files only), because most
subtitle files are fully read on loading, and running a thread for them
would just cause slowdowns and increase resource usage, without having
any advantages.
In theory, an external file could provide multiple tracks from the same
demuxer, but demux_start_thread() is idempotent, so the code can be
kept simple.
Should help with playing DASH with ytdl_hook.
We must not try to remap channels with this. Whethever ALSA gives us,
and whatever we do with it, the result will probably be nonsense.
Untested, as I don't have the required hardware.
This used to be required to workaround PulseAudio bugs. Even later, when
the bugs were (partially?) fixed in PulseAudio, I had the feeling the
hacks gave better behavior. On the other hand, I couldn't actually
reproduce any bad behavior without the hacks lately. On top of this, it
seems our hacks sometimes perform much worse than PulseAudio's native
implementation (see #1430).
So disable the hacks by default, but still leave the code and the option
in case it still helps somewhere. Also, being able to blame PulseAudio's
code by using its native API is much easier than trying to debug our own
(mplayer2-derived) hacks.
Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into
the build system, instead of defining them over and over in the code.
Conflicts:
video/out/w32_common.c
waftools/checks/custom.py
The function terminal_in_background() reports whether the player was
backgrounded. In this case, we don't want to annoy the user by still
printing the status to stderr. If no terminal interaction is assumed,
this mechanism is disabled, and stderr is always used. The read_terminal
variable signals this case.
Oddly, just redirecting stderr will disable output to stderr, because
the background check with tcgetpgrp() is done on stderr, but
read_terminal is still true (because that one depends on stdin and
stdout).
Explicitly disable this mechanism if --no-input-terminal is used by
setting read_terminal to true only if terminal input is actually
initialized.
No more equals signs for options that don't take values.
Complete values for options with preset choices.
Complete --no-whatever where applicable.
Fixes#997.
Our own code was introduced when FFmpeg didn't provide this API (or
maybe didn't even have a way to determine the CPU count). But now,
av_cpu_count() is available for all FFmpeg/Libav versions we support,
and there's no reason to have our own code.
libavutil's code seems to be slightly more sophisticated than our's, and
it's possible that the detected CPU count is different on some platforms
after this change.
Removes an annoying "No video PTS! Making something up." warning.
Mark it as keyframe, which is needed to prevent strange behavior with
PNG. Also, don't leak the picture data.
Options which take colors accept two variants. The first is "r/g/b/a",
the second is "#AARRGGBB". Since they put alpha at different places,
it's probably better to document the second variant explicitly. (It's a
bit strange that they put alpha in different places, but on the other
hand, it's kind of natural. The second variant should probably be
considered deprecated.)
This is basically a hack; but apparently a needed one, since many
vapoursynth filters insist on having a FPS set.
We need to apply the FPS override before creating the filters. Also
change some terminal output related to the FPS value.
Most of this is explained in the code comments. This change should
improve performance with vapoursynth, especially if concurrent requests
are used.
This should change nothing if vf_vapoursynth is not in the filter chain,
since non-threaded filters obviously can not asynchronously finish
filtering of frames.
Add an explicit "signal" event type, because the implicit one was
confusing.
Don't rescale the Y axis of the second graph, it was nonsense.
Make the legend for the second graph separate (and cleanup the code
creating the graphs).
* bits instead of bytes
* add valid_bits argument
* just pass in the mp_chmap and get the number and wavext channel map from that
* indicate valid bits in waveformat_to_str
* make appropriate accomodations in try_format
Sort the legend by the used y value of binary events/signals, add a way
to filter branches (although that requires editing the script), and use
the full screen if the second subplot is not used.
We certainly don't use the mplayer configuration dir. The name didn't
matter, but now that it's in user-visible output (as part of config.h
being dumped in verbose mode), it's a bit too strange.
It was requested that mpv should print what features etc. have been
enabled at compile time. It can print the configure command line, but it
obviously doesn't include autodetected features.
I tried to think of a nicer way than dumping the config.h as text, but
this was still the simplest way.
Conflicts:
player/main.c
I hoped we could always use libavresample, but the FFmpeg project is
being too dickish to enable libavresample by default - which means we
need our libswresample-to-libavresample hack anyway.
Give up, and use the "supported" one of the duplicated libraries when
compiling against FFmpeg (relying on the fact that libswresample won't
be present if compiling against Libav).
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.
Conflicts:
DOCS/client_api_examples/qml/mpvrenderer.cpp
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().
Conflicts:
player/command.c
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.
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).
Conflicts:
video/out/gl_hwdec_vda.c
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.
Conflicts:
stream/stream_pvr.c
wm4