summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wayland_common: add support for embeddingRostislav Pehlivanov2017-10-053-0/+9
|
* wayland_common: reset the LIVE_RESIZING flag when resizing endsRostislav Pehlivanov2017-10-051-10/+14
| | | | | | The VO code resets each flag individually, and it doesn't do it for this one. Also make the prints use the struct names rather than the hardcoded ones, forgot to add those to the last wayland_common commit.
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-055-43/+8
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* DOCS/interface-changes.rst: mention --log-file behavior changewm42017-10-051-0/+1
| | | | See previous commit.
* msg: make --msg-level affect --log-file toowm42017-10-042-3/+6
| | | | | | | But --msg-level can only raise the log level used for --log-file, because the original idea with --log-file was that it'd log verbose messages to disk even if terminal logging is lower than -v or fully disabled.
* player: change a minor code fragment to LGPLwm42017-10-041-5/+0
| | | | | | | Seems absurd to keep this under GPL, since it's only a tiny code fragment (that would always look the same, no matter if you rewrote it independently), but now I got proper permission from the original author anyway.
* wayland_common: don't hardcode protocol names during registryRostislav Pehlivanov2017-10-041-8/+8
| | | | Use the interface names from the wl_interface structs they provide.
* README: drop support for Windows VistaMartin Herkt2017-10-041-1/+1
| | | | See #4952.
* wayland_common: rewrite from scratchRostislav Pehlivanov2017-10-0311-1058/+1281
| | | | | | | | | | | | The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
* vo_wayland: removeRostislav Pehlivanov2017-10-037-1062/+0
| | | | | This VO was buggy and never worked correctly. Like with wayland_common, it needs to be rewritten from scratch.
* demux_mkv: replace deprecated av_copy_packet_side_data()wm42017-10-031-4/+2
| | | | | It's deprecated, and av_packet_copy_props() is nearly equivalent. It's also more widely supported.
* osx: add some common paths to our $PATH when started from bundleAkemi2017-10-031-0/+8
| | | | | | | | | | | with the previous commit we removed the ability of loading the standard shell environment. this exact behaviour can only be re-added by either invoking the standard shell in a background process and reading it's environment vars or by manually reading all the various shell configs. both ways are kinda dirty and the former was already rejected before. for now we will just add some commonly used paths, when started from the bundle, so it can find the binaries used by mpv again. for example the youtube-dl one for our youtube-dl hook.
* osx: fix bundle on macOS High Sierra (10.13)Akemi2017-10-036-20/+29
| | | | | | | | | | | | | | | | | | | | | | Apple slightly changed the App bundle mechanism which broke wrapper scripts that invoke the actual binary. it caused the bundle to always open a new instance of mpv instead of reusing the currently running one. just removing the wrapper script would lead to several regressions, so it was replaced with a symlink to the bundle binary. detection if mpv was started from the bundle was replaced by comparing the execution name of the binary, eg the name of the symlink "mpv-bundle". additionally, because we load a standard config from the Resources folder of the bundle again, we prevent that config from being loaded if mpv wasn't started via the bundle. the psn argument has to be removed manually again. the ability of loading your standard shell environment has been removed with the wrapper. a substitution will be added with another commit. as a side effect this fixes an issues when zsh was used with common NodeJS configuration scripts. Fixes #4926 #4866
* vo_gpu: gl: implement proper extension string searchwm42017-10-023-10/+23
| | | | | | | The existing code in check_ext() avoided false positive due to sub-strings, but allowed false negatives. Fix this with slightly better search code, and make it available as function to other source files. (There are some cases of strstr() still around.)
* DOCS/compile-windows.md: update for changes to mpv and MSYS2James Ross-Gowan2017-10-021-21/+19
| | | | | | | | | | | | - Don't recommend libdvdnav, since DVD support isn't compiled by default anymore. - Take advantage of the new $MINGW_PACKAGE_PREFIX and $MSYSTEM_PREFIX variables to make the build commands independent from the mingw-w64 build environment being used. - Invoke /usr/bin/python3 directly, since I've heard some packages have started to depend on mingw-w64 versions of Python, but our build scripts only work with the MSYS2 version. - Reword the MSYS2 install instructions to try to prevent common errors.
* Man page: fix typoKranky K. Krackpot2017-10-011-2/+2
| | | Man page: fix typo as of https://github.com/mpv-player/mpv/issues/4913
* vo_gpu: enable 3DLUTs in dumb modeNiklas Haas2017-09-301-1/+3
| | | | | | Unless FBOs are unsupported, this works. In particular, it's required to get ICC profiles working in voluntary dumb mode. So instead of blanket-disabling it, only disable it in the !have_fbo false case.
* vf_vavpp: restrict allowed sw upload formats to nv12/yuv420pwm42017-09-301-20/+3
| | | | | | | | | | | | | | | | | | | | We allowed any input format that was generally supported by libva, but this is probably nonsense, as the actual surface format was always fixed to nv12. We would have to check whether libva can upload a given pixel format to a nv12 surface. Or we would have to use a separate frame pool for input surfaces with the exact sw_format - but then we'd also need to check whether the vaapi VideoProc supports the surface type. Hardcode nv12 and yuv420p as input formats, which we know can be uploaded to nv12 surfaces. In theory we could get a list of supported upload formats from libavutil, but that also require allocating a dummy hw frames context just for the query. Add a comment to the upload code why we can allocate an output surface for input. In the long run, we'll probably want to use libavfilter's vaapi deinterlacer, but for now this would break at least user options.
* vaapi: replace error macro implementationwm42017-09-302-12/+3
| | | | | | | | | | The current check_va_status() function could probably be argued to be derived from the original VAAPI's patch check_status() function, thus GPL-only. While I have my doubts that it applies to an idiom on this level, it's better to replace it. Similar idea, different expression equals no copyright association. An earlier commit message promised this, but it was forgotten.
* Copyright: remove deleted file from listwm42017-09-301-1/+0
|
* video: fix green shitwm42017-09-301-1/+1
|
* manpage: update --blend-subtitles affected optionsLeo Izen2017-09-291-1/+1
| | | | | | Changed the reference from --gpu-gamma to --gamma-factor, and changed the reference from --post-shader to --glsl-shaders, in order to reflect actual changes to the option names.
* vaapi: change license to LGPLwm42017-09-296-20/+19
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* vaapi: move legacy code to vo_vaapi.cwm42017-09-293-440/+310
| | | | | | Done for license reasons. vo_vaapi.c is turned into some kind of dumpster fire, and we'll remove it as soon as I'm mentally ready for unkind users to complain about removal of this old POS.
* vf_vavpp: use error checking macrowm42017-09-291-19/+11
|
* vf_vavpp: use libavutil hw frames API for frame pool and uploadwm42017-09-295-49/+119
| | | | | Another step to get rid of the legacy crap in vaapi.c. (Most is still kept, because it's in use by vo_vaapi.c.)
* vaapi: use newer libavutil vaapi pixfmt namewm42017-09-291-1/+1
| | | | | AV_PIX_FMT_VAAPI_VLD is clearly deprecated - it just doesn't raise any compiler warnings.
* vaapi: minor changeswm42017-09-291-7/+7
| | | | | | | | | | | | This is for relicensing. Some of this code is loosely based on vo_vaapi.c from the original MPlayer-vaapi patches. Most of the code has changed, and only the initialization code and check_status() look remotely similar. The initialization code is changed to be like Libav's (hwcontext_vaapi.c). check_va_status() is just a C idiom, but to play it safe, we'll either drop it from LGPL code (or recreate it). vaapi.c still contains plenty of code from the original patches, but the next commits will move them out of the LGPL code paths.
* vo_gpu: vulkan: reword commentNiklas Haas2017-09-291-3/+4
| | | | | This is fixed upstream (and we now know it's a driver bug) so reword the comment.
* vo_gpu: force layout std430 for PCsNiklas Haas2017-09-292-4/+2
| | | | | | | | Seems to be fixed upstream in the nvidia driver, so it's probably a good idea to 1. force the layout and 2. remove the warning, as it now actually works. Users with older drivers would run into errors, but they can still use shaderc as a replacement. (And it's not like the old status quo was any better)
* vo_gpu: fix --opengl-gamma redirectNiklas Haas2017-09-281-1/+1
| | | | | It still pointed at --gpu-gamma, but we decided on --gamma-factor instead.
* vo_gpu: set the correct number of vertex attribsNiklas Haas2017-09-281-2/+2
| | | | | | | This was always set to the length of the VAO, but it should have been set to the number of vertex attribs actually in use for this frame. No idea how that managed to survive the test framework on nvidia/linux, but ANGLE caught it.
* vo_gpu: vulkan: add support for WindowsJames Ross-Gowan2017-09-284-0/+113
|
* vo_gpu: make the vertex attribs dynamicNiklas Haas2017-09-287-104/+102
| | | | | | | | | | | | | | | | This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
* vo_gpu: kill some static arraysNiklas Haas2017-09-282-83/+69
| | | | | This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
* manpage: remove aphasemeter exampleswm42017-09-271-6/+1
| | | | | | | | | | Apparently this filter is broken in a weird way, which even makes some libavfilter functions segfault in certain conditions. Don't waste time with it and just remove the examples. Also adjust the "life" example description (certainly this filter is 100% worthless, but the example does demonstrate how to use source filters without any available input).
* audio: fix channel conversion with NA channelswm42017-09-271-1/+1
| | | | | | | | The case at hand was 5.1 -> fl-fr-fc-lfe-na-na (apparently triggered by ALSA). That means only the NA channels have to be cleared, but the result was actually that fc and lfe were cleared. This is due to a simple regression in the reorder code, which quite obviously got the index of the first NA channel wrong.
* vo_gpu: vulkan: indent queue family enumerationNiklas Haas2017-09-271-1/+1
| | | | Consistency
* vo_gpu: vulkan: normalize use of *Flags and *FlagBitsNiklas Haas2017-09-276-33/+31
| | | | | | | | | | | | FlagBits is just the name of the enum. The actual data type representing a combination of these flags follows the *Flags convention. (The relevant difference is that the latter is defined to be uint32_t instead of left implicit) For consistency, use *Flags everywhere instead of randomly switching between *Flags and *FlagBits. Also fix a wrong type name on `stageFlags`, pointed out by @atomnuker
* vo_gpu: vulkan: optimize redundant pipeline barriersNiklas Haas2017-09-261-5/+15
| | | | | | | | | | | | | | | Using renderpass layout transitions is more optimal and doesn't require a redundant pipeline barrier. Since our render passes are static and don't change throughout the lifetime of a ra_renderpass, we unfortunately don't have much flexibility here - so just hard-code SHADER_READ_ONLY_OPTIMAL as the output format as this will be the most common case. We also can't short-circuit the transition when we need to preserve the framebuffer contents, since that depends on the current layout; so we still use an explicit tex_barrier in this case. (Most optimal for this scenario would be an input attachment anyway)
* vd_lavc: cuda requires setting hw_device_ctxwm42017-09-262-1/+4
| | | | | | This restores cuda/cuvid under Windows. Cuvid is relatively useless under Windows, but this was requested.
* manpage: some --hwdec correctionswm42017-09-261-5/+2
| | | | | | | auto-copy selects more modes than the ones listed. It will always be outdated anyway. The GLX vaapi backend is never selected anymore, because it sucks.
* video: remove old videotoolbox supportwm42017-09-268-293/+2
| | | | | Like as in previous commits, you need a very recent FFmpeg (probably git master).
* wscript: remove redundant checkwm42017-09-261-6/+0
| | | | We're not using this function directly.
* video: drop old D3D11/DXVA2 supportwm42017-09-2614-1656/+11
| | | | | | | | | Now you need FFmpeg git, or something. This also gets rid of the last real use of gpu_memcpy(). libavutil does that itself. (vaapi.c still used it, but it was essentially unused, because the code path isn't really in use anymore. It wasn't even included due to the d3d-hwaccel dependency in wscript.)
* video: drop old cuda/cuvid hwaccelwm42017-09-264-123/+1
| | | | Just use FFmpeg 3.3 (or whatever it was) to get Cuvid support.
* manpage: document --gpu-api=vulkanNiklas Haas2017-09-261-0/+2
|
* vo_gpu: fix memleak in spirv.cNiklas Haas2017-09-261-1/+1
|
* vo_gpu: explicitly label storage image formatsNiklas Haas2017-09-261-1/+22
| | | | | | | | | | | | This is apparently required to get storage images working on windows/vulkan, and probably good practice either way. Not entirely sure if it's the best idea to be always storing the value as 32-bit float, but it should hardly matter in practice (since we're only writing one sample per thread). (Leaving them implicit requires the shaderStorageImageWriteWithoutFormat feature to be enabled, which the windows nvidia vulkan driver doesn't support, at least not for a GTX 670)
* vo_gpu: attempt to avoid UBOs for dynamic variablesNiklas Haas2017-09-264-2/+32
| | | | | | | | | This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
* vo_gpu: vulkan: add support for push constantsNiklas Haas2017-09-263-25/+112
| | | | Can in theory avoid updating the uniform buffer every frame
* vo_gpu: vulkan: add support for waylandRostislav Pehlivanov2017-09-268-10/+170
|
* vo_gpu: vulkan: generalize SPIR-V compilerNiklas Haas2017-09-2616-94/+571
| | | | | | | | | | | | | | In addition to the built-in nvidia compiler, we now also support a backend based on libshaderc. shaderc is sort of like glslang except it has a C API and is available as a dynamic library. The generated SPIR-V is now cached alongside the VkPipeline in the cached_program. We use a special cache header to ensure validity of this cache before passing it blindly to the vulkan implementation, since passing invalid SPIR-V can cause all sorts of nasty things. It's also designed to self-invalidate if the compiler gets better, by offering a catch-all `int compiler_version` that implementations can use as a cache invalidation marker.
* vo_gpu: vulkan: initial implementationNiklas Haas2017-09-2620-16/+3773
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
* vo_opengl_cb: fix deprecated option usageNiklas Haas2017-09-261-1/+1
| | | | opengl-debug was renamed to gpu-debug
* vo_gpu: fix possible segfault on shader miscompileNiklas Haas2017-09-231-5/+6
| | | | | Iterations after the first time will fail to realize that the pass was never created. This function's logic and control flow is so annoying...
* osc: fix rare stack overflow when changing visibility modeAvi Halachmi (:avih)2017-09-231-1/+6
| | | | | | | | | | | | | Under some conditions, hide_osc() was calling render(), which then called hide_osc() again, and so forth, until the stack overflows. Tracking the exact conditions where this happens (and then managing them to prevent it) is an excercise in futility. Remove the osc directly - instead of going through the entire rendering procedure just to end up rendering nothing. Fixes #4900 .
* js: fix broken mp.set_property_number, mp.set_property_nativeAvi Halachmi (:avih)2017-09-231-2/+2
| | | | | | Also implicitly fixes memory leak when mp.set_property_native was used, because the cleanup did not expect more allocations from the accidental use of mpv_get_property.
* vo_gpu: angle: fix misleading struct nameJames Ross-Gowan2017-09-231-2/+2
| | | | This should have been renamed when it stopped being empty.
* vo_gpu: handle texture initialization errors gracefullyNiklas Haas2017-09-233-19/+27
| | | | | | | | | | Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
* vo_gpu: reduce the --alpha=blend-tiles checkerboard intensityNiklas Haas2017-09-221-1/+1
|