1
0
mirror of https://github.com/mpv-player/mpv synced 2025-03-21 18:57:35 +00:00
mpv/DOCS/man
wm4 ba70b150fb client API: provide ways to finish property changes on file changes
When the current file changes (or rather, when starting/finishing
playback of a playlist entry), clients tend to have the problem that
it's hard to tell whether a property change notification (via
mpv_observe_property() and mechanisms layered on top of it) is from the
previous or new playlist entry. The previous commit probably helps, but
all the asynchronity is still a bit unhelpful.

Try to make this better by adding new hooks, that are run before/after
playback init/deinit. This is similar to the existing hooks, except
they're outside of "initialized" playback, which excludes that you might
accidentally get an overlap between the current and the previous/next
playlist entry.

That still doesn't seem quite enough, since normally, property change
notifications come after the hook event. So basically a client would
have to explicitly "drain" the event queue within the hook, and make the
hook continue only after that is done. Knowing when property
notifications are done is another asynchronous nightmare (how exactly it
works keeps changing within client.c, and an API user probably can't
tell anymore when all pending properties are truly done). So introduce
another guarantee: properties that were changed before the hook happens
will be returned before the hook event is returned. That means the
client will have received all pending property notifications from the
previous playlist entry (or whatever) before the hook is entered.

As another minor complication, we shouldn't just keep the hook pending
until _all_ property notifications are done, since the client's hook
could produce new ones. (Or just consider things like the demuxer thread
hammering the client with cache update events, while the "on_preloaded"
hook is run.) So there is some extra untested, fragile logic in client.c
to handle this (the waiting_for_hook flag).

This probably works, but was barely tested. Not sure if this helps
anyone, but I think it's fine for my own purposes. (I really hated this
aspect of the API whenever I used it myself.)
2020-03-07 02:52:10 +01:00
..
af.rst audio: remove unreferenced af_lavrresample 2019-09-19 20:37:05 +02:00
ao.rst ao_pulse: add --pulse-allow-suspended 2019-09-21 12:54:36 +02:00
changes.rst manpage: directly link interface-changes.rst in changelog section 2020-02-21 14:34:02 +01:00
console.rst console: use hidpi scale reporting 2019-12-20 13:00:39 +01:00
encode.rst manpage: explain deprecated usage of multiple items with *-add 2020-01-07 18:13:12 +01:00
input.rst client API: provide ways to finish property changes on file changes 2020-03-07 02:52:10 +01:00
ipc.rst ipc: allow sending commands with named arguments 2020-02-24 00:31:46 +01:00
javascript.rst DOCS: js: minor update for require 2020-02-07 19:24:00 +02:00
libmpv.rst manpage: define stricter rules for C plugin return values 2017-01-14 17:41:04 +01:00
lua.rst command: extend osd-overlay command with bounds reporting 2020-03-06 18:20:11 +01:00
mpv.rst manpage: fix some path description details 2020-02-21 12:13:54 +01:00
options.rst manpage: fix typos 2020-03-06 18:12:13 +01:00
osc.rst osc: use default hr-seek when dragging progress bar to seek 2020-02-28 17:17:42 +01:00
stats.rst manpage: document stats page 3 2019-10-31 11:06:22 +01:00
vf.rst vf_format: add w, h parameters 2020-02-09 18:23:22 +01:00
vo.rst sws_utils, zimg: destroy vo_x11 and vo_drm performance 2019-10-31 16:51:12 +01:00