[FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious initialisations

[Rostislav Pehlivanov]

On 24 April 2018 at 12:29, Alexander Kravchenko <akravchenko188 at gmail.com>
wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Mark Thompson
> > Sent: Sunday, April 22, 2018 6:37 PM
> > To: ffmpeg-devel at 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-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?
> >
> > 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.