On 24 April 2018 at 12:29, Alexander Kravchenko <akravchenko...@gmail.com> wrote:
> > > > -----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 > No, I think there should be no avpriv functions for hwcontexts, nor any public API changes. Better duplicate that code in lavfi. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
