Lynne: > Sent: Tuesday, February 22, 2022 5:36 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_gblur_vulkan: add sizeV > option > > 22 Feb 2022, 07:27 by jianhua.wu-at-intel....@ffmpeg.org: > > > Lynne: > > > >> Sent: Tuesday, February 22, 2022 1:38 PM > >> To: FFmpeg development discussions and patches <ffmpeg- > >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_gblur_vulkan: add > >> sizeV option > >> > >> 18 Feb 2022, 16:24 by toq...@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. >
I suppose you mean there is a init function in the shader source file and execute it to read back some configuration data, don't you? If so, looks like a great feature. And I think, isn't these characteristics should be only added when there is someone who has the relative requirements? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
