Commit Graph

13 Commits

Author SHA1 Message Date
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