summaryrefslogtreecommitdiffstats
path: root/video/vaapi.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2017-01-11 18:47:27 +0100
committerwm4 <wm4@nowhere>2017-01-11 18:47:37 +0100
commit32186de3678cab5a63fd947e256c3b0f5ad0a72f (patch)
treebc3cc414421a13f3cb826835d0c7003594ec00de /video/vaapi.h
parenta41bedfce5f1df4adf2749eb2358e841bdb7a7f5 (diff)
downloadmpv-32186de3678cab5a63fd947e256c3b0f5ad0a72f.tar.bz2
mpv-32186de3678cab5a63fd947e256c3b0f5ad0a72f.tar.xz
vaapi: turn all mpv users into a living experiment
Dummy out the locking around all libva calls, which in theory shouldn't be needed anyway. Two years ago, these were added to prevent crashes with vaapi decoding and direct rendering (vo_opengl/vo_vaapi) active. It's not clear whether these are really needed - theory strongly points towards no. Some developers familiar with vaapi expressed similar thoughts. But past experience says differently. So let's try without the locking for a while and see what happens.
Diffstat (limited to 'video/vaapi.h')
-rw-r--r--video/vaapi.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/video/vaapi.h b/video/vaapi.h
index add3216308..68d8d4383d 100644
--- a/video/vaapi.h
+++ b/video/vaapi.h
@@ -45,8 +45,8 @@ bool check_va_status(struct mp_log *log, VAStatus status, const char *msg);
#define CHECK_VA_STATUS(ctx, msg) check_va_status((ctx)->log, status, msg)
-#define va_lock(ctx) pthread_mutex_lock(&(ctx)->lock)
-#define va_unlock(ctx) pthread_mutex_unlock(&(ctx)->lock)
+#define va_lock(ctx) (void)(ctx)
+#define va_unlock(ctx) (void)(ctx)
int va_get_colorspace_flag(enum mp_csp csp);