summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* demux: add a back buffer and the ability to seek into itwm42017-10-212-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | This improves upon the previous commit, and partially rewrites it (and other code). It does: - disable the seeking within cache by default, and add an option to control it - mess with the buffer estimation reporting code, which will most likely lead to funny regressions even if the new features are not enabled - add a back buffer to the packet cache - enhance the seek code so you can seek into the back buffer - unnecessarily change a bunch of other stuff for no reason - fuck up everything and vomit ponies and rainbows This should actually be pretty usable. One thing we should add are some properties to report the proper buffer state. Then the OSC could show a nice buffer range. Also configuration of the buffers could be made simpler. Once this has been tested enough, it can be enabled by default, and might replace the stream cache's byte ringbuffer. In addition it may or may not be possible to keep other buffer ranges when seeking outside of the current range, but that would be much more complex.
* vo_gpu: add rgba16hf to the list of FBO formatsJames Ross-Gowan2017-10-181-3/+3
| | | | | | | This should be functionally identical to rgba16f, since the formats only differ in their representation on the CPU, but it could be useful for RA backends that don't expose rgba16f, like Vulkan. It's definitely useful for the WIP D3D11 backend.
* video: add mp_image_params.hw_flags and add an examplewm42017-10-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems this will be useful for Rokchip DRM hwcontext integration. DRM hwcontexts have additional internal structure which can be different depending on the decoder, and which is not part of the generic hwcontext API. Rockchip has 1 layer, which EGL interop happens to translate to a RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple layers. Both will use sw_format=nv12, and thus are indistinguishable on the mp_image_params level. But this is needed to initialize the EGL mapping and the vo_gpu video renderer correctly. We hope that the layer count is enough to tell whether EGL will translate the data to a RGB texture (vs. 2 texture resembling raw nv12 data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE. This commit adds the flag, infrastructure to set it, and an "example" for D3D11. The D3D11 addition is quite useless at this point. But later we want to get rid of d3d11_update_image_attribs() anyway, while we still need a way to force d3d11vpp filter insertion, so maybe it has some justification (who knows). In any case it makes testing this easier. Obviously it also adds some basic support for triggering the opaque format for decoding, which will use a driver-specific format, but which is not supported in shaders. The opaque flag is not used to determine whether d3d11vpp needs to be inserted, though.
* video: make it possible to always override hardware decoding formatwm42017-10-162-0/+15
| | | | | | | | Mostly an obscure option for testing. But --videotoolbox-format can be deprecated, as it becomes redundant. We rely on the libavutil hwcontext implementation to reject invalid pixfmts, or not to blow up if they are incompatible.
* vo_gpu: semi-fix --gpu-context/--gpu-api options and help outputwm42017-10-161-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was confusing at best. Change it to output the actual choices. (Seems like in the end it's always me who has to clean up other people's bullshit.) Context names were not unique - but they should be, so fix it. The whole point of the original --opengl-backend option was to side-step the tricky auto-detection, so you know exactly what you get. The goal of this commit is to make --gpu-context work the same way. Fix the non-unique names by appending "vk" to the names. Keep in mind that this was not suitable for slecting the "UI" backend anyway, since "x11" would force GLX, whereas people on not-NVIDIA actually want "x11egl". Users trying to use --gpu-context=x11 to force the X11 backend would always end up with GLX, which would at least break VAAPI hardware decoding for them. Basically the idea that this option could select the "UI" type is completely broken - it selects an implementation, which implies a UI. Selecting the UI type This would require a separate mechanism. (Although in theory this separate mechanism could be part of the --gpu-context option - in any case, someone would have to implement it.) To achieve help output that can actually be understood, just duplicate the code. Most of that code is duplicated anyway, and trying to share just the list code with the result of making the output unreadable doesn't make too much sense. If we wanted to save code/effort, we could just remove the help output altogether. --gpu-api has non-unique entries, and it would be nice to group them (e.g. list all OpenGL capable contexts with "opengl"), but C makes this simple idea too much of a pain, so don't do it. Also remove a stray tab from the android entry on the manpage.
* manpage: add Vulkan WSI extension name for --gpu-context=winJames Ross-Gowan2017-10-141-1/+1
| | | | This matches the other Vulkan contexts.
* options: add --vlang switchwm42017-10-131-0/+3
| | | | For symmetry with --alang and --slang. 100% useless, but why not?
* stats: clarify documentationJulian2017-10-131-7/+7
| | | | | Change true/false to yes/no because lua script configs only take these values for booleans.
* manpage: correct some comments about ordered chapterswm42017-10-111-6/+5
| | | | | Ordered chapters behavior changed at some point, and all of this was outdated.
* stats: add documentationJulian2017-10-092-0/+164
| | | | stats.rst is heavily based on osc.rst
* lua: integrate stats.lua scriptJulian2017-10-091-0/+5
| | | | | | | | | Signed-off-by: wm4 <wm4@nowhere> Rename --stats to --load-stats-overlay and add an entry to options.rst over the original commit. Signed-off-by: wm4 <wm4@nowhere>
* 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/<