On Fri, Dec 09, 2016 at 04:25:31PM +0100, Hendrik Leppkes wrote:
> On Fri, Dec 9, 2016 at 3:52 PM, Diego Biurrun <di...@biurrun.de> wrote:
> > On Mon, Dec 05, 2016 at 05:39:57PM +0100, Hendrik Leppkes wrote:
> >> On Tue, Nov 29, 2016 at 7:34 PM, Diego Biurrun <di...@biurrun.de> wrote:
> >> > --- a/configure
> >> > +++ b/configure
> >> > @@ -2382,7 +2382,6 @@ sndio_indev_deps="sndio_h"
> >> > vfwcap_indev_deps="capCreateCaptureWindow vfwcap_defines"
> >> > -vfwcap_indev_extralibs="-lavicap32"
> >> > xcbgrab_indev_deps="libxcb"
> >> >
> >> > @@ -3041,7 +3040,6 @@ msvc_common_flags(){
> >> > -march=*) ;;
> >> > -lz) echo zlib.lib ;;
> >> > - -lavicap32) echo vfw32.lib user32.lib ;;
> >> > -lx264) echo libx264.lib ;;
> >> > -l*) echo ${flag#-l}.lib ;;
> >> > @@ -4752,7 +4750,7 @@ check_header AVFoundation/AVFoundation.h &&
> >> >
> >> > check_header sys/videoio.h
> >> >
> >> > -check_func_headers "windows.h vfw.h" capCreateCaptureWindow
> >> > "$vfwcap_indev_extralibs"
> >> > +check_lib "windows.h vfw.h" capCreateCaptureWindow -lvfw32
> >> > # check that WM_CAP_DRIVER_CONNECT is defined to the proper value
> >> > # w32api 3.12 had it defined wrong
> >> > @@ -4804,6 +4802,10 @@ if enabled libxcb; then
> >> >
> >> > enabled dxva2 &&
> >> > + check_lib "windows.h winuser.h" GetShellWindow -luser32 ||
> >> > + disable dxva2
> >> > +
> >> > +enabled dxva2 &&
> >> > check_lib windows.h CoTaskMemFree -lole32 &&
> >> > enable dxva2_lib
> >>
> >> This entirely takes out linking against avicap32, and replaces it with
> >> vfw32, presumably this was once required (except for msvc). That does
> >> introduce a distinct change in linking, so it would need testing on
> >> all supported versions of mingw.
> >
> > I suspect this was cargo-culted around. I tested building with dxva2
> > disabled and vfwcap enabled on Cygwin, Msys 2, and Mingw32. No problems.
> >
> >> Also does vfwcap indev not require user32 anymore, like it apparently used
> >> to?
> >
> > The only use of GetShellWindow is in libavutil/hwcontext_dxva2.c.
>
> On a quick check, vfwcap uses GetWindowLongPtr, which is from user32.dll.
> There might be other functions in there as well. I am not sure however
> if user32.dll is part of the default link libraries these days, and
> maybe was not at some earlier point.
It certainly worked without linking against user32.dll at all, so our
best guess is that your theory is right. I'm assuming that means that
linking against user32.dll at all is pointless nowadays?
Diego
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
