| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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 that the user has to
declare this manually. Since the GNU people overtook the Unix world with
their very clever "embrace, extend, extinguish" strategy, but not 100%,
and trying to build without _GNU_SOURCE is hopeless; but since there
might be Unix environments which support _GNU_SOURCE features partially,
this means that in practice "environ" will be randomly declared or not
declared by system headers. Also, gcc was written by very clever people
too, and prints a warning if an external variable is declared twice (I
didn't check, but I suppose redeclaring is legal C, and not even the gcc
people are clever enough to only warn against a definitely not legal C
construct, although sometimes they do this), ...and since we at mpv hate
compiler warnings, we seek to silence them all. Adding a configure test
just for a warning seems too radical, so we special-case this against
__GLIBC__, which is hopefully not defined on other libcs, especially not
libcs which don't implement all aspects of _GNU_SOURCE, and redefine
"environ" on systems even if the headers define it already (because they
support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote
software THAT portable that other libcs just gave up and implemented
parts of _GNU_SOURCE, although probably not all), which means that
compiling mpv will print a warning about "environ" being redefined, but
at least this won't happen on my system, so all is fine. However, should
someone complain about this warning, I will force whoever complained
about this warning to read this ENTIRE commit message, and if possible,
will also force them to eat a printed-out copy of the GNU Manifesto, and
if that is not enough, maybe this person could even be forced to
convince the very clever POSIX people of not doing crap like this:
having the user to manually declare somewhat central symbols - but I
doubt it's possible, because the POSIX people are too far gone and only
care about maintaining compatibility with old versions of AIX and HP-UX.
Oh, also, this code contains some subtle and obvious issues, but writing
about this is not fun.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the Lua API is a big PITA because it uses longjmp() error
handling. That is, a Lua API function could any time raise an error and
longjmp() to a lower part of the stack. This kind of "exception
handling" is completely foreign to C, and there are no proper ways to
clean up the "skipped" stack frames.
Other than avoiding such situations entirely, the only way to deal with
this is using Lua "userdata", which is basically a malloc'ed data block
managed by the Lua GC, and which can have a destructor function
associated (__gc metamethod).
This requires an awful lot of code (because the Lua API is just so
terrible), so I avoided this utnil now. But it looks like this will make
some of the following commits much easier, so here we go.
|
|
|
|
|
| |
Instead of relying on the macro-defined lseek(), just use _lseeki64
directly, and avoid a minor mess.
|
| |
|
|
|
|
|
|
|
| |
After removing synchronous libdispatch calls, this looks like it doesn't
deadlock anymore. I also experimented with pthread_mutex_trylock liek wm4
suggested, but it leads to some annoying black flickering. I will fallback to
that only if some new deadlocks are discovered.
|
|
|
|
| |
This reverts commit a0ac8b6331d345748d415cf71affbe7a90e336a6.
|
|
|
|
|
|
| |
It's kind of obvious, since the protocol by design has to allow you to
read (loadfile) and write (screenshot_to) random files, but better
make it explicit so that nobody accidentally does something insecure.
|
|
|
|
| |
Exclude the worthless Qt 5.0-only demo code on Qt 4.x.
|
| |
|
|
|
|
|
|
| |
As I understand, otherwise, the code will try to destroy the same
window again in the cleanup part of the gui_thread(), which makes no
sense and is potentially dangerous.
|
|
|
|
|
|
|
|
|
|
|
| |
mp_stat() instead of stat() was used in the normal code (i.e. even
on Unix), because MinGW-w64 has an unbelievable macro-mess in place,
which prevents solving this elegantly.
Add some dirty workarounds to hide mp_stat() from the normal code
properly. This now requires replacing all functions that use the
struct stat type. This includes fstat, lstat, fstatat, and possibly
others. (mpv currently uses stat and fstat only.)
|
|
|
|
|
|
| |
On MingGW seeking on pipes succeeds.
This fix is quite similar to Gnulib's (lib/lseek.c).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Previously we didn't report events to the core, but still prevented the events
to travel on the responder chain.
|
|
|
|
|
| |
Actually doesn't remove the related flags so that one can still pass the
option with the option doing nothing.
|
| |
|
|
|
|
|
|
| |
Generally useless feature, and might be slightly dangerous if paths
can "escape" from the profile dir. (Normally this shouldn't be
possible, though.)
|
|
|
|
|
|
|
|
|
|
| |
Now requires newest libass git. Since this feature wasn't part of a
libass release yet, I'm not bothering making the mpv code compatible
with as how it was previously implemented (it will just be disabled
with any older libass).
CC: @mpv-player/stable (because mpv-build uses libass git, and this
breaks the feature)
|
|
|
|
|
|
|
| |
It possibly goes to sleep without actually starting to decode audio.
Possibly fixes a problem with --no-osc --no-video reported on IRC.
CC: @mpv-player/stable
|
|
|
|
| |
No idea what this was for. It has no purpose and looks weird.
|
|
|
|
|
|
| |
Fixes #1185.
CC: @mpv-player/stable
|
|
|
|
| |
See #1187.
|
|
|
|
|
|
| |
The previous commit was actually incorrect, and the change had
absolutely no effect. The two formats are (fortunately) the same. I'm
probably too tired.
|
|
|
|
|
|
|
|
|
| |
This would have been wrong for hw decoders which pass us NV12 or NV21.
The format the GL shader filter chain gets is stored in p->image_desc,
while p->image_format still contains the "real" input format (which in
case of hw decoding is an opsque hw accel format). Since no hw decoder
did this, this is really just a theoretical fix and doesn't fix any
actual bugs.
|
|
|
|
|
| |
This is slightly safer and without the resize redraw, should not cause any
deadlock.
|
|
|
|
|
|
| |
Otherwise, other magic Qt stuff can be magically broken.
(No, I don't know the real reasons for this.)
|
| |
|
|
|
|
|
| |
Leading percent sign is a quote indicator so it needs to be quoted
itself.
|
|
|
|
| |
This was rejecting correct escapes and accepting incorrect ones.
|
| |
|
|
|
|
| |
The change was made with faad40aad92d51290ef2fc4d94277eca89863873.
|
|
|
|
|
|
|
| |
Could crash when exiting playback in very early stages of
initialization.
CC: @mpv-player/stable
|
|
|
|
|
|
| |
This was probably commented as an oversight. Since the subtitle renderer
was uninitialized on reinitialization anyway, this had no negative
consequences, except a memory on exit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A vague idea to get something similar what libquvi did.
Undocumented because it might change a lot, or even be removed. To give
an idea what it does, a Lua script could do the following:
-- type ID priority
mp.commandv("hook_add", "on_load", 0, 0)
mp.register_script_message("hook_run", function(param, param2)
-- param is "0", the user-chosen ID from the hook_add command
-- param2 is the magic value that has to be passed to finish
-- the hook
mp.resume_all()
-- do something, maybe set options that are reset on end:
mp.set_property("file-local-options/name", "value")
-- or change the URL that's being opened:
local url = mp.get_property("stream-open-filename")
mp.set_property("stream-open-filename", url .. ".png")
-- let the player (or the next script) continue
mp.commandv("hook_ack", param2)
end)
|
|
|
|
|
| |
The intended use-case is for doing this at load time, after the load
command was issued. (See following commit.)
|
|
|
|
|
| |
Seems like this could theoretically happen in low buffer situations, but
I haven't spotted this behavior in the wild.
|
|
|
|
| |
This is already taken care of by Q_DISABLE_COPY().
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, we pass libavformat demuxers a wrapped mpv stream. But in some
cases, such as HLS and RTSP, we let libavformat open the stream itself.
In these cases, set typical network properties like useragent according
to the mpv options.
(We still don't set it for the cases where libavformat opens other
streams on its own, e.g. when opening the companion .sub file for .idx
files - not sure if we maybe should always set these options.)
|
|
|
|
|
|
|
|
| |
Fixes opening some streams.
This means the HLS playlist will be opened twice, but that's not much of
a problem, considering it's pretty small, and HLS will make many other
http accesses anyway.
|
|
|
|
|
|
|
| |
OSD cycling attempted to remove the current message by setting an empty
message with duration 0. Duration 0 tripped up a corner case causing no
OSD to be displayed (until the next message was set), so exclude this
explicitly.
|
|
|
|
|
|
|
| |
Apparently there's an use for this; see #1178.
I won't redocument obscure FFmpeg features, so add a hint to the
manpage that some protocols are documented in FFmpeg instead.
|
| |
|
|
|
|
|
| |
I'm starting to think that being type-strict with this interface
actually sucks. This commit is a step towards being less strict.
|
|
|
|
|
|
|
|
|
| |
This could produce an extra frame, because reaching the maximum merely
signals the playloop to exit, without strictly enforcing the limit.
Fixes #1181.
CC: @mpv-player/stable
|
|
|
|
| |
Forgotten.
|
|
|
|
| |
Pretty dumb oversights.
|
|
|
|
|
|
| |
Dump chapters and track list to the log for demo purposes.
Compile in debug mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides some helper functions and classes for C++/Qt. As the top
of qthelper.hpp says, this is built on top of the client API, and is a
mere helper provided for convenience.
Maybe this should be a separate library, but on the other hand I don't
see much of a point in that. It's also header-only, but C++ people like
such things. This makes it easier for us, because we don't need to care
about ABI compatibility.
The client API doesn't change, but bump it so that those who are using
this header can declare a proper dependency.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also, don't set an empty string for the fallback device if an AO doesn't
list any devices.
|
|
|
|
|
|
|
| |
With some files, the extradata variable can remain uninitialized, but
will be used for memory access.
CC: @mpv-player/stable (with high priority)
|
|
|
|
|
| |
Some filters still (or will) behave badly on these errors, so explicitly
log when it happens.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of letting the window-scale property return the old value until
X11 actually executed the resize, just set the new assumed internal
window size immediately. This avoids a "lag" between setting and reading
the window-scale property, like OSD controls typically do.
Remove the additional calls from vo_x11_highlevel_resize() - they're
pointless and slightly wrong, and resize events will take care of
updating these things correctly anyway.
Fixes #1176.
("window-scale" works via VOCTRL_[S|G]ET_UNFS_WINDOW_SIZE.)
|
|
|
|
|
| |
Not all functions are for creating filters. Consider for example
LoadPlugin.
|
|
|
|
|