> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark > Thompson > Sent: Sunday, April 22, 2018 6:37 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious > initialisations > > 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. >
Hi Mark, I agree it is good to stay within current API (hwdevice and hwframes), but I am not sure it is always possible. is it ok create hwcontext_amf_internal.h which can be placeholder for the API like the following, or probably some helper functions can be published as pointers in AVAMFDeviceContext structure: amf_set_property_buffer amf_get_property_buffer amf_create_buffer_with_frame_ref amf_release_buffer_with_frame_ref Thanks, Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel