1. 20 Apr, 2021 2 commits
  2. 30 Mar, 2021 1 commit
  3. 15 Mar, 2021 3 commits
    • Alexandre Janniaux's avatar
      Makefile.am: mmal: remove recursive Makefile target · 4ef3f338
      Alexandre Janniaux authored
      Sort of revert 1d2b56c6 but it actually
      finish the work done in ticket #9367 by removing the last recursive
      makefile target in modules/.
      
      It allows faster make (though not significant here) but most of all,
      sharing the same variable definition scope in modules/ for all
      makefiles.
      
      In particular, this facilitate for future work implementing partial
      linking at the module level, which actually needs the list of all
      plugins being compiled.
      4ef3f338
    • Alexandre Janniaux's avatar
      configure.ac: remove previous mmal virtual plugin · 8e3b8b91
      Alexandre Janniaux authored
      The plugin's values are not used anymore.
      8e3b8b91
    • Alexandre Janniaux's avatar
      configure.ac: fix mmal CFLAGS/LDFLAGS definition · d9552fa0
      Alexandre Janniaux authored
      The MMAL_CFLAGS / MMAL_LIBS will be used in the Makefile.am instead of
      the plugin defined flags, since there are multiple plugins, and in
      addition of a HAVE_MMAL conditional.
      
      In addition, -L flags are LIBADD flags, and not LDFLAGS flags, so it's
      actually put into MMAL_LIBS instead of defining a MMAL_LDFLAGS.
      d9552fa0
  4. 15 Feb, 2021 1 commit
    • Alexandre Janniaux's avatar
      configure.ac: fix AC_PROG_LEX warning · 824b3d45
      Alexandre Janniaux authored
      With autoconf 2.70, the following warnings are emitted:
      
      configure.ac:56: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
      ./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
      ./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
      configure.ac:56: the top level
      
      The documentation[1] of autoconf now states:
      
      > Prior to Autoconf 2.70, AC_PROG_LEX did not take any arguments, and
      > its behavior was different from either of the above possibilities: it
      > would search for a library that defines yywrap, and would set LEXLIB
      > to that library if it finds one. However, if a library that defines
      > this function could not be found, LEXLIB would be left empty and LEX
      > would not be reset. This behavior was due to a bug, but several
      > packages came to depend on it, so AC_PROG_LEX still does this if
      > neither the yywrap nor the noyywrap option is given.
      >
      > Usage of AC_PROG_LEX without choosing one of the yywrap or noyywrap
      > options is deprecated. It is usually better to use noyywrap and define
      > the yywrap function yourself, as this almost always renders the LEXLIB
      > unnecessary.
      
      The behaviour of the argument on autoconf < 2.70 is to ignore the
      argument, so there are no issues with adding the option.
      
      [1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Particular-Programs.html#Particular-Programs
      824b3d45
  5. 29 Jan, 2021 1 commit
  6. 28 Jan, 2021 1 commit
  7. 25 Jan, 2021 1 commit
  8. 18 Jan, 2021 2 commits
    • Jean-Baptiste Kempf's avatar
      Update Copyright Years to 2021 · 8c6ccc3b
      Jean-Baptiste Kempf authored
      8c6ccc3b
    • Steve Lhomme's avatar
      direct3d11: use a ID3D11Fence to tell when the rendering is done · 61dbb36e
      Steve Lhomme authored
      This is a lot more accurate and wastes a lot less time than the Query approach.
      The D3D11 Fence value is set when the GPU is done doing the previous
      (rendering) commands. Then we can wait in the CPU for this event and return when
      it's done. All decoder/filter commands seem to not have any impact so that's
      really the signal we're looking for to tell the core we're done rendering.
      
      This is only supported on newer mingw toolchains and only on Windows 10
      Creators Update, which should cover pretty much all Win10 installed machines.
      
      Better fixes #21600
      61dbb36e
  9. 11 Dec, 2020 1 commit
    • Alexandre Janniaux's avatar
      configure.ac: refactor lua detection · 2af2780f
      Alexandre Janniaux authored
      All checks were nested which was really hard to read and modify
      correctly. Instead use a state variable to track the detection status
      and chain AS_IF condition for each test.
      2af2780f
  10. 09 Dec, 2020 1 commit
  11. 29 Nov, 2020 1 commit
  12. 20 Oct, 2020 1 commit
  13. 19 Oct, 2020 1 commit
  14. 17 Oct, 2020 2 commits
  15. 12 Oct, 2020 1 commit
  16. 09 Oct, 2020 1 commit
    • Marvin Scholz's avatar
      codec/sdl_image: remove module · 6ff21931
      Marvin Scholz authored
      Most of the codecs that are supported by this module are already
      supported by FFmpeg anyway and its quite heavy dependency-wise (needing
      SDL and SDL_image).
      Instead, rely on avcodec and remove this module.
      6ff21931
  17. 10 Sep, 2020 1 commit
  18. 26 Aug, 2020 1 commit
  19. 24 Aug, 2020 1 commit
  20. 18 Aug, 2020 1 commit
  21. 22 Jul, 2020 1 commit
  22. 02 Jul, 2020 1 commit
    • Alexandre Janniaux's avatar
      opengl: split into convenience library · da1853b2
      Alexandre Janniaux authored
      Create a libvlc_opengl and libvlc_opengles library that are built only
      if one other target is needing it, avoiding to compile the OpenGL code
      once per module using it and removing the need for OPENGL_COMMON* vars.
      
      As the fact we're using OpenGL or OpenGL ES is defined at compile time,
      the clients must use the correct variant depending on what they use.
      
      In addition, this patch refactor the glesv2 detection in order to
      enable both the gles2 display plugin and the libvlc_opengles.la target
      which must not be built on Windows target for example.
      da1853b2
  23. 22 Jun, 2020 1 commit
  24. 19 Jun, 2020 1 commit
  25. 17 Jun, 2020 1 commit
  26. 10 Jun, 2020 1 commit
    • Steve Lhomme's avatar
      win32: use windowsappcompat instead of winstorecompat · 6e8effb6
      Steve Lhomme authored
      This is the proper counterpart to windowsapp.
      
      Now that we have a proper Docker image to build it:
      registry.videolan.org/vlc-debian-llvm-uwp:20200603145315
      
      A recent mingw64 8 (unreleased) is needed to make use of this. It's available
      in our Docker images and in msys2 (although it's using msvcrt so it will
      probably fail to link properly)
      
      The forced -lwindowsappcompat is added like the other LDFLAGS in configure.ac.
      6e8effb6
  27. 08 Jun, 2020 2 commits
  28. 05 Jun, 2020 2 commits
  29. 19 May, 2020 1 commit
  30. 18 May, 2020 2 commits
  31. 13 May, 2020 1 commit
  32. 10 May, 2020 1 commit
    • Rémi Denis-Courmont's avatar
      notify: don't depend on any GTK version · 0ebb8fa0
      Rémi Denis-Courmont authored
      If there's one in the process use it. If there's none fallback to
      default VLC icon with the old code.
      
      This not only avoids VLC builds depending on GTK, but this should
      prevent crashes if GTK 2 is present in the process (e.g. through Qt plugin).
      0ebb8fa0