[FFmpeg-devel] [PATCH v1] avfilter/vf_gblur_vulkan: add sizeV option

Wu, Jianhua jianhua.wu at intel.com
Tue Feb 22 08:27:58 EET 2022


Lynne:
> Sent: Tuesday, February 22, 2022 1:38 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_gblur_vulkan: add sizeV
> option
> 
> 18 Feb 2022, 16:24 by toqsxw at outlook.com:
> 
> >> 29 Jan 2022, 13:34 by toqsxw at outlook.com:
> >>
> >>> Ping.
> >>>
> >>>> From: Wu, Jianhua<mailto:jianhua.wu-at-intel.com at ffmpeg.org>
> >>>> Sent: 2022年1月21日 19:42
> >>>> To: ffmpeg-devel at ffmpeg.org<mailto:ffmpeg-devel at ffmpeg.org>
> >>>> Cc: Wu, Jianhua<mailto:jianhua.wu at intel.com>
> >>>> Subject: [FFmpeg-devel] [PATCH v1] avfilter/vf_gblur_vulkan: add
> >>>> sizeV option
> >>>>
> >>>> [PATCH 1/5] avfilter/vf_gblur_vulkan: add sizeV option [PATCH 2/5]
> >>>> avfilter:add shader_vulkan filter [PATCH 3/5]
> >>>> avfilter/vf_blend_vulkan: add multiply blend mode [PATCH 4/5]
> >>>> avutil/vulkan: don't use strlen as loop >condition [PATCH 5/5]
> >>>> avfilter/scale_vulkan: use RET for checking return value
> >>>>
> >>>> Patches attached.
> >>>>
> >>>
> >>> Hi there,
> >>>
> >>> Any update?
> >>>
> >>
> >> Sorry, haven't forgotten, but been busy with FFTs lately.
> >> Will try to review and test the patches soon.
> >>
> >
> > Hi there,
> >
> > I'm sorry for bothering you. If there is any update on this thread,
> > please do let me know.
> >
> 
> Pushed all except the strlen() in a loop condition and the shader filter.
> I pushed a different, smaller version for the strlen patch.
> 
Maybe you don't need to use strlen() at all. That patch could be applied
separately if you preferred to apply the shader_vulkan filter in the future.

> As for a shader filter, I'd like something that's a lot less minimal.
> You should expose the frame number, framerate (with an avoption to set it),
> pixel format to the shader. Keep in mind the API will be fixed, so we need to
> get this right the first time hopefully.

Frame number and framerate are okay to set if I can get them from FFmpeg API,
but pixel format may not be ideal to expose for there is a lot of pixel formats in
FFmpeg. Exposing a pixel format means we need to expose all values related to
pixel formats. Instead, we could expose two functions like

vec4 pixel = av_read_pixel(intput_images, av_position) 
av_write_pixel(ouput_images, pixel, positions)

so the user shader could only concentrate on the vector4 pixel variable and don't
need to care about what pixel format is. Or simply expose the subsampling scheme,
444, 420, or 422, and color space, YUV, and RGB.

> Also, correct the name style. We don't use camelcase for variables, and we
> use "av_" instead of "ff_" for public API, which a shader sort of is IMO.

Got it.

> You should expose alpha planes as well.
Could you elaborate it further?

> Finally, could you implement N-inputs and M-outputs, configurable via
> avoptions? That way, someone could make a custom blend filter without a
> separate avfilter which takes multiple inputs. Or a separator filter.
> Or a simple source filter that just produces an image pattern.
> 
Sounds great! However, at the present, I've no idea about how this could be done.
I think the current filter is already useful already for I could make some great video
effects just like Shadertoy. More extensions need further contributions.

Thanks,
Jianhua



More information about the ffmpeg-devel mailing list