Commit Graph

24 Commits

Author SHA1 Message Date
wm4 f13266014f client API: add glue for making full use of mpv_command_node()
Until now, the return value was always MPV_FORMAT_NONE. Now a command
can actually set it. This will be used in one of the following commits.
2015-04-20 23:00:12 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 04472352ae player: fix audio-device-list updates
The way the AO wakes up the playloop has nothing to do with events;
instead we must query the events on the AO once the playloop was woken
up. Querying the events in every playloop iteration is thus the correct
way to do this.
2015-02-14 15:13:58 +01:00
Stefano Pigozzi 70802d519f ao_coreaudio: add support for hotplug notifications
This commit adds notifications for hot plugging of devices. It also extends
the old behaviour of the `audio-out-detected-device` property which is now
backed by the hotplugging code. This allows clients to be notified when the
actual audio output device changes.

Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's
device selection code is a bit fragile.
2015-02-14 12:51:15 +01:00
wm4 f061befb33 audio: add device change notification for hotplugging
Not very important for the command line player; but GUI applications
will want to know about this.

This only adds the internal API; support for specific audio outputs
comes later.

This reuses the ao struct as context for the hotplug event listener,
similar to how the "old" device listing API did. This is probably a bit
unclean and confusing. One argument got reusing it is that otherwise
rewriting parts of ao_pulse would be required (because the PulseAudio
API requires so damn much boilerplate). Another is that --ao-defaults is
applied to the hotplug dummy ao struct, which automatically applies such
defaults even to the hotplug context.

Notification works through the property observation mechanism in the
client API. The notification chain is a bit complicated: the AO notifies
the player, which in turn notifies the clients, which in turn will
actually retrieve the device list. (It still has the advantage that it's
slightly cleaner, since the AO stuff doesn't need to know about client
API issues.)

The weird handling of atomic flags in ao.c is because we still don't
require real atomics from the compiler. Otherwise we'd just use atomic
bitwise operations.
2015-02-12 17:17:41 +01:00
wm4 720eb187fd command: send additional property change events in-between loading
Opening the stream and opening the demuxer are both done asynchronously,
meaning the player reacts to client API requests. They also can
potentially take a while. Thus it's better to process outstanding
property changes, so that change events are sent for properties that
were changed during opening.
2015-02-01 18:25:12 +01:00
wm4 64f72687ce client API: notify API user on event queue overflow
Before this, we merely printed a message to the terminal. Now the API
user can determine this properly. This might be important for API users
which somehow maintain complex state, which all has to be invalidated if
(state-changing) events are missing due to an overflow.

This also forces the client API user to empty the event queue, which is
good, because otherwise the event queue would reach the "filled up"
state immediately again due to further asynchronous events being added
to the queue.

Also add some minor improvements to mpv_wait_event() documentation, and
some other minor cosmetic changes.
2015-01-19 21:26:42 +01:00
wm4 416c86f3cb command: add window-minimized property (X11 only)
More or less requested by #1237.

Should be simple to extend this to other backends.
2014-11-02 20:55:07 +01:00
wm4 4e2574f025 command: make window-scale property observable
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.

(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
2014-11-02 20:53:56 +01:00
wm4 b79f291f4b command: remove hook cancellation mechanism
I doubt anyone will actually use this correctly. Also, there was a bug
(a typo) which prevented it from working at all.
2014-10-20 23:43:10 +02:00
wm4 8e4fa5fcd1 command: add a mechanism to allow scripts to intercept file loads
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)
2014-10-16 01:00:22 +02:00
wm4 733bdebcb9 client API: minor optimizations for property notification
Internally, there are two mechanisms which can trigger property
notification as used with "observed" properties in the client API.

The first mechanism associates events with a group of properties that
are potentially changed by a certain event. mp_event_property_change[]
declares these associations, and maps each event to a set of strings.
When an event happens, the set of strings is matched against the list of
observed properties of each client. Make this more efficient by
comparing bitsets of events instead. This way, only a bit-wise "and" is
needed for each observed property. Even better, we can completely skip
clients which have no observed properties that match.

