mpv has a ton of defines that are generated during building. Previously,
the meson build just had this as a big giant wall of text that manually
set each one but we can do this smarter. Instead, change the "features"
object to a dictionary and have it hold the name of the feature and its
value (true/false on whether it is enabled). Then at the end, just loop
through it and reformat the name of the feature so it becomes
HAVE_FEATURE. A side effect of this is that a lot of extra defines are
generated that aren't actually used in the code, but the waf build
worked like this for years anyway. A nice result of this is that the use
of foo['use'] internally can be completely eliminated and replaced with
feature['foo'] instead when needed.
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
Some compiler flags were passed to mpv in order to get it to build as a
gui application on windows. However on the meson build, this always
resulted in mpv being built as a console application. This is because
the function for making executables in meson specifically has a kwarg
called win_subsystem* which defaults to 'console'. That always added
link arguments at the end which compiled mpv.exe as a console
application. The correct thing to do is to remove all of the
subsystem-related flags in the meson build and use the win_subsystem
kwarg as intended by setting it to 'windows,6.0'. For mpv.com, we can
remove the -Wl,--subsystem,console flag since meson will set this by
default in that executable. This makes mpv.exe function correctly and
open with the pseudo-gui while mpv.com acts as a console wrapper.
1a0603835e
A few custom targets had some less than optimal names which created some
misleading "Generating custom-target-name with a custom command"
messages. Change those to be more descriptive/correct. In a few other
places, some checks were being done that could easily be
skipped/ignored in certain cases (like checking for windows-related
headers when gl-win32 isn't true). Also rearrange that to be smarter.
Finally, print some extra libplacebo messages for enabling/disabling
vo_gpu_next.
