fuzzer_set_property.c:
fuzz mpv_set_property in both initialized and non-initialized state.
Useful for user provided values sanitization test. I've already seen
some memory leaks in parsing code, good to drill it.
fuzzer_loadfile.c:
mpv_command "loadfile" test. Good for testing demuxers, decoding and
playback loop. Sadly in headless mode we can't really test AO and VO,
but at least all the code around can be fuzzed. Especially our custom
demuxers like demux_mkv.
fuzzer_loadfile_direct.c:
Similar to loadfile above, but instead of saving the data to file, it
passes the fuzz input in the command. Generated protocol specific
versions (mf:// and memory:// for now) and generic one.
Nothing really complex, but good start and even those few targets should
give good coverage of the most common code paths in libmpv.
Abstract out EGL, and allow choosing between EGL and vulkan at runtime.
vf_gpu_egl.c contains GL specific context and creation/destroy code,
vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being
built in systems where EGL is not available and where Vulkan is
available.
DXGI debug interface encapsulate multiple message queues, which allows
to get validation not only for D3D11 calls, but also DXGI ones.
Also this makes leak detector not report self debug interface as alive
like it was before. And same as with validation, it has ability to
detect more alive objects, not being limited to D3D11.
add new app_bridge objc file for bridging between mpv core and app
functionality. replace old EventsResponder singleton with AppHub.
another step to clean up all App functionality and have one central
place for it.
timeBeginPeriod() only allows setting minimum timer resolution
to 1 ms. However, modern x86 platforms support a minimum timer
resolution of 0.5 ms. Use NtSetTimerResolution() instead for
the increased resolution, which can be set with MPV_HRT_RES.
Additionally, change the units of mp_start_hires_timers(),
mp_end_hires_timer(), MPV_HRT_RES, and MPV_HRT_MAX to nanoseconds,
in accordance with other functions used in timer.h.
The purpose of osdep/io is to provide a wrapper for POSIX I/O functions
on Windows. The last 2 functions are utility functions which don't serve
this purpose.
Move them to a separate file.
This will prevent building demos and link statically with libplacebo by
default if system libplacebo is not found or isn't new enough and a
sufficiently new enough libplacebo exists in `subprojects/libplacebo`.
vo_rpi and its related code has pretty much historically been a
disaster in mpv. The build regularly gets broken and since nobody uses
it, it takes months for anyone to notice. There was also that time where
fullscreen was broken for about a year and a half. Also building in waf
was entirely broken for about a couple of years or so due to mysterious
reasons no one ever figured out (meson magically fixed it).
Anyways, once again the build is broken due to rpi being forgotten about
again, but instead of pretending to support this crap. Just drop it all.
Nowadays, mmal hwdec is a relic since these devices are better off using
the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1
and 2 probably can't do this and will remain broken but oh well blame
Broadcom for being special snowflakes and not using standard APIs (my
rockpro worked out of the box; just saying). RPI 2 is nearly 10 years
old anyways, so I think you can afford a new SBC by now. If we were
nicer, there would be a deprecation period, but this is broken in the
last major release anyway so too late.
Closes#13402.
See 1b035402a6. This is only relevant if
you are using d3d11 on --vo=gpu which is windows-only. For all other
platforms, vulkan uses libplacebo which uses shaderc. mpv itself doesn't
need it in those cases.
Meson was pretty strict about target ids and generating the mpv.com in
the same directory as mpv.exe wasn't possible. So as a workaround we
tucked it away in a subdirectory, but that's not really intuitive at
all. Well as of meson 1.3.0, this is now possible so leverage it since
it makes way more sense. We still keep the old workaround for anyone
using older meson versions.
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is
completely unmaintained and can't properly playback anything anymore on
the newest macOS. it is time to remove it.
older macOS dev tools were inconsistent with the way how SDK versions
were returned, some truncated the minor versions. in those cases the
SDK version had to be retrieved through the SDK build version.
recently the scheme for the SDK build version changed that our heuristic
for converting it to an SDK version produced wrong version strings.
the stride of the minor version changed from 1 to 2, so SDK versions
ended up higher than they actually were. furthermore macOS 11 was
hardcoded.
since Xcode 12 Apple fixed the SDK version retrieval and it is no longer
truncated when using Xcode as dev tools. Xcode 12 is also the latest
supported version on macOS 10.15, which is also our oldest supported
version. we can remove the old SDK build version conversation and use
the Xcode only tool to retrieve the SDK version in the case Xcode is
used as dev tools. furthermore this als keeps support for Xcode 11 where
the problem wasn't fixed yet, but is still a supported version on macOS
10.15.
Fixes#9907
These have been build options since the waf build, but that doesn't
really make sense. The build can detect whatever macOS sdk version is
available and then use that information to determine whether to enable
the features or not. Potentially disabling multiple sdk versions doesn't
really make any sense. Because f5ca11e12b
effectively made macOS 10.15 the minimum supported version, we can drop
all of these checks and bump the required sdk version to 10.15. The rest
of the build simplifies from there.
Kacper Michajłow