[FFmpeg-devel] [PATCH 1/5] libavutil: Some VAAPI infrastructure

[Hendrik Leppkes]

On Sun, Jan 17, 2016 at 7:13 PM, Mark Thompson <sw at jkqxz.net> wrote:
> On 17/01/16 17:53, wm4 wrote:
>>
>> On Sun, 17 Jan 2016 17:34:55 +0000
>> Mark Thompson <sw at jkqxz.net> wrote:
>>
>>>   From 2442c1aca8778167c2e60a34d03ed452737f1366 Mon Sep 17 00:00:00 2001
>>> From: Mark Thompson <mrt at 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