summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu_next: fix OOM on waylandNiklas Haas2021-11-201-7/+3
| | | | | | Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8 Fixes #9484
* wayland: fix a potential segfault on surface enterDudemanguy2021-11-201-0/+3
| | | | | | | | | | | | | | | | | | This possibility actually existed for years. The wayland protocol is asynchronous and there's no restriction on when a compositor can send a surface enter event. In mpv's case, the surface enter event is used to set some vital things regarded geometry/scaling etc. However, this implictly assumes that wl->current_output is actually initialized. The vast majority of the time, vo_wayland_reconfig will happen first which is where wl->current_output is, and should, be created. There's no rule/law that the ordering of events will always occur in this order. Plasma with certain auto-profile conditions can send the surface enter event before mpv does its initial reconfig. That segfaults of course. Just add a check to make sure we have wl->current_output here and return if we don't. This assumes that the compositor will send us another surface enterance event when mpv actually does the initial surface commit and roundtrip request later. Wayland logs indicate this does happen. Fixes #9492.
* wayland: support modifiers during axis eventsDudemanguy2021-11-201-4/+5
| | | | | | It was never implemented before but it's trivial. As an aside, touch events currently don't support modifiers either (is this a thing?). Well if someone complains that can be done later. Fixes #9490.
* DOCS/ao: remove incorrect note about openalDudemanguy2021-11-191-1/+1
| | | | | | | The audio rewrite in d27ad9654218463694093697e3d09f8983b4ccf3 originally broke this ao. However, 0ac724f0025d48e1372ac82c62d504aaadf19735 fixed and the documentation was never updated to reflect that. OpenAL has worked fine for a while not. Just remove this sentence.
* vo_gpu_next: always cache still framesNiklas Haas2021-11-191-1/+3
| | | | | | | Even when not display synced. Prevents redraw overhead for refreshes while paused. Also make the logic slightly clearer to follow (since it's inverted).
* vo_gpu_next: fix lancozs typo to lanczosLeo Izen2021-11-191-1/+1
| | | | | Fix typo in the warning to avoid ewa_lanczossharp because it might be removed in the future.
* vo_gpu: libplacebo: make version logging slightly clearerNiklas Haas2021-11-191-1/+2
| | | | Matches what `pl_log_create` does as well.
* meson: use gnu_symbol_visibility for libmpvDudemanguy2021-11-191-1/+2
| | | | | | Following the previous commit, we can just set gnu_symbol_visibility to 'hidden' to hide everything except for the symbols we explictly want to export. This should work on gcc, clang, and msvc.
* client API: use symbol visibility attributesDudemanguy2021-11-192-68/+77
| | | | | | | | In mpv, the only symbols we want to export are the functions from the client API. This is accomplised using a specific .def whitelist, but the main compilers people use (gcc or clang) like these attributes since it allows for further optimizations. MSVC also allegedly supports this as well (untested of course), so use __declspec for tht case.
* vo_gpu_next: simplify and improve frame redrawing logicNiklas Haas2021-11-191-14/+6
| | | | | | | | | | | | | | | | | | This almost perfectly recreates the semantics of --vo=gpu, i.e.: - still frames are never interpolated - non-repeated frames bypass single frame cache The only difference is that libplacebo doesn't do a cache/blit on the full output image, but rather it re-runs the last rendering step. This has some advantages and some drawbacks. The most notable advantage is that it also allows re-using the image contents when the only thing that changes is the OSD (whereas `--vo=gpu` would force a full re-render for that). The most notable drawback is that it also implies going through the dithering and output LUT logic on redraws. All in all, I think this is a pretty good trade-off in favor of `--vo=gpu-next`. Fully fixes the last remaining performance difference in #9430.
* ao_opensles: add guards for sample rate to useTom Yan2021-11-191-0/+2
| | | | | | Upstream "Wilhelm" (the Android OpenSLES implementation) supports only 8000 <= rate <= 192000. Make sure mpv resamples the audio when necessary.
* vo_gpu_next: fix panning on rotated videosNiklas Haas2021-11-191-4/+10
| | | | Closes #9454
* meson: fix typo in header checkDudemanguy2021-11-181-1/+1
| | | | This should be EGL not GL. Fixes #9469.
* context_glx: fix check for wrong GLX extensionsfan52021-11-171-2/+2
| | | | | | | GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by GLX_ARB_create_context_profile but the check was for _create_context. The former implies the latter (which we also need) so just replace the checked extension.
* context_{wayland,x11egl}: use mpegl_create_window_surface() toosfan52021-11-172-5/+12
| | | | Again no functional difference, just uses better APIs when they're available.
* context_drm_egl: make use of mpegl_create_window_surface()sfan52021-11-171-11/+3
| | | | This does what 3a10210c568f9c7d969ca6c4da2377c55fbf30f3 was supposed to, but better.
* egl_helpers: introduce wrapper around eglCreatePlatformWindowSurfacesfan52021-11-172-12/+50
| | | | | | It abstracts EGL 1.5, extension checks and other inconsistencies away. This can be used in context code as the (preferred) alternative to eglCreateWindowSurface().
* video: opengl: use gl_check_extension() instead of strstr()sfan52021-11-176-9/+8
| | | | | | Using a simple substring match for extension checks is considered bad practice because it's incorrect when one extension is a prefix of another's name. This will almost surely not make a difference in practice but do it for correctness anyway.
* context_drm_egl: use mpegl_get_display() helper over own codesfan52021-11-171-12/+7
| | | | | | Although there are no known problems with this, using the helper should be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay over eglGetPlatformDisplayEXT if available.
* stream_dvb: add missing mutex unlockOliver Freyermuth2021-11-161-0/+1
| | | | | | | This deadlock was not triggered in real use since configuration validity does not change at runtime. closes #9459
* meson: fix build on androidDudemanguy2021-11-161-18/+28
| | | | | | | The original implementation had some errors with regards to android. Add a couple of missing files, add the android library, fix the aviocontext bytes_read check, fix egl-android, and rearrange/tidy up the vulkan handling.
* vo_gpu: vulkan: open DRM render fd when using VK_KHR_displayPhilip Langdale2021-11-151-2/+102
| | | | | | | | | | | | | | | While the basic Vulkan Display context can theoretically drive the display without the involvement of any non-Vulkan code, that prevents us from using VAAPI acceleration. When initialising VAAPI without a window system, we need to provide it with an opened DRM render fd corresponding to the device to use. In the context of using VK_KHR_display, that means we need to identify which DRM device matches the selected Vulkan device, and then open its render fd and set the necessary state that VAAPI expects to find. With that done, the normal VAAPI<->Vulkan interop can kick in and we get working acceleration
* meson: check for x11 when building the xv optionDudemanguy2021-11-151-1/+5
| | | | | Obvious oversight in the original PR for the meson build. The xv option requires x11 to function. Check for this by using the require method.
* meson: minor QOL and logic tweaksDudemanguy2021-11-152-20/+39
| | | | | | | | | | | 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.
* meson: also check for generic lua.pcDudemanguy2021-11-152-2/+3
| | | | | Some systems have only a "lua.pc" file which contains version information inside it. Check those as well.
* meson: fix -Werror=format-security flagDudemanguy2021-11-151-1/+4
| | | | | | | | This test fails because the compiler object does not have -Wformat when it tries this flag. To fix this this, we have to pass both -Wformat and -Werror=format-security at the same time during the test. This requires us to use has_multi_arguments so this flag needs to be pulled out of this array and tested separately.
* ytdl_hook.lua: improve check for sub language before inserting all-subsUmar Javed2021-11-151-1/+1
| | | | | | | youtube-dl and yt-dlp both support --sub-langs and --srt-lang in addition to --sub-lang for defining languages of subtitles. This hook only checked for sub-lang in --ytdl-raw-options and inserted --all-subs in its absence.
* options: const annotate all m_opt_choice_alternatives accessorsEmil Velikov2021-11-153-16/+17
| | | | | | | Constant data, most accessors are good but some were missing the explicit notation. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: const annotate m_obj_list accessorsEmil Velikov2021-11-152-2/+2
| | | | | | | Nearly all the code base correctly references the data as constant. But a couple of instances - fix those. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* options: remove always true m_obj_list::allow_unknown_entriesEmil Velikov2021-11-155-10/+1
| | | | | | | Ever instance of m_obj_list is a constant and for all of them, the field is true. Just remove the field all together. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
* DOCS/options: fix `target-colorspace-hint` typoMehul Mittal2021-11-141-1/+1
|
* ci: add meson buildsDudemanguy2021-11-145-36/+160
| | | | | | | | Update the github workflows to also do meson builds for every OS. Additionally, make every workflow execute the built mpv executable (except for windows and FreeBSD's waf executable) to make sure that it runs. As an aside, FreeBSD unfortunately is a bit less elegant since it is in a VM.
* build: add meson build supportDudemanguy2021-11-1419-5/+2240
| | | | | | Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
* demux_edl: rename ebml_defs.c to ebml_defs.incDudemanguy2021-11-142-2/+2
| | | | | | | | | | | The extension is completely arbitrary since ebml_defs.c isn't a real c file that actually is compiled at any point in time. It's just used as an include. The reason for changing the extension is because meson needs to add this to its list of sources for dependency/ordering purposes. Understandably, meson will try to compile any .c file added to a c project executable object. Obviously, this compilation will never succeed, and this shouldn't be compiled anyways. Just make it .inc instead.
* TOOLS/matroska.py: support outputting to fileDudemanguy2021-11-141-2/+7
| | | | | Like the previous commit, it's better to just output it to a file for meson.
* TOOLS/file2string.py: support outputting to fileDudemanguy2021-11-141-1/+6
| | | | | | | Another modification for the upcoming meson build. Meson can capture the stdout and redirect it to a file. However, this is considered a hack. It's better to just add a few lines to this script and write a file directly.
* TOOLS: add macos-swift-lib-directory.py scriptDudemanguy2021-11-141-0/+42
| | | | | | | Apple is great and forces us to do a lot of weird checks because they randomly move the location of the swift libraries around. Make a specific python script for checking various locations and write the output to stdout for meson.
* TOOLS: add macos-sdk-version.py scriptDudemanguy2021-11-141-0/+68
| | | | | | | | Building for macos requires us to check the macos sdk path as well as the sdk version that is on the system. To do this, let's steal the logic that's in the compiler_swift.py check from the waf build. This returns a comma-delinated string. The first entry is the absolute path to the sdk. The second entry is the detected macos sdk version.
* build: add version.py for generating version.hDudemanguy2021-11-141-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | version.h is essential for building, and its generation was done by a shell script. Strictly speaking, python should in general be more portable (windows), and would be better for the upcoming meson build to simply just execute a python script. version.py has some small differences with version.sh which shouldn't matter but they are noted below. - version.sh accepted several arguments that seemed useless (like --cwd). These were removed from version.py. - version.py takes either no arguments (prints the version) or it takes exactly one argument specifying the complete path of where the header should be generated. - version.sh attempted to read a file named "snapshot_version". The comments noted that this was for "daily tarball snapshots". Such a file does not exist in the source tree, and it's not really clear that anyone actually uses this. This logic was removed from version.py. - version.py reads the SOURCE_DATE_EPOCH environment variable. Some distros use this for reproducible builds. Technically you could also just disable the build date but this is only a couple of extra lines and maybe it's prettier than UNKNOWN. - version.py also doesn't attempt to display timezone information in the build date. It only shows UTC time.
* egl_helpers: remove EGL_OPENGL_ES3_BITDudemanguy2021-11-111-2/+1
| | | | | | | | | | | | | | d2e8bc449986e012f257249a996386bd323febd0 was the the commit that originally introduced the usage of this bit. As the message states, the purpose was to force creating GLES 3 contexts on drivers that do not return a higher version context than what was requested. With the recent opengl refactors, mpv's gl selection has already moved away from such complicated queries. Perhaps when that commit was added things were different, but nowadays it seems like Mesa simply returns the highest driver version available that is compatibile with the request (i.e. requesting GLES 2 returns a GLES 3 context on my machine). In that case, let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break GLES 2 only machines. Fixes #9431.
* context_drm_egl: use eglCreatePlatformWindowSurfaceEXT if availablesfan52021-11-111-2/+12
| | | | | This is identical to eglCreateWindowSurface but should be preferred as part of EGL's platform extension.
* context_drm_egl: add support for BGR surface formatsPhilip Langdale2021-11-103-3/+34
| | | | | | | | | | | | The new GBM supporting nvidia drivers declare support for 10bit surfaces using BGR ordering, rather than RGB, so add support for them. We've also seen examples of hardware supporting BGR8888 but not RGB8888 so let's support those too. Of course, the nvidia EGL driver doesn't publish support for any 10bit formats so you can't actually do 10bit display. Perhaps they'll eventually fix that.
* context_drm_egl: use gbm_surface_create_with_modifiersPhilip Langdale2021-11-102-10/+94
| | | | | | | | | The GBM supporting nvidia driver doesn't support creating surfaces without modifiers and using modifiers is more and more recommended as the right way to do this. Enumerating modifiers is painfully verbose, but necessary if we are to allow the driver to pick the best possible one.
* ao_oss: define PATH_DEV_MIXER as it is an internal defineJan Ekström2021-11-101-0/+1
| | | | | | | | This fixes a mismatch between configure working and build time failing with Linux + OSSv4, enabling compilation on Debian based Linux systems with the oss4-dev package. Fixes #9378
* ci/build-freebsd: require OSSv4 AO to be enabledJan Ekström2021-11-101-0/+1
|
* vo_gpu_next: fix slight performance regressionNiklas Haas2021-11-101-3/+1
| | | | | | | | This logic, which was working around a libplacebo bug, ended up always alpha blending - even for sources without an alpha channel. This caused a minor slowdown to be constantly enabled. Due to the recent bump to libplacebo v170, this is no longer needed.
* vo_gpu_next: Initialize `pl_frame_mix`Starsam802021-11-091-1/+1
| | | | | Without initializing, the random data causes the `pl_render_image_mix` function to abort with a SIGSEGV.
* vo_gpu_next: implement HDR passthroughNiklas Haas2021-11-083-0/+66
| | | | | | | | Completely untested, since Linux still can't into HDR in 2021. Somebody please make sure it works. Technically covers #8219, since gpu-context=drm can be combined with vo=gpu-next.
* vo_gpu_next: drop PL_API_VER checksNiklas Haas2021-11-081-8/+0
| | | | These are no longer needed with the minimum version bump.
* vo_gpu_next: fix resource exhaustion on minimized windowsNiklas Haas2021-11-082-4/+10
| | | | | | | | This required an upstream API change to implement in a way that doesn't unnecessarily re-push or upload frames that won't be used. I consider this a big enough bug to justify bumping the minimum version for it. Closes #9401
* wayland: remove bogus scale_change variableDudemanguy2021-11-082-24/+1
| | | | | | | | | This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993 for unclear reasons (way to go me). This concept is clearly incorrect. It doesn't matter what state the window is in. As soon as mpv detects a scale change, it needs to reset the buffer scale of the window. Just remove all this junk and put wl_surface_set_buffer_scale in set_surface_scaling like it should be. Related issue: #9426.
* vo_gpu_next: add automatic translation for ewa_lanczossharpNiklas Haas2021-11-071-0/+7
| | | | | | | This one hits a lot of people. Probably because the man page explicitly recommends it. Fixes #9408
* vo_gpu_next: implement --dither-depthNiklas Haas2021-11-071-0/+8
| | | | | | I somehow completely forgot about this option existing. Closes #9416
* vo_gpu_next: remove --builtin-scalers optionNiklas Haas2021-11-072-10/+0
| | | | | | | | | | | Looking at this again I'm not sure it does anything useful at all. The man page entry is also wrong: `bicubic` is not affected, only `bicubic_fast`, and those filters are not configurable anyways. So this would only ever be a debugging option, and I don't see a pressing need for it. No interface-change.rst update because it only just got added anyways.
* f_lavfi: replace deprecated avfilter_pad_countsfan52021-11-051-10/+10
|
* audio: replace deprecated av_mallocz_arraysfan52021-11-051-1/+1
|
* vo_gpu_next: call start_frame in vulkan/context.cDudemanguy2021-11-042-2/+12
| | | | | | | | | In practice, this is for wayland. vo_gpu_next doesn't check the check_visible parameter since it didn't descend into the vulkan/context.c file when starting a frame. To make this happen, just call the start_frame function pointer but pass NULL as the ra_fbo. In there, we can do the visibility checks and after that bail out of the start_frame function if ra_fbo is NULL.
* wayland_vk: rename start_frame to check_visibleDudemanguy2021-11-043-9/+10
| | | | | | | | | | This vulkan-specific parameter was poorly named and probably causes confusion. Just rename it to check_visible instead to make clear what is going on here. Only wayland uses it for now but in theory anyone else can. As an aside, wayland egl accomplishes this by using an external swapchain instead (an opengl-only concept in the mpv code). This may or may not need to be changed in the future when gpu-next gets opengl support.
* manpage: document --sharpen not affecting vo_gpu_nextNiklas Haas2021-11-031-1/+1
| | | | Fixes https://github.com/mpv-player/mpv/issues/9387
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-0314-22/+22
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* vo_gpu_next: fix --tone-mapping-param mappingNiklas Haas2021-11-031-0/+2
| | | | | | vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default. Fixes https://github.com/mpv-player/mpv/issues/9386
* vo_gpu_next: add new libplacebo-based rendererNiklas Haas2021-11-039-2/+1499
| | | | | | | | |