[FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious initialisations
Alexander Kravchenko
akravchenko188 at gmail.com
Sun Apr 15 22:45:18 EEST 2018
> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Mark Thompson
> Sent: Sunday, April 15, 2018 7:31 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious initialisations
>
>
> > I am waiting patches to be applied to propose new patch with hwcontext_amf in libavutil.
>
> Can you explain what you're intending to use that for? It's not clear to me how an extra wrapper around the D3D(9|11) surfaces is
> going to help, given that the support for them with AMF is already pretty good. (Compare the Intel libmfx stuff (the misleadingly-
> named "qsv") where the extra wrapping does help for some cases because the underlying library has weird constraints, but overall
> adds a lot of complexity (and failure modes) for rather unclear benefit. It's also inconvenient in that it promotes the existence of
> antifeatures like the "_qsv" decoders which are inferior to the builtin hwaccels in pretty much every respect.)
>
Hi Mark,
I am intending to create amf common helpers(tools) in libavutil.
They will be used in amfenc and vf_scaleamf. (vf_scaleamf is hw-accelerated color-space converter and scaler)
amf helpers should provide:
* amf_library: functions to load/unload amf dll based on reference count mechanism
* amf_context: functions to create AMFContext derived from DXVA2, D3D11, opencl and Vulcan in future
* av_frame <-> AMFSurface map functions (move from amfenc.c)
amfav_context can be implemented like hwdevice_ctx (AVAMFDeviceContext) and can be managed by av_hwdevice_ctx_create_derived (in case of incoming hw frames) and av_hwdevice_ctx_create or it can be implemented not using of av_hwdevice_ctx* mechanism
I think don’t need AVAMFFrameContext, and amf components will send/receive hwframes based on existing framecontexts (dxva/opencl...)
Could you recommend the best way how to do this fit in current architecture?
Thanks,
Alexander
More information about the ffmpeg-devel
mailing list