On 17/01/16 17:53, wm4 wrote:
On Sun, 17 Jan 2016 17:34:55 +0000
Mark Thompson <s...@jkqxz.net> wrote:
From 2442c1aca8778167c2e60a34d03ed452737f1366 Mon Sep 17 00:00:00 2001
From: Mark Thompson <m...@jkqxz.net>
Date: Sun, 17 Jan 2016 15:48:54 +0000
Subject: [PATCH 1/5] libavutil: Some VAAPI infrastructure
+
+static AVVAAPIConnection *av_vaapi_connection_list;
+
+int av_vaapi_instance_init(AVVAAPIInstance *instance, const char *device)
+{
+ AVVAAPIConnection *ctx;
+ int err;
+
+ for(ctx = av_vaapi_connection_list; ctx; ctx = ctx->next) {
+ if((device == 0 && ctx->device_string == 0) ||
+ (device && ctx->device_string &&
+ !strcmp(device, ctx->device_string)))
+ break;
+ }
This won't work. Neither vaapi nor your patch are thread-safe, yet you
have them as very central global mutable state.
True. That setup is all pretty nasty, and everything currently assumes
it happens on the same thread. Since multiple instances have to use a
common connection to libva (because they have to be able to pass
surfaces between them), this is unfortunately pretty much required.
If multithreaded use is desirable immediately then we could just have a
big lock which anything VAAPI-related must take when it wants to do
anything? (This would require changes to all existing VAAPI decoders as
well.)
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
