> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, April 15, 2018 7:31 PM
> To: ffmpeg-devel@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 
* 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?


ffmpeg-devel mailing list

Reply via email to