[FFmpeg-devel] [PATCH 1/2] libavutil/libavfilter: add opencl wrapper to ffmpeg

Thilo Borgmann thilo.borgmann at googlemail.com
Mon Mar 25 20:22:05 CET 2013


Am 25.03.13 13:03, schrieb Wei Gao:
> 2013/3/25 Michael Niedermayer <michaelni at gmx.at>
> 
>> On Mon, Mar 25, 2013 at 10:17:20AM +0800, Wei Gao wrote:
>>> 2013/3/25 Michael Niedermayer <michaelni at gmx.at>
>>>
>>>> On Sun, Mar 24, 2013 at 08:00:46PM +0100, Michael Niedermayer wrote:
>>>>> On Sun, Mar 24, 2013 at 06:40:27PM +0100, Stefano Sabatini wrote:
>>>>>> On date Sunday 2013-03-24 19:55:00 +0800, Wei Gao encoded:
>>>>>>>
>>>>>>
>>>>>>> From ab91c74fa166f557eadb39ab399d7ba667b91340 Mon Sep 17 00:00:00
>>>> 2001
>>>>>>> From: highgod0401 <highgod0401 at gmail.com>
>>>>>>> Date: Sun, 24 Mar 2013 19:20:16 +0800
>>>>>>> Subject: [PATCH 1/2] add opencl wrapper to ffmpeg
>>>>> [...]
>>>>>
>>>>>>> +static int access_binaries(cl_device_id *device_ids, int
>>>> numdevices, const char *cl_file_name, FILE **fhandle,
>>>>>>> +                                size_t *binarysizes, char
>>>> **binaries, int write)
>>>>>>> +{
>>>>>>> +    FILE *fd = NULL;
>>>>>>> +    int status;
>>>>>>> +    char filename[1024] = {0};
>>>>>>> +    char cl_name[1024] = {0};
>>>>>>> +    char devicename[1024] = {0};
>>>>>>> +    int i;
>>>>>>> +    for (i = 0; i < numdevices; i++) {
>>>>>>> +        if (device_ids[i] != 0) {
>>>>>>> +            status = clGetDeviceInfo(device_ids[i],
>>>>>>> +                                     CL_DEVICE_NAME,
>>>>>>> +                                     sizeof(devicename),
>>>>>>> +                                     devicename,
>>>>>>> +                                     NULL);
>>>>>>> +            if (status == CL_SUCCESS) {
>>>>>>> +
>>  av_strlcpy(cl_name,cl_file_name,sizeof(cl_name));
>>>>>>> +                snprintf(filename,
>> sizeof(filename),"./%s-%s.bin",
>>>> cl_name, devicename);
>>>>>
>>>>> [...]
>>>>>
>>>>>>> +                    if (binarysizes[i] != 0) {
>>>>>>> +                        output = fopen(filename, "wb");
>>>>>
>>>>> [...]
>>>>>
>>>>>>> +                        }
>>>>>>> +                        fwrite(binaries[i], sizeof(char),
>>>> binarysizes[i], output);
>>>>>
>>>>> theres no gurantee that you have write permission in the current
>>>>> directory or in any directory.
>>>>> Also its not nice from a library to drop files in the current
>>>>> directory unrequested
>>>>
>>>> also, while i didnt read the whole file read/write code it appears
>>>> to me that files are read and executed from the current directory
>>>> this is not safe, someone could have placed a mallicious file there
>>>>
>>> The file is use to save compile informations of OpenCL kernels in ffmpeg.
>>> Because OpenCL kernels is compiled in the runtime, and the compile time
>>> will be longer if there are more OpenCL kernels.If ffmpeg compile kernel
>>> every time, it will cost a long time in compiling every time.So we record
>>> the compile information the first time. And ffmpeg will load the file and
>>> run kernel without compile. It can save much time.
>>
>> This is not a compile cache vs. security argumentation.
>> security is a requirement.
>> If we can implement a secure compile cache that would be ideal.
>> But if its not secure then a insecure cache is not an alternative.
>>
>> Also for such a cache you need a directory where to place the files
>> the current directory is not ok. The directory path needs to be
>> configureable at build time, if no path is configured the code should
>> not read or write any excutables.
>> The path also needs to support $HOME or something like that.
>> And accessing the cache needs to work correctly if, 2 or more ffmpeg
>> processes access the cache at the same time.
>> also the cache must work when newer code has become available, that
>> is a user might have updated his ffmpeg to one with newer opencl code.
>> or updated opencl itself
>>
>> Should we need to add a configure option to this? I don't konw how to get
> the configured patch, is there any examples?

We should consider to keep the kernels in the library. Either as build-time
compiled data or as plain text strings.

Also the usual kernel is small and the compilers are fast. I doubt that
on-the-fly compiling of the invoked kernels significantly influences the
processing time of the filter chain processing, even for audio - some numbers
might help to convince me I'm wrong.

-Thilo



More information about the ffmpeg-devel mailing list