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
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
