| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
As suggested in #1321
|
|
|
|
|
| |
This allows to make mpv wait for file open events at start but close
after it is done playing the first playlist.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If no-block was given, the device would be opened with SND_PCM_NOBLOCK.
Also, after opening, blocking mode was unconditionally enabled anyway
with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK
failed, opening was retried without this flag.
This doesn't make any sense to me, and I've never heard of someone using
this suboption. I suspect it has to do with ancient ALSA bugs or API
caveats. Remove it and simplify the code.
|
|
|
|
|
|
|
|
|
| |
This is an ancient filter, and we assume it's not useful anymore.
If you really want this, it's still available in libavfilter (e.g. via
--vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through
QP information to libavfilter. (This was probably the reason vf_pp still
was part of mpv - it was slightly easier to pass QP internally.)
|
|
|
| |
fixes #1302
|
|
|
|
|
|
|
|
| |
By now, input.conf is actually just a small part of input handling.
Rename the section to something else ("command interface" was the
first reasonable thing that came to mind).
Also fix a minor typo further down.
|
|
|
|
| |
Oops.
|
|
|
|
|
| |
Also update the Lua example. The "pause" event was declared deprecated,
so the example should use the newer API.
|
| |
|
|
|
|
| |
Includes some arbitrary minor refactoring.
|
|
|
|
|
|
|
|
| |
Yep, Lua is so crappy that the stdlib doesn't provide anything like
this.
Repurposes the undocumented mp.format_table() function and moves it to
mp.utils.
|
| |
|
|
|
|
|
|
|
| |
Makeshift-solution for working around certain fontconfig issues.
With --use-text-osd=no, libass and fontconfig won't be initialized, and
fontconfig won't block everything with scanning for fonts.
|
|
|
|
|
| |
Much of it is the same, but now there's the possibility to distinguish
key down/up events in the Lua API.
|
| |
|
|
|
|
| |
For these, autorepeat is enabled.
|
|
|
|
|
|
| |
The fact that it's a generic command prefix that is parsed even when
using the client API is a bit unclean (because this flag makes sense
for actual key-bindings only), but it's less code this way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This command was actually requested on IRC ages ago, but I forgot about
it.
The main purpose is that the decoding state can be reset without issuing
a seek, in particular in situations where you can't seek.
This restarts decoding from the middle of the packet stream; since it
discards the packet buffer intentionally, and the decoder will typically
not output "incomplete" frames until it has recovered, it can skip a
large amount of data.
It doesn't clear the byte stream cache - I'm not sure if it should.
|
|
|
|
|
|
|
|
|
| |
It's passed with the '--format' option to youtube-dl.
If it isn't set, we don't pass '--format best' so that youtube-dl can
use the options from its configuration file.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This was requested on IRC.
|
| |
|
|
|
|
|
|
| |
As suggested in #1241; to make using the feature easier.
Also add better OSD-formatting for the ab-loop-a/b properties.
|
|
|
|
|
|
|
|
|
|
| |
This sub-option was turned into a flag when the sub-option parser was
changed to the generic one (probably accidentally). Turn it into a
proper choice-option.
Also, adjust what the options do. Though none of this probably makes
much sense; the default should work, and if it doesn't, the GPU/driver
is probably beyond help.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Probably needs to be polished a bit more. Also, might require a key
binding that can set/clear the loop points in a more intuitive way.
For now, something like this can be put into input.conf to use it:
ctrl+y set ab-loop-a ${time-pos} # set A
ctrl+x set ab-loop-b ${time-pos} # set B
ctrl+c set ab-loop-a no # clear (mostly)
Fixes #1241.
|
|
|
|
|
|
|
|
| |
Due to the current code structure, the "current" entry and the entry
which is playing can be different. This is probably silly, but still
try to mark the entries correctly.
Refs #1260.
|
|
|
|
|
|
|
|
| |
This actually doesn't even write/return the new sub-property, because
I dislike the idea of dumping that field for every single playlist
entry, even though it's "needed" only for one.
Fixes #1260.
|
|
|
|
| |
Apparently this is confusing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the changes started in commit c827ae5f more eloborate, and provide
an option to control the amount of data read before the seek-target. To
achieve this, rewrite the loop that finds the lowest still acceptable
target cluster. It is now searched by time instead of file position. The
behavior (both with and without preroll option) may be different from
before this change, although it shouldn't be worse.
The change demux_mkv_read_cues() fixes a bug: when seeking after playing
normally, the code would erroneously assume that durations are set. This
doesn't happen if the first operation after loading was a seek instead
of playback.
|
| |
|
|
|
|
|
|
|
| |
This might be interesting for GUIs and such.
It's probably still a little bit insufficient. For example, the filter
and audio/video output lists are not available through this.
|
| |
|
|
|
|
|
| |
It seems strange that a client API user can't get this string, other
than analyzing the mpv log output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Following the discussion in #1253.
The events won't be removed for a while, though. (Or maybe never, unless
we run out of bits for the uint64_t event mask.)
This is not a real change (the events still work, and the alternative
mechanisms were established a few API revisions earlier), but for the
sake of notifying API users, update DOCS/client-api-changes.rst.
|
|
|
|
| |
Can be useful for certain scripts; I think someone requested this.
|
|
|
|
|
|
| |
The main need I see for this is with libmpv - it would be confusing if
some application showed up as "mpv" on whateverthehell PulseAudio uses
it for (generally it does show up on various PA GUI tools).
|
|
|
|
|
|
|
| |
Call VOCTRL_GET_DISPLAY_NAMES it when the property is
requested. The vo should return the names of the displays that the mpv
window is covering. For example, with x11 vos, xrandr names LVDS1,
HDMI1, etc.
|
|
|
|
|
|
| |
More or less requested by #1237.
Should be simple to extend this to other backends.
|
|
|
|
| |
A client API user has no other way to know the version.
|
|
|
|
|
|
|
|
| |
Note that you can't pass .cue or .edl files to it, at least not yet.
Requested in context of allowing to specify custom chapters. For that
to work well, we probably need to add some sort of chapter metadata
pseudo-demuxer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the --playlist option is no longer recommended.
A while ago, mpv rewrote all playlist parsers and added some minimal
security mechanisms (like not allowing local file access or unsafe
protocols in remote playlists). Further, mpv can load playlists by
passing them as normal file arguments, without the option.
Now, --playlist is needed only in these situations:
1) loading plaintext files
2) disabling additional security mechanisms
(e.g. using a remote playlist to play local files)
|
|
|
|
|
| |
The receiving part was implemented, but since no messages are enabled
by default, it couldn't be used.
|
| |
|
| |
|
|
|
|
|
| |
Rename the variable, update comments, and update the documentation of
the property which returns its value.
|
|
|
|
|
| |
Hopefully less confusing, and hopefully doesn't exceed the terminal
width in any situation.
|
|
|
|
| |
This sounds much more intuitive, while "empty" was a bit of a WTF.
|
|
|
|
|
|
| |
This is probably what libmpv users want; and it also improves error
reporting (or we'd have to add a way to communicate such mid-playback
failures as events).
|
|
|
|
| |
Documents the behavior introduced with the previous commit.
|
|
|
|
| |
Meant for changing the --audio-device at runtime.
|
|
|
|
|
| |
Anticipated use: simple solution for dealing with audio APIs which
request configuration changes via events.
|
| |
|
|
|
|
|
|
| |
At least on my machine, reading back the frame with system memcpy is
slower than just using software rendering. Use the optimized gpu_memcpy
from LAV to speed things up.
|
|
|
|
|
|
|
|
|
|
|
| |
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
|
|
|
|
|
| |
Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug
it yourself.
|
| |
|
|
|
|
|
|
|
|
|
| |
So a client API user can know when a window is created or destroyed.
Also might be useful for the OSC: it could disable itself if video is
disabled.
Before this commit, there were only indirect ways of detecting this.
|
|
|
|
|
| |
Wider vertical margins, slightly thicker border and larger font
size should be an improvement.
|
|
|
|
|
| |
This avoids reloading a subtitle if it was already added. In all cases,
the subtitle is selected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some rationale for the documented/suggested behavior:
It's not really clear what to do with invalid UTF-8, since JSON simply
can't transport this information. Maybe you could transfer such strings
as byte arrays, but that would be very verbose and inconvenient, and
would pose the problem that it's hard to distinguish between strings
encoded in this way and actual arrays.
There are many other ways how this could be handled. For example, you
could replace invalid sequences with '?'. Or you could do it like
Python, and use certain reserved unicode codepoints to "tunnel" through
invalid bytes.
Which of these works really depends on the application. And since this
can be done entirely on the byte level (invalid UTF-8 sequences can
appear only in strings in our case), it's best to leave this to the
receiver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assume mpv.exe is located in $mpv_exe_dir, then config files were
preferably loaded from "$mpv_exe_dir/mpv". This was mostly traditional,
and inherited from MPlayer times.
Reverse the config path priority order, and prefer $CSIDL_APPDATA/mpv as
main config path. This also fixes behavior when writing watch_later
configs, and mpv is installed in a not-writable path.
It's possible that this will cause regressions for some users, if the
change in preference suddenly prefers stale config files (which may
happen to longer around in the appdata config dir) over the user's
proper config.
Also explicitly document the behavior.
|
| |
|
|
|
|
|
|
|
|
|
| |
The behavior of reverse cycling (with the "!reverse" magic value) was a
bit weird and acted with a "delay". This was because the command set the
value the _next_ command should use. Change this and make each command
invocation select and use the next command directly. This requires an
"uninitialized" special index in the counter, but that is no problem at
all.
|
|
|
|
|
|
|
|
|
|
|
| |
Allows properly changing/updating the cursor state. Useful for client
API window embedding, because the host application may not want the mpv
window to grab mouse input, and this has to manually handle the cursor.
Changing the cursor of foreign windows is usually not sane.
It might make sense to allow changing the cursor icon, but that would be
much more complicated, so I won't add it unless someone actually
requests it.
|
|
|
|
| |
Now this is obscure.
|
| |
|
|
|
|
|
|
|
|
|
| |
Apparently using the stream index is the best way to refer to the same
streams across multiple FFmpeg-using programs, even if the stream index
itself is rarely meaningful in any way.
For Matroska, there are some possible problems, depending how FFmpeg
actually adds streams. Normally they seem to match though.
|
| |
|