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


More information about the ffmpeg-devel mailing list