summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: add android opengl backendAman Gupta2017-10-092-1/+7
| | | | | | | | | | At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
* vo: add mediacodec_embed output driverAman Gupta2017-10-091-0/+8
| | | | | Allows rendering IMGFMT_MEDIACODEC frames directly onto an android.view.Surface
* hwdec: add mediacodec hardware decoder for IMGFMT_MEDIACODEC framesAman Gupta2017-10-091-0/+5
|
* hwdec: rename mediacodec to mediacodec-copyAman Gupta2017-10-092-1/+3
|
* command: drop "audio-out-detected-device" propertywm42017-10-092-4/+2
| | | | | | Coreaudio stopped setting it a few releases ago (66a958bb4fa). There is not much of a user- or API-visible change, so remove it without deprecation.
* Revert "wayland_common: add support for embedding"Rostislav Pehlivanov2017-10-051-4/+0
| | | | This reverts commit 8d8d4c5cb1b3553215a8ba547d4db463fdc88831.
* wayland_common: add support for embeddingRostislav Pehlivanov2017-10-051-0/+4
|
* 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-041-2/+5
| | | | | | | 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.
* 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
* 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.
* vo_gpu: force layout std430 for PCsNiklas Haas2017-09-291-3/+1
| | | | | | | | 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: make the vertex attribs dynamicNiklas Haas2017-09-281-4/+0
| | | | | | | | | | | | | | | | 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.
* 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).
* 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.
* manpage: document --gpu-api=vulkanNiklas Haas2017-09-261-0/+2
|
* vo_gpu: vulkan: add support for waylandRostislav Pehlivanov2017-09-261-1/+1
|
* vo_gpu: vulkan: generalize SPIR-V compilerNiklas Haas2017-09-261-0/+17
| | | | | | | | | | | | | | 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-261-6/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_gpu: fix gamma scaleNiklas Haas2017-09-211-11/+11
| | | | | | This never really made sense since the BT.1886 changes. It should get *brighter* for bright rooms, not darker for dark rooms. Picked some new values that seemed reasonable-ish.
* vo_gpu: convert windows/osx hwdecs/contexts to new APIJames Ross-Gowan2017-09-211-19/+0
|
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-215-104/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* options: remove --heartbeat-cmd and --heartbeat--intervalwm42017-09-182-44/+3
| | | | | | | | | This mechanism uses system() and shouldn't even exist. x11_common.c has its own solution for the original problem (disabling Linux DE screensavers without MPlayer/mpv having to link a dbus lib). If that is not sufficient, you can create a simple Lua script. Incidentally fixes #4888.
* Release 0.27.0v0.27.0Martin Herkt2017-09-131-1/+1
|
* vo_opengl: add a gamut warning featureNiklas Haas2017-09-101-0/+12
| | | | | | | | This clearly highlights all out-of-gamut/clipped pixels. (Either too bright or too saturated) Has some (documented) caveats. Also make TONE_MAPPING_CLIP stop actually clamping the value range (it's unnecessary and breaks this feature).
* man: correct default for --audio-file-autoMartin Herkt2017-09-101-4/+3
| | | | Fixes #4851
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* input: use mnemonic names for mouse buttonsJames Ross-Gowan2017-09-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv's mouse button numbering is based on X11 button numbering, which allows for an arbitrary number of buttons and includes mouse wheel input as buttons 3-6. This button numbering was used throughout the codebase and exposed in input.conf, and it was difficult to remember which physical button each number actually referred to and which referred to the scroll wheel. In practice, PC mice only have between two and five buttons and one or two scroll wheel axes, which are more or less in the same location and have more or less the same function. This allows us to use names to refer to the buttons instead of numbers, which makes input.conf syntax a lot easier to remember. It also makes the syntax robust to changes in mpv's underlying numbering. The old MOUSE_BTNx names are still understood as deprecated aliases of the named buttons. This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in the codebase, since I think both would benefit from using names over numbers, especially since some platforms don't use X11 button numbering and handle different mouse buttons in different windowing system events. This also makes the names shorter, since otherwise they would be pretty long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they weren't used. Names are the same as used in Qt: https://doc.qt.io/qt-5/qt.html#MouseButton-enum
* DOCS/contribute.md: coding style exceptionwm42017-08-301-0/+2
|
* DOCS/interface-changes.rst: don't suggest @deinterlace labelwm42017-08-231-2/+2
| | | | | --vf-defaults always applies, and the label is ignored. So don't suggest using it, it would be misleading.
* video: change --deinterlace behaviorwm42017-08-223-12/+22
| | | | | | | | | | | | This removes all GPL only code from it, and that's the whole purpose. Also happens to be much simpler. The "deinterlace" option still sort of exists, but only as runtime changeable option. The main change in behavior is that the property will not report back the actual deint state. Or in other words, if inserting or initializing the filter fails, the deinterlace property will still return "yes". This is in line with most recent behavior changes to properties and options.
* manpage: video equalizer properties now behave differentlywm42017-08-221-4/+0
| | | | No more special behavior.
* manpage: remove removed "osd" commandwm42017-08-221-4/+0
| | | | Someone pointed this out on github.
* vf_eq: remove this filterwm42017-08-222-26/+1
| | | | | | | | | Both the video equalizer command/option glue, which drives this filter, as well as the filter itself are slightly GPL contaminated. So it goes. After this commit, "--vf=eq" will actually use libavfilter's vf_eq (if FFmpeg was compiled in GPL mode), but it has different options and will not listen to the equalizer VOCTRLs.
* TOOLS/lua/autodeint: update to lavfi-bridgeRicardo Constantino2017-08-211-1/+0
| | | | | Also use lavfi setfield instead of removed field-dominance. Remove missing remainder of field-dominance in docs.
* ao_rsound: allow setting the hostwm42017-08-211-1/+2
| | | | | | | | Completely untested (rsound dev libs unavailable on my system). Trivial enough that it's very likely that it'll just work. No port selection, but could be added by parsing it as part of the device name. Should fix #4714.
* video: add metadata handling for spherical videowm42017-08-211-0/+10
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* options: correct two remaining instances of singular `file-path` optionsFrédéric Brière2017-08-181-2/+2
| | | | These were left behind by e4bc563fd2dc.
* manpage: update --lavfi-complex descriptionwm42017-08-171-4/+7
|
* options: change --loop semanticswm42017-08-142-5/+6
| | | | As announced by the previous deprecation.
* player: add --track-auto-selection optionwm42017-08-122-0/+14
| | | | I imagine this is useful. Or maybe it isn't.
* player: make --lavfi-complex changeable at runtimewm42017-08-121-0/+3
| | | | | | | | Tends to be somewhat glitchy if subtitles are enabled, and you enable and disable tracks. On error, this will disable --lavfi-complex, which will result in whatever behavior.
* man/mpv: document bd:// expected titles and title listRicardo Constantino2017-08-111-0/+5
|
* vo_opengl: further GL API use separationwm42017-08-071-0/+5
| | | | | | | | | | | | | | | Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
* cocoa: add an option to disable the native macOS fullscreenAkemi2017-08-061-0/+4
| | | | Fixes #4014
* vo_opengl: make fbotex helper use rawm42017-08-051-0/+3
| | | | | | | | Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
* w32_common: handle media keysJames Ross-Gowan2017-08-051-1/+1
| | | | | | | | | | | | | | | | | This was attempted before in fc9695e63b5b, but it was reverted in 1b7ce759b1f4 because it caused conflicts with other software watching the same keys (See #2041.) It seems like some PCs ship with OEM software that watches the volume keys without consuming key events and this causes them to be handled twice, once by mpv and once by the other software. In order to prevent conflicts like this, use the WM_APPCOMMAND message to handle media keys. Returning TRUE from the WM_APPCOMMAND handler should indicate to the operating system that we consumed the key event and it should not be propogated to the shell. Also, we now only listen for keys that are directly related to multimedia playback (eg. the APPCOMMAND_MEDIA_* keys.) Keys like APPCOMMAND_VOLUME_* are ignored, so they can be handled by the shell, or by other mixer software.
* vo_opengl: support embedded ICC profilesNiklas Haas2017-08-031-0/+6
| | | | | | | | | | | | | | | | This currently only works when using lcms-based color management (--icc-profile-*). In principle, we could also support using lcms even when the user has not specified an ICC profile, by generating the profile against a fixed reference (--target-prim/--target-trc) instead. I still might do that some day, simply because 3dlut provides a higher quality conversion than our simple gamut mapping does for stuff like BT.2020, and also because it's now needed to enable embedded ICC profiles. But that would be a separate change, so preserve the status quo for now. (Besides, my opinion is still that you should be using an ICC profile if you care about colors being accurate _at all_)
* vo_opengl: make compute shaders more flexibleNiklas Haas2017-08-031-7/+17
| | | | | | This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
* vo_opengl: simplify/fix user shader textureswm42017-08-031-10/+12
| | | | | | | | | | | | | | | | | | | | This broke float textures, which were actually used by some shaders. There were probably some other bugs as well. Lots of code can be avoided by using ra_tex_params directly, so do that. The main change is that COMPONENT/FORMAT are replaced by a single FORMAT directive, which takes different parameters now. Due to the mess with 16/32 bit float textures, and because we want to support other APIs than just GL in the future, it's not really clear how this should be handled, and the nice component/type separation makes things actually harder. So just jump the gun and use the ra_format.name names, which were originally meant mostly for debugging. (This is probably something that will be regretted later.) Still only superficially tested, but seems to work. Fixes #4708.
* vo_opengl: generalize HDR tone mapping to gamut mappingNiklas Haas2017-08-032-7/+10
| | | | | | | | | | | | | | | | | | | | | | Since this code was already written for HDR, and is now per-channel (because it works better for HDR as well), we can actually reuse this to get very high quality gamut mapping without clipping. The only required change is to move the tone mapping from before the gamut map to after the gamut map. Additonally, we need to also account for changes in the signal range as a result of applying the CMS when we compute ref_peak, which is fortunately pretty easy because we only need to consider the case of primaries mapping to themselves. Since `HDR` no longer really makes sense as a label, rename it to `--tone-mapping` in general. Also fits better with `--tone-mapping-desat` etc. Arguably we could also rename `--hdr-compute-peak`, but that option is basically only useful for HDR content anyway because we don't need information about the signal range for gamut mapping. This (finally!) gives us reasonably high quality gamut mapping even in the absence of an ICC profile / 3DLUT.
* vo_opengl: support loading custom user texturesNiklas Haas2017-07-271-13/+48
| | | | | | | | | | | Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
* vo_opengl: adjust the rules for linearizationNiklas Haas2017-07-241-2/+4
| | | | | | | | | | | | | | | | | | Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
* manpage: expand --hwdec warningsNiklas Haas2017-07-241-17/+36
| |