| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Not sure about these deep path-names. Maybe "metadata/0" should work
instead of "metadata/list/0". I'm so unsure about it, that I'm leaving
it open.
|
|
|
|
|
|
| |
The old way still works, and is fine to use. Still discourage it,
because it might conflict with other ways to access this property, such
as the one added in the next commit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a regression introduced from moving Lua scripts (including the
OSC) to their own threads. Now OSC and dvdnav can add their bindings at
the same time without coordination, which seems to result in the OSC
winning most time, and thus overriding the dvdnav menu bindings.
Fix this by adding a flag that makes dvdnav menu bindings take priority
over all other bindings.
|
| |
|
| |
|
|
|
|
|
|
| |
When timeline was used, and the --start option was not used, the initial
seek (needed to switch to the first timeline segment) seeked to -1 due
to an oversight.
|
|
|
|
|
|
| |
Example see edl-mpv.rst.
What is this useful for? No clue...
|
|
|
|
|
| |
Basically, chapter marks and chapter seek-points were incorrect, while
the rest worked.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was already an undocumented mechanism provided by
mp.set_key_bindings and other functions, but this was relatively
verbose, and also weird. It was mainly to make the OSC happy (including
being efficient and supporting weird corner cases), while the new
functions try to be a bit simpler.
This also provides a way to let users rebind script-provided commands.
(This mechanism is less efficient, because it's O(n^2) for n added key
bindings, but it shouldn't matter.)
|
|
|
|
|
| |
This comes with a "script_message" input command, which sends these
messages. Used by the following commits.
|
|
|
|
|
| |
E.g. ``mp.get_property("foo", "value")`` will return ``value`` if the
property can't be read.
|
|
|
|
|
| |
Nobody will loom at this, and the proper documentation of these
functions is in lua.rst.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This uses the previously added sub-property mechanism to export a bunch
of stuff. For example, "video-params/w" now contains the video width.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
|
|
|
|
| |
This is like passing them to --lua.
|
|
|
|
|
|
|
|
| |
Instead, chain them.
Note that there's no logic to prevent the other event handlers to be run
from an event handler (like it's popular in GUI toolkits), because I
think that's not very useful for this purpose.
|
|
|
|
|
|
|
|
|
|
| |
In particular, this affects drag & drop of subtitles, which uses sub_add
internally. This will make the subtitles show up immediately, instead of
requiring manual selection of the added subtitle.
Might be not so ideal when adding multiple subtitles at once, because
that leads to multiple sub_add commands, and will end up with the last
subtitle instead of the first selected. But this is a minor detail.
|
|
|
|
| |
This crashed when retrieving the raw property value. Oops.
|
|
|
|
|
|
|
|
| |
The initialization code was split and refactored for the libmpv changes.
One change, moving a part of cocoa initialization, accidentally broke
--force-window on OSX, which creates a VO in a certain initialization
stage. We still don't know how cocoa should behave with libmpv, so fix
this with a hack to beat it back into working. Untested.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Return the error Lua-style, instead of raising it as Lua error. This is
better, because raising errors is reserved for more "fatal" conditions.
Pretending they're exceptions and trying to do exception-style error
handling will just lead to pain in this language.
|
|
|
|
|
|
|
|
|
| |
send_command -> command
send_commandv -> commandv
get_timer -> get_time
property_get -> get_property
property_get_string -> get_property_osd
getopt -> get_opt
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This library will export the client API functions.
Note that this doesn't allow compiling the command line player to link
against this library yet. The reason is that there's lots of weird stuff
required to setup the execution environment (mostly Windows and OSX
specifics), as well as things which are out of scope of the client API
and every application has to do on its own. However, since the mpv
command line player basically reuses functions from the mpv core to
implement these things, it's not very easy to separate the command
line player form the mpv core.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is partial only, and it still accesses some MPContext internals.
Specifically, chapter and track lists are still read directly, and OSD
access is special-cased too.
The OSC seems to work fine, except using the fast-forward/backward
buttons. These buttons behave differently, because the OSC code had
certain assumptions how often its update code is called.
The Lua interface changes slightly.
Note that this has the odd property that Lua script and video start
at the same time, asynchronously. If this becomes an issue, explicit
synchronization could be added.
|
|
|
|
|
|
|
| |
Add a client API, which is intended to be a stable API to get some rough
control over the player. Basically, it reflects what can be done with
input.conf commands or the old slavemode. It will replace the old
slavemode (and enable the implementation of a new slave protocol).
|
|
|
|
|
|
|
|
|
|
| |
This avoids trouble if another mpv instance is initialized in the same
process.
Since timeBeginPeriod/timeEndPeriod are hereby not easily matched
anymore, use an atexit() handler to call timeEndPeriod, so that we
can be sure these calls are matched, even if we allow multiple
initializations later when introducing the client API.
|
|
|
|
|
| |
Mostly useful for internal reasons. This code will be enabled by
default if mpv is started via the client API.
|
|
|
|
|
|
|
|
| |
This sometimes happened when changing playback speed (= reinitializing
audio) after seeking of playback start. The assertion in audio.c:441 was
triggered, because buffer_playable_samples wasn't reset correctly when
the audio buffer was cleared or shortened. The assertion is correct and
should hold up any time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of printing lines like:
Demuxer info GENRE changed to Alternative Rock
Just output all tags once they change. The assumption is that individual
tags rarely change, while all tags change in the common case.
This changes tag updates to use polling. This could be fixed later,
although the ICY stuff makes it a bit painful, so maybe it will remain
this way.
Also remove DEMUXER_CTRL_UPDATE_INFO. This was intended to check for tag
updates, but now we use a different approach.
|
|
|
|
| |
Apparently, at least sub_reload was missing a refresh at all.
|
|
|
|
|
| |
Instead of trying to be clever to avoid outputting redundant
information, simply output everything that we have.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows applications that use LoadLibrary are vulnerable to DLL
preloading attacks if a malicious DLL with the same name as a system DLL
is placed in the current directory. mpv had some code to avoid this in
ao_wasapi.c. This commit just moves it to main.c, since there's no
reason it can't be used process-wide.
This change can affect how plugins are loaded in AviSynth, but it
shouldn't be a problem since MPC-HC also does this and it's a very
popular AviSynth client.
|
|
|
|
|
|
|
|
|
|
| |
Enable the terminate-on-corruption feature. This is recommended for new
Windows applications and shouldn't cause a performance hit. It actually
shouldn't change anything for 64-bit builds, since Win64 has this
switched on by default.
See:
http://blogs.msdn.com/b/michael_howard/archive/2008/02/18/faq-about-heapsetinformation-in-windows-vista-and-heap-based-buffer-overruns.aspx
|
|
|
|
|
|
| |
Windows users expect this when a program crashes. Without it, the
program just disappears. Also change the SetErrorMode call to use macros
instead of a hardcoded constant.
|
|
|
|
|
|
|
|
|
|
|
| |
If there's more than one edition, print the list of editions, including
the edition name, whether the edition is selected, whether the edition
is default, and the command line option to select the edition. (Similar
to stream list.)
Move reading the tags to a separate function process_tags(), which is
called when all other state is parsed. Otherwise, that tags will be lost
if chapters are read after the tags.
|
|
|
|
|
| |
Paths passed to the --lua option now follow the convention for paths
starting with ~ documented in mpv.rst.
|
| |
|
|
|
|
| |
This made seeking show an empty progbar if --osd-level=0 was used.
|
|
|
|
| |
Caused by the OSD changes. Fixes #490.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque
While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.
All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
|
|
|
|
|
|
| |
These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)
|
|
|
|
|
|
|
|
|
|
|
| |
If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.
But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
|
|
|
|
|
|
|
|
| |
Showing subtitles on terminal used the OSD message stack (which uses a
stack to "pile up" messages that were displayed at the same time). This
had a bunch of weird and annoying consequences. This accessed a certain
osd_state field, which is a minor annoyance since I want to make that
struct opaque. Implement this differently.
|
|
|
|
|
|
|
| |
The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
|
|
|
|
|
|
| |
When the Lua code was written, the core didn't have names for log levels
yet (just numbers). The only user visible change is that "verbose"
becomes "v", since this level had different names.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
|
|
|
|
|
| |
While almost everything uses msg.h, the moved definitions are rarely
needed by anything.
|
|
|
|
| |
Why didn't I put it there from the start?
|
|
|
|
| |
With the old code and pos == width - 2 one character too many is drawn.
|
|
|
|
|
| |
If the terminal width is large enough the position marker jumps over
several characters because currently pos only increases in 1/100th steps.
|
|
|
|
| |
... to decide wether the seekbar should be enabled or not.
|
|
|
|
|
|
|
| |
Before that, it just returned -1.
The print case is inconsistent with that, but I'll leave it for now,
because it's consistent with status line / show_progress behavior.
|
|
|
|
|
| |
Feature request from github issue #451. Disabled by default, will
probably stay this way.
|
|
|
|
| |
Apparen |