The second mechanism just updates individual properties explicitly by
name. Optimize this by using the property index instead. It would be
nice if we could reuse the first mechanism for the second one, but
there are too many properties to fit into a 64 bit mask.

(Though the limit on 64 events might get us into trouble later...)
2014-08-02 01:53:22 +02:00
wm4 be337aa415 command: add a property that returns a list of all properties
Also remove the undocumented Lua mp.property_list() function.
2014-08-02 01:53:21 +02:00
wm4 b4f24544bb client API: make "cache" property and similar observable
Achieve this by polling. Will be used by the OSC. Basically a bad hack -
but the point is that the mpv core itself is in the best position to
improve this later.
2014-07-31 04:19:41 +02:00
wm4 e00aad18cb command: redo the property type
Instead of absuing m_option to store the property list, introduce a
separate type for properties. m_option is still used to handle data
types. The property declaration itself now never contains the option
type, and instead it's always queried with M_PROPERTY_GET_TYPE. (This
was already done with some properties, now all properties use it.)

This also fixes that the function signatures did not match the function
type with which these functions were called. They were called as:

   int (*)(const m_option_t*, int, void*, void*)

but the actual function signatures were:

   int (*)(m_option_t*, int, void*, MPContext *)

Two arguments were mismatched.

This adds one line per property implementation. With additional the
reordering of the parameters, this makes most of the changes in this
commit.
2014-06-13 02:11:39 +02:00
wm4 5a5a3c53f7 client API: report success status when running commands
Until now, an error was reported only if the command couldn't be parsed.
Attempt to do more fine-grained reporting. This is not necessarily
perfect, but it's an improvement.
2014-06-01 03:41:46 +02:00
wm4 69ad734af8 command: add const to mp_notify_property 2014-06-01 03:41:36 +02:00
wm4 49d1b42f70 client API: add a way to notify clients of property changes
This turned out ridiculously complex. I think it will have to be
simplified some day. Main reason for the complexity are:
- filtering properties by forcing clients to observe individual
  properties explicitly
  (to avoid spamming clients with changes they don't want)
- optional retrieval of property value with the notification
  (the basic idea was that this is more user friendly)
- allowing to the client to specify a format in which the value
  should be retrieved
  (because if a property changes its type, the client API couldn't
  convert it properly, and compatibility would break)

I don't know yet which of these are important, and everything could
change. In particular, the interface and semantics should be adjusted
to reduce the implementation complexity.

While I consider the API complete, there could (and probably will) be
bugs left. Also while the implementation is complete, it's inefficient.
The complexity of the property matching is O(a*b*c) with a clients,
b observed properties, and c properties changing at once. I threw away
an earlier implementation using bitmasks, because it was too unwieldy.
2014-04-06 03:22:49 +02:00
wm4 98dc8206ae options: handle escape sequences in e.g. --playing-msg differently
M_OPT_PARSE_ESCAPES was pretty stupid, and broke the (useful) assumption
that string variables contain exactly the same value as set by the
option. Simplify it, and move escape handling to the place where it's
used.

Escape handling itself is not terribly useful, but still allows useful
things like multiline custom OSD with "\n".
2014-02-20 14:46:23 +01:00
wm4 206616b697 lua: port to client API
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.
2014-02-10 21:03:59 +01:00
wm4 88ae914b1e Add a client API
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).
2014-02-10 21:01:35 +01:00
wm4 119efdc197 lua: add playback-start event 2014-01-20 19:31:23 +01:00
wm4 a2d144fc8f m_property: mp_msg conversions
Includes some semi-crappy hacks to avoid changing too much code for this
conversion (allowing NULL log argument for m_property_do()).
2013-12-21 21:04:21 +01:00
wm4 e449111429 Move mpvcore/player/ to player/ 2013-12-17 00:53:22 +01:00