| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
It's needed for some obscure feature in combination with .rar reading.
However, it's unconditionally used by the subtitle loader code, so take
care of not blocking the main thread unnecessarily.
(Untested.)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Otherwise, it'd retry creating the window all the time.
|
|
|
|
|
| |
This event basically means "something about video changed", and uninit
is certainly an important change.
|
|
|
|
|
|
|
|
| |
Most things should be allowed to access the client API unconditionally
(for example for sending events), so move destroying the client API
down. Also, mp_uninit_ipc() should happen before the point at which all
clients are shutdown, or there will be a small time window in which new
clients can be created after destroying them all.
|
|
|
|
| |
It was a bit ugly/annoying.
|
|
|
|
|
|
|
|
|
|
|
| |
Wether and when the text of a button should be squeezed when it
gets too long can now be configured in the layout:
lo.button.maxchars = <number>
nil = no squeezing (default)
If the button text has more than <maxchars> characters, it will
be squeezed to the estimated width of <maxchars>.
|
| |
|
|
|
|
|
|
| |
It was disabled since the last release, and nobody complained loudly.
Further details see commit 4b5c3ea7.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Doing that doesn't make sense anyway: it's meant for interactive input,
and if the output of the player is not on the terminal, how will you
interact with it?
It was also quite in the way when trying to read verbose output with
e.g. less while the player was running, because the player would grab
half of all input meant for less (simply because stdin is still
connected to the terminal).
Remove the now redundant special-casing of pipe input.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The player was supposed to exit playback if both video and audio failed
to initialize (or if one of the streams was not selected when the other
stream failed). This didn't work; for one this check was missing from
one of the failure paths. And more importantly, both checked the
current_track array incorrectly.
Fix these issues, and move the failure handling code into a common
function.
CC: @mpv-player/stable
|
|
|
|
|
| |
Why not. (I thought I needed this, but my other experiments failed. So
this is merely a minor cleanup.)
|
|
|
|
| |
Let's actually test our code next time.
|
|
|
|
|
| |
Useful for debugging. Considered doing this in command.c, but it's
easier here.
|
|
|
|
|
| |
Useful for debugging and informational purposes. Not sure if it's sane
in any form.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Instead of just disabling the stream.
Also, check if the selected track has the right type, or we'd crash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This is so that the source file name matches the AO name
|
| |
|
| |
|
|
|
|
|
| |
Looks like this will help us with making --audio-device and spdif work
as expected on OSX. To be used ina following commit.
|
|
|
|
| |
Oops.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the list associated with --audio-device is supposed to enable
simple user-selection, it doesn't make much sense to include overly
special things like ao_pcm or ao_null in the list. Specifically,
ao_pcm is harmful, because it will just dump all audio to a file
named audiodump.wav in the current working directory. The user can't
choose the filename (it can be customized, but not through this
option), and the working directory might be essentially random,
especially if this is used from a GUI.
Exclude "strange" entries. We reuse the fact that there's already a
simple list ordered by auto-probe priority in order to avoid having to
add an additional flag. This is also why coreaudio_exclusive was moved
above ao_null: ao_null ends auto-probing and marks the start of
"special" outputs, which don't show up on the device, but we want
coreaudio_exclusive to be selectable (I think).
|
|
|
|
|
|
|
| |
Move it above ao_null, so that it can be selected during auto-probing
(even if it's only last). I see no reason why it should not be included,
and it makes the following commit slightly more elegant. (See
explanations there.)
|
|
|
|
| |
Same as it's done on the terminal.
|
|
|
|
| |
This was always intended. Also fixes subtitle-file drag & drop.
|
|
|
|
|
|
|
| |
Because Lua is so terrible, it's easy to confuse temporary values pushed
to the Lua stack with arguments if the arguments are checked after that.
Add a hack that should fix this.
|
|
|
|
|
|
| |
From: bugmen0t on github
Fixes #1207.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the way video-rotate currently works, the state will be
automatically updated once new video is decoded. So the filter chain
doesn't need to be reinitialized automatically, but there is a need to
trigger the video instant refresh code path instead.
Also move the support function closer to an annoying similar yet
different function. They probably can be unified next time major changes
are done to this code.
|
|
|
|
|
| |
I suspect this clashes with libcs,w hich define "stdout" as macro.
Hopefully fixes #1206.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Blergh. Now needed for --ff-aid and friends.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting subtitle scaling and positioning right even if there are video
filters, which completely change the image (like cropping), doesn't seem
to have a single, correct solution. To some degree, the results are
arbitrary, so we may as well do what is most useful to the user.
In this case, if the PGS resolution aspect ratio and the video output
aspect ratio mismatch, letter-box it, instead of stretching the subs
over the video frame. (This will require additional fixes, should it
turn out that there are PGS subtitles which are stretched by design.)
Fixes #1205.
|
|
|
|
|
|
| |
It assumed that any >\"< sequence was an escape for >"<, but that is not
the case with JSON such as >{"ducks":"\\"}<. In this case, the second
>\< is obviously not starting an escape.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This isn't quite as robust as idet.sh as the default detection
interval is only 4 seconds vs 35 for idet.sh. idet.sh can have such a
large sample time since it turns off the vo and uses --untimed, which
is currently not possible from lua.
|
| |
|
|
|
|
| |
So the user doesn't have to care about the awkward low-level details.
|
| |
|
|
|
|
|
| |
I doubt anyone will actually use this correctly. Also, there was a bug
(a typo) which prevented it from working at all.
|
| |
|
|
|
|
|
| |
Instead of affecting every platform, do this for glibc only (where it's
known to be a problem), and only if the right error is returned.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out the glibc people are very clever and return an error if the
thread name exceeds the maximum supported kernel length, instead of
truncating the name. So everyone has to hardcode the currently allowed
Linux kernel name length limit, even if it gets extended later.
Also the Lua script filenames could get too long; use the client name
instead.
Another strange thing is that on Linux, unrelated threads "inherit" the
name by the thread they were created. This leads to random thread names,
because there's not necessarily a strong relation between these threads
(e.g. script command leads to filter recreation -> the filter's threads
are tagged with the script's thread name). Unfortunate.
|
|
|
|
|
|
|
|
| |
On win32, open() is a function-like macro. The line of code changed
with this commit accidentally expanded the macro. Prevent this macro
expansion. Not sure why that happened now. Since as far as I remember
system functions can be defined as macros, this affects in theory not
only win32.
|
|
|
|
|
|
|
|
|
|
| |
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
|
|
|
|
|
|
| |
Windows doesn't have unix domain sockets, and can't handle sockets and
pipes in an uniform way. Only the libwaio fallback code is available,
which doesn't do JSON.
|
|
|
|
|
| |
This seems safer. It might be possible that commands sent by the clients
could recreate e.g. audio or video outputs.
|
|
|
|
|
|
|
|
| |
This is not realy obvious, so I assume this is a helpful hint.
Although the usefulness of such an approach is probably influenced by
the fact that the player might send events that arrive in the short
window while the socket is connected.
|
| |
|
|
|
|
| |
Minimizes the differences between --input-file and --input-unix-socket.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ipc_thread can exit any time, and will free the mp_ipc_ctx when
doing this, leaving a dangling pointer. This was somewhat handled in the
original commit by setting mpctx->ipc_ctx to NULL when the thread
exited, but that was still a race condition.
Handle it by freeing most things after joining the ipc_thread. This
means some resources will not be freed until player exit, but that
should be ok (it's an exceptional error situation).
Also, actually close the pipe FDs in mp_init_ipc() on another error
path.
|
|
|
|
| |
Just a minor refactor to keep unneeded dependencies on the core low.
|
|
|
|
|
| |
The output is a bit confusing. Quoting the device name probably helps a
little bit; also add minimal explanations to the manpage.
|
| |
|
|\
| |
| | |
lua: fix lua_objlen -> lua_rawlen for lua 5.2
|
|/ |
|
|
|
|
|
|
|
| |
Thanks to the recently introduced mp_lua_PITA(), this is "simple" now.
It fixes leaks on Lua errors. The hack to avoid stack overflows
manually isn't needed anymore, and the Lua error handler will take
care of this.
|
|
|
|
|
|
|
| |
The JSON parser was introduced for the IPC protocol, but I guess it's
useful here too.
The motivation for this commit is the same as with 8e4fa5fc (again).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately,
since Unix is also terrible, this turned out more complicated than I
hoped. As a consequence and to avoid that this code has to be maintained
forever, add a disclaimer that any function in Lua's utils module can
disappear any time. The complexity seems a bit ridiculous, especially
for a feature so far removed from actual video playback, so if it turns
out that we don't really need this function, it will be dropped again.
The motivation for this commit is the same as with 8e4fa5fc.
Note that there is an "#ifndef __GLIBC__". The GNU people are very
special people and thought it'd be convenient to actually declare
"environ", even though the POSIX people, which are also very special
people, state that no header declares this and tha |