diff options
author | wm4 <wm4@nowhere> | 2017-01-11 18:47:27 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-01-11 18:47:37 +0100 |
commit | 32186de3678cab5a63fd947e256c3b0f5ad0a72f (patch) | |
tree | bc3cc414421a13f3cb826835d0c7003594ec00de /video | |
parent | a41bedfce5f1df4adf2749eb2358e841bdb7a7f5 (diff) | |
download | mpv-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')
-rw-r--r-- | video/vaapi.h | 4 |
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); |