On Tue, Jun 13, 2017 at 03:31:12PM +0300, Martin Storsjö wrote: > When targeting the UWP API subset, the LoadLibrary function is not > available (and the fallback, LoadPackagedLibrary, can't be used to > load system DLLs). In these cases, link directly to the functions > in the DLLs instead of trying to load them dynamically at runtime. > --- > I kept the behaviour where we don't error out if dxgi.dll is missing, > if the device parameter is null, although I'm not sure if the > distinction is relevant. > > I changed checks for UWP into checks for the LoadLibrary function, > which in general feels more straightforward. > > Do note that this uses the CreateDXGIFactory1 function if LoadLibrary > isn't available, since the unsuffixed version of the function isn't > available in UWP. > > I don't have any actual environment to test this in, so I'd appreciate > if someone can do that. > --- > configure | 4 +++ > libavutil/hwcontext_d3d11va.c | 79 > +++++++++++++++++++++++++------------------ > 2 files changed, 51 insertions(+), 32 deletions(-)
I'll be bold and ask the naive question: why not skip LoadLibrary in all cases? > --- a/configure > +++ b/configure > @@ -5159,6 +5159,10 @@ esac > > enabled asm || { arch=c; disable $ARCH_LIST $ARCH_EXT_LIST; } > > +# d3d11va requires linking directly to dxgi and d3d11 if not building for > +# the desktop api partition > +enabled LoadLibrary || d3d11va_extralibs="-ldxgi -ld3d11" > + > check_deps $CONFIG_LIST \ > $CONFIG_EXTRA \ > $HAVE_LIST \ That's not a good place for the hack. Problem is, I don't see a good place anywhere. I'll try to think of something. > --- a/libavutil/hwcontext_d3d11va.c > +++ b/libavutil/hwcontext_d3d11va.c > @@ -18,6 +18,10 @@ > > #include <windows.h> > > +// Include thread.h before redefining _WIN32_WINNT, to get > +// the right implementation for AVOnce > +#include "thread.h" > + > #if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600 > #undef _WIN32_WINNT > #define _WIN32_WINNT 0x0600 The comment confuses me, I don't see where AVOnce depends on _WIN32_WINNT.. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel