On Sun, Jan 17, 2016 at 7:13 PM, Mark Thompson <s...@jkqxz.net> wrote: > 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.) >
static variables (ie. global state) are undesirable as a concept entirely. Applications that want to setup a chain with pass through should manage the needed connection and make it available to each component needing access to it. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel