| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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 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 output is a bit confusing. Quoting the device name probably helps a
little bit; also add minimal explanations to the manpage.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Previously we didn't report events to the core, but still prevented the events
to travel on the responder chain.
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Otherwise, other magic Qt stuff can be magically broken.
(No, I don't know the real reasons for this.)
|
| |
|
|
|
|
| |
The change was made with faad40aad92d51290ef2fc4d94277eca89863873.
|
|
|
|
|
| |
The intended use-case is for doing this at load time, after the load
command was issued. (See following commit.)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Forgotten.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows mpv's view to take key and send events to mpv's core.
To set key status correctly, clients must call -[NSWindow selectNextKeyView:]
during reconfig on the main thread. All is 'documented' in the cocoabasic
example.
If someone knows a better way to handle giving key to the embedded view,
let me know!
|
|
|
|
| |
This is the Lua equivalent of mpv_command_node().
|
|
|
|
|
|
|
|
|
| |
Allows passing native types as arguments.
Also some minor doc improvements, including giving some (natural)
improvements to mpv_free_node_contents().
Note: mpv_command_node_async() is completely untested.
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 45c8b97efbaff7a5031b008223eeed56f7b0607a.
Some else complained (github issue #1163).
The feature requested in #1148 will be implemented differently in
the following commit.
|
|
|
|
|
|
| |
The event monitor is used to get keyboard events when there is no window, but
since it is a global monitor to the current process, we don't want it in a
library setting.
|
|
|
|
|
|
|
| |
After @frau's split of macosx_events from macosx_application, `is_cplayer' is
not needed anymore. At the moment only global events such as Media Keys and
Apple Remote work, because the VO-level ones were hardcoded to be disabled.
(that will be fix in a later commit ).
|
|
|
|
| |
Add closing ">" and specify what is the default value.
|
|
|
|
|
|
|
| |
Not sure how good of an idea this is.
This commit doesn't add support for this to any AO yet; the AO
implementations will follow later.
|
|
|
|
| |
In particular, add a basic description of how Cocoa embedding works.
|
|
|
|
|
| |
Apparently we need this for Cocoa too. (The option was X11 specific in
the hope that only X11 would need this hack.)
|
|
|
|
|
| |
Basically add if guards on all the problematic features. I'm still thinking
about a better way to handle this, but for the time being, this will do.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Maybe using strings for log levels was a mistake (too broad and too
impractical), so I'm adding numeric log level at least for the receiver
side. This makes it easier to map mpv log levels to other logging
systems.
I'm still too stingy to add a function to set the log level by a numeric
value, though.
The numeric values are not directly mapped to the internal mpv values,
because then almost every file in mpv would have to include the client
API header.
Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
|
|
|
|
|
|
|
|
| |
For the purpose of demonstration.
Also make the windows larger. I'm not exactly sure how Qt determines
the default window sizes, but here they are a bit tiny, so force them
larger.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The API could return partial lines, meaning the message could stop
in the middle of a line, and the next message would have the rest of
it (or just the next part of it). This was a pain for the user, so do
the nasty task of buffering the lines ourselves.
Now only complete lines are sent. To make things even easier for the
API user, don't put multiple lines into a single event, but split them.
The terminal output code needed something similar (inserting a prefix
header on start of each line). To avoid code duplication, this commit
refactors the terminal output so that lines are split in a single
place.
|
| |
|
|
|
|
|
|
|
|
| |
Whether you consider the semantics weird or not depends on your use
case, but I suppose it's a bit confusing anyway. At this point, we keep
MPV_EVENT_PAUSE/UNPAUSE for compatibility only.
Make the "core-idle" property somewhat more useful in this context.
|
|
|
|
|
|
|
| |
QApplication sets the locale, so change the LC_NUMERIC category back to
"C" for libmpv.
See: http://qt-project.org/doc/qt-5/qcoreapplication.html#locale-settings
|
|
|
|
|
|
|
|
|
|
|
| |
Now any action that stops playback of a file (even playlist navigation)
will save the position. Normal EOF is of course excluded from this, as
well as commands that just reload the current file.
The option name is now slightly off, although you could argue what the
word "quit" means.
Fixes #1148 (or at least this is how I understood it).
|
|
|
|
|
|
|
| |
This is the first of a series of commits that will change the Cocoa way in a
way that is easily embeddable inside parent views. To reach that point common
code must avoid referencing the parent NSWindow since that could be the host
application's window.
|
|
|
|
| |
credits: wm4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just temporary code but is a good base for future work (and baby
steps are required for these changes). The 'final destination' is embedding
the video view into any NSView but that requires some more work (the mechanism
will be the same: pass the view's pointer casted to int64_t through -wid).
For instance we will need to remove as much usage of the window instance
as possible, and use nil guards where not possible. For this reason I will
remove stuff like the mission control fullscreen feature (it's a cute feature
but annoying to support and quite limited, go make your GUIs), and a way to
lookup the current screen directly from the NSView absolute coordinates
(this is needed for ICC detection mostly, and reporting back the screen to
mpv's core).
Moreover the current view.m will need to be separated into 2 views: the actual
video view that will be embedded, and a parent view that will not be embedded
and will be responsibile for tracking events.
|
|
|
|
|
| |
Cocoa expects the you instance NSApplications only through the singleton
method sharedApplication.
|
| |
|
| |
|
| |
|
|
|
|
| |
Seems silly, but was requested.
|
|
|
|
| |
Merge duplicate entries, organize entries in subsections, reword some entries.
|
|
|
|
|
|
|
|
| |
--x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto
(detect whether NetWM fullsctreen support is available) is the old
behavior and still the default.
See #888.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
--lua-opts is a key-value list, so the option parser accepts only commas.
Signed-off-by: wm4 <wm4@nowhere>
CC: @mpv-player/stable
|
|
|
|
|
|
|
|
|
| |
For the sake of libmpv. Might make things much easier for the user,
especially on Windows. On the other hand, it's a bit sketchy that a
command exists that makes the player access arbitrary memory regions.
(But do note that input commands are not meant to be "secure" and never
were - for example, there's the "run" command, which obviously allows
running random shell commands.)
|
|
|
|
|
|
|
|
|
|
| |
Use percent-pos instead, which is exactly the same, except with the
range 0.0-100.0.
I'm not sure how this got there; it was probably introduced and then
removed again as percent-pos got more precise.
CC: @mpv-player/stable
|
|
|
|
|
| |
Fixes #1131.
CC: @mpv-player/stable
|
|
|
|
|
|
|
| |
Apparently this is what users want. When playing with normal speed,
nothing is done. When playing slower than normal, resampling is used
instead, because scaletempo (which does the pitch correction) adds
too many artifacts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This would play some silence in case video was slower than audio. If
framedropping is already enabled, there's no other way to keep A/V
sync, short of changing audio playback speed (which would give worse
results). The --audiodrop option inserted silence if there was more
than 500ms desync.
This worked somewhat, but I think it was a silly idea after all. Whether
the playback experience is really bad or slightly worse doesn't really
matter. There also was a subtle bug with PTS handling, that apparently
caused A/V desync anyway at ridiculous playback speeds.
Just remove this feature; nobody is going to use it anyway.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
| |
The intention was to adjust the window size to video size. It never
worked well; it prevented the user to make the window smaller. For
unknown reason it stopped resizing properly as well.
This is just a cheap example, and I don't intend to fight with Qt, so
replace the "demonstration" behavior by something slightly lamer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
|