mirror of https://github.com/mpv-player/mpv
4d43c79e4c
The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not). |
||
|---|---|---|
| .. | ||
| decode | ||
| filter | ||
| out | ||
| csputils.c | ||
| csputils.h | ||
| d3d.c | ||
| d3d.h | ||
| fmt-conversion.c | ||
| fmt-conversion.h | ||
| hwdec.c | ||
| hwdec.h | ||
| image_loader.c | ||
| image_loader.h | ||
| image_writer.c | ||
| image_writer.h | ||
| img_format.c | ||
| img_format.h | ||
| mp_image.c | ||
| mp_image.h | ||
| mp_image_pool.c | ||
| mp_image_pool.h | ||
| sws_utils.c | ||
| sws_utils.h | ||
| vaapi.c | ||
| vaapi.h | ||
| vdpau.c | ||
| vdpau.h | ||
| vdpau_functions.inc | ||
| vdpau_mixer.c | ||
| vdpau_mixer.h | ||