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

[Lynne]

22 Feb 2022, 07:27 by jianhua.wu-at-intel.com at ffmpeg.org:

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

Wrapper functions won't help, shaders would still need to know what colorspace to work in.
I think if you just expose the entire pixdesc flags as-is, so shaders know if it's RGB or YUV, and the raw colorspace/transfer/matrix integers, it'll be good enough.


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

Yes, currently for YUVA images, the alpha channel remains untouched (the size of all image arrays is [3]) and unexposed to the shader.


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

Just set AVFilter.inputs and AVFilter.outputs to NULL. Then in the init function,
copy what e.g. af_amix does to set inputs and what e.g. af_channelsplit does for
outputs. There are probably better examples out there if you look.
I think that this should be up to the shader to initialize, rather than the filter user,
so perhaps, in the init function, you compile the shader, run an init function in
the shader which tells you what it requires and does checking, then return,
and set it up for operation.