int pipefd = mpv_get_wakeup_pipe(mpv); if (pipefd < 0) error(); while (1) { struct pollfd pfds[1] = { { .fd = pipefd, .events = POLLIN }, }; // Wait until there are possibly new mpv events. poll(pfds, 1, -1); if (pfds[0].revents & POLLIN) { // Empty the pipe. Doing this before calling mpv_wait_event() // ensures that no wakeups are missed. It's not so important to // make sure the pipe is really empty (it will just cause some // additional wakeups in unlikely corner cases). char unused[256]; read(pipefd, unused, sizeof(unused)); while (1) { mpv_event *ev = mpv_wait_event(mpv, 0); // If MPV_EVENT_NONE is received, the event queue is empty. if (ev->event_id == MPV_EVENT_NONE) break; // Process the event. ... } } }
@deprecated this function will be removed in the future. If you need this functionality, use mpv_set_wakeup_callback(), create a pipe manually, and call write() on your pipe in the callback.
@return A UNIX FD of the read end of the wakeup pipe, or -1 on error. On MS Windows/MinGW, this will always return -1.
Return a UNIX file descriptor referring to the read end of a pipe. This pipe can be used to wake up a poll() based processing loop. The purpose of this function is very similar to mpv_set_wakeup_callback(), and provides a primitive mechanism to handle coordinating a foreign event loop and the libmpv event loop. The pipe is non-blocking. It's closed when the mpv_handle is destroyed. This function always returns the same value (on success).
This is in fact implemented using the same underlying code as for mpv_set_wakeup_callback() (though they don't conflict), and it is as if each callback invocation writes a single 0 byte to the pipe. When the pipe becomes readable, the code calling poll() (or select()) on the pipe should read all contents of the pipe and then call mpv_wait_event(c, 0) until no new events are returned. The pipe contents do not matter and can just be discarded. There is not necessarily one byte per readable event in the pipe. For example, the pipes are non-blocking, and mpv won't block if the pipe is full. Pipes are normally limited to 4096 bytes, so if there are more than 4096 events, the number of readable bytes can not equal the number of events queued. Also, it's possible that mpv does not write to the pipe once it's guaranteed that the client was already signaled. See the example below how to do it correctly.