On 15/04/18 20:45, Alexander Kravchenko wrote: >> -----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 > 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?
I agree that using a hwdevice context here makes sense, since it wraps all of the right properties (in particular, derivation from other devices). It's less clear to me what to do with the frames. A hwframes context could work just for derivation because you don't actually need to implement the allocation stuff (the existing DRM hwcontext does this, since it's only for interop). What other approach would you think of taking? Adding special external API to use internally between libraries is not nice and we try to avoid it quite strongly. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
