macosx/coreinteraction: split apple remote, media key and video filter handling as those don't belong there

No functional changes

Asking NSFileManager for the mounted devices can take very long (>6s) when the devices are slow to respond, so let's do that on the background thread and don't delay display of the open panel.

libplacebo won't find it

Asynchronous requests from the user interface should still be queued
without blocking, even if the video output is held by other processing.

For that, we need to release the mutex between Hold() and Release().

There is a mixture of subpicture-related calls, with some running on
the calling thread, and others running on the video output thread
control loop.

The later may be delayed, depending on other video output thread
processing, sleeping and pending control requests. This leads to a
race condition, and potentially inconsistent ordering of calls on the
SPU instance.

This patch runs vout_FlushSubpictureChannel() directly on the calling
thread and adds a missing check for nonexistent/destroyed SPU.

There is a mixture of subpicture-related calls, with some running on
the calling thread, and others running on the video output thread
control loop.

The later may be delayed, depending on other video output thread
processing, sleeping and pending control requests. This leads to a
race condition, and potentially inconsistent ordering of calls on the
SPU instance.

This patch runs vout_SubPicture() directly on the calling thread and
adds a missing check for nonexistent/destroyed SPU.

Romain Vimont authored 6 years ago and Thomas Guillem committed 6 years ago

If a media source was already created in _GetMediaSource(), its refcount
was not incremented.

Reported-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>
Signed-off-by: Thomas Guillem <thomas@gllm.fr>

On my system it doesn't find any matching format.

And build using cmake rather their manually edited makefiles

In recent wglew.h it relies on the DLL export mode defined in glew.h

... leveraging the removal of callbacks from previous changeset.

Once the callbacks are deleted, we are assured that they will no longer
be triggered. Then we can safely destroy resources without the risk of
causing use-after-free if a user interface sets a variable.

This enables sharing per-format initialization code between the initial
initialization and reinitialization cases.

...like the snapshot queue. This makes no practical differences... yet.

There are only two ways that the video output (control) thread can end:
- vout_Request() requests REINIT, then ThreadReinit() fails;
  vout_Close() will be called.
- vout_Close() requests CLEAN and the ensuing ThreadStop() completes.

Either way, we will hit the vlc_join(). This is a suitable place to
mark the "death" of the control queue.

This avoids creating a thread in vain on failure, and then ping-pong
between the decoder and the vout thread.

No functional changes.

Since the caller waits for completion, there are no benefits to
offloading the work to the video output thread.

Since the caller waits for completion, there are no benefits to
offloading the work to the video output thread.

The vout window is not reentrant, needs its lock.

Since the caller waits for completion, there are no benefits to
offloading the work to the video output thread.

Since the caller waits for completion, there are no benefits to
offloading the work to the video output thread.

Since the caller waits for completion, there are no benefits to
offloading the work to the video output thread.

Holding waits for the control loop to go idle, then preempts it.
Release resumes it.

This allows running code in synchronization with the video output
thread, without actually running on the video output thread. In
particular, this does not require any memory allocation, unlike pushing
a control request.

Regression from cad5bc0a.

So what if protoc does not matc? I should still be able to build almost
everything that does not depend on this crapware.

Regression from d45bc25e.