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

Mark Thompson sw at jkqxz.net
Sun Jan 17 19:13:50 CET 2016


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.)

- Mark



More information about the ffmpeg-devel mailing list