On 15/11/17 15:39, Carl Eugen Hoyos wrote: > 2017-11-15 15:34 GMT+01:00 Mark Thompson <s...@jkqxz.net>: >> On 14/11/17 22:30, Carl Eugen Hoyos wrote: >>> 2017-11-14 20:47 GMT+01:00 Mark Thompson <s...@jkqxz.net>: >>> >>>> Silly example using everything (for i965 VAAPI + Beignet): >>>> >>>> ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128 >>>> -init_hw_device opencl=ocl@va -hwaccel vaapi >>>> -hwaccel_device va -hwaccel_output_format vaapi -i in.mp4 >>>> -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl >>>> -filter_complex '[1:v]format=yuva420p,hwupload[x2]; >>>> [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1]; >>>> [x1][x2]overlay_opencl=0:0, >>> >>>> program_opencl=test.cl >>> >>> Is this the equivalent of the vhook functionality? >> >> I suppose it has some similarities. > >> Is that a problem? > > That's exactly my question, I wonder if it is an issue.
The code itself shouldn't be a problem - OpenCL is fully standardised with runtime compilation (and indeed we have to do this for the filters including source as well). Like other filters making use of external files, it shouldn't be used where arguments (given e.g. "source=/etc/passwd" the build errors can leak inappropriate information) or the source file (easy to DoS the GPU) could be controlled by an attacker, but I don't think that sort of thing is a common use-case. >> The point of it is to allow the user to run simple pixel shaders >> on the GPU side without having to integrate them into ffmpeg. > > Why would this only be possible for simple shaders? It only has the input frame and an increasing index to decide what to do - there are no persistent data to guide anything. (More could be added, of course, but making something which is generally useful is difficult and quickly loses the simplicity of the current form. Ideas certainly welcome, though.) Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
