On Sat, 14 May 2016 13:20:02 +0200
Anton Khirnov <[email protected]> wrote:
> > > +/**
> > > + * This struct is allocated as AVHWDeviceContext.hwctx
> > > + */
> > > +typedef struct AVDXVA2DeviceContext {
> > > + IDirect3DDeviceManager9 *devmgr;
> > > +} AVDXVA2DeviceContext;
> > > +
> > > +/**
> > > + * This struct is allocated as AVHWFramesContext.hwctx
> > > + */
> > > +typedef struct AVDXVA2FramesContext {
> > > + /**
> > > + * The surface type (e.g. DXVA2_VideoProcessorRenderTarget or
> > > + * DXVA2_VideoDecoderRenderTarget). Must be set by the caller.
> > > + */
> > > + DWORD surface_type;
> > > +
> > > + /**
> > > + * The surface pool. When an external pool is not provided by the
> > > caller,
> > > + * this will be managed (allocated and filled on init, freed on
> > > uninit) by
> > > + * libavutil.
> > > + */
> > > + IDirect3DSurface9 **surfaces;
> > > + int nb_surfaces;
> > > +
> > > + /**
> > > + * Certain drivers require the decoder to be destroyed before the
> > > surfaces.
> > > + * To allow internally managed pools to work properly in such cases,
> > > this
> > > + * field is provided.
> > > + *
> > > + * If it is non-NULL, libavutil will call
> > > IDirectXVideoDecoder_Release() on
> > > + * it just before the internal surface pool is freed.
> > > + */
> > > + IDirectXVideoDecoder *decoder_to_release;
> > > +} AVDXVA2FramesContext;
> >
> > That's going to behave pretty badly with all those dynamically loaded
> > DLLs. If you unload a DLL while a frame is still referenced, everything
> > will crash.
>
> I don't understand what you mean here. What DLLs are getting unloaded
> where?
>
Many API users (including avconv_dxva2.c) are dynamically loading
dxva2.dll and Direct3D. (Not sure why...)
So I would argue that the device context should include possibly
optional DLL handles (similar to how the frames context makes sure the
decoder and D3D device handle survive until the end). Unless there's
another mechanism the user is intended to use for this.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
