[FFmpeg-devel] [PATCH 5/5] amfenc: Remove spurious initialisations
Alexander Kravchenko
akravchenko188 at gmail.com
Tue Apr 24 14:29:07 EEST 2018
> -----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
Thanks,
Alexander
More information about the ffmpeg-devel
mailing list