summaryrefslogtreecommitdiffstats
path: root/DOCS/man/options.rst
Commit message (Collapse)AuthorAgeFilesLines
* audio: add global options for resampler defaultswm42018-01-131-10/+38
| | | | | | | | This is part of trying to get rid of --af-defaults, and the af resample filter. It requires a complicated mechanism to set the defaults on the resample filter for backwards compatibility.
* client API: remove ytdl=no defaultwm42018-01-131-2/+1
| | | | | | | | | | | | | | With the recent changes to the script it does not incur a startup delay by default due to starting youtube-dl and waiting for it. This was the main reason for making libmpv have a different default. Starting sub processes from a library can still be a bit fishy, but I think it's ok. Still mention it in the libmpv header. There were already other cases where libmpv would start its own processes, such as the X11 backend calling xdg-screensaver. (The reason why this is fishy is because UNIX process management sucks: SIGCHLD and the wait() syscall make sub processes non-transparent and could potentially introduce conflicts with code trying to use them.)
* command: make pause display the same osd-msg-bar as seekKevin Mitchell2018-01-071-3/+3
| | | | | | Previously, toggling pause would generate no osd response, and changing that wasn't even configurable. This was surprising to users who generally expect to see *where* pause / unpause is taking place (#3028).
* command: default to osd-msg-bar for seeksKevin Mitchell2018-01-071-6/+4
| | | | | | | | The previous default was osd-bar (unless the user specified --no-osd-bar, in which case case it was osd-msg). Aside from requiring some twisted logic to implement, this surprised users since osd-msg3 wasn't displayed when seeking with the keyboard (#3028), so the time seeked to was never displayed.
* manpage: fix typos in osd level descriptionsKevin Mitchell2018-01-071-3/+3
|
* ytdl_hook: add script option to revert to trying youtube-dl firstRicardo Constantino2018-01-071-0/+5
| | | | | Should only make a difference if most of the URLs you open need youtube-dl parsing.
* player: strictly never autoselect tracks from --external-fileswm42018-01-061-1/+2
| | | | | | | | | | | | | | | | Before this commit, some autoselection of tracks coming from files loaded with --external-files was still done. This commit removes all of it, and the only way to select a track is via the explicit stream selection options like --vid/--sid/--aid. I think this was always the original intention. The change could in theory still unintentionally surprise some users, so add a changelog entry. This does not affect --audio-file/--sub-file, even if these contain mismatching track types. E.g. if audio files passed to --audio-file contain subtitles, these should still be selected. Past feature requests indicate that users want this.
* vo_gpu: hwdec_dxva2dxgi: initial implementationJames Ross-Gowan2018-01-061-2/+3
| | | | | | | | | | | | | This enables DXVA2 hardware decoding with ra_d3d11. It should be useful for Windows 7, where D3D11VA is not available. Images are transfered from D3D9 to D3D11 using D3D9Ex surface sharing[1]. Following Microsoft's recommendations, it uses a queue of shared surfaces, similar to Microsoft's ISurfaceQueue. This will hopefully prevent surface sharing from impacting parallelism and allow multiple D3D11 frames to be in-flight at once. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554.aspx
* player: add --cache-pause-initial option to start in buffering statewm42018-01-031-0/+14
| | | | | | Reasons why you'd want this see manpage additions. Disabled by default, because it would increase latency of live streams by default. (Or well, at least it would be another problem when trying getting lower latency.)
* player: use fixed timeout for cache pausing (buffering) durationwm42018-01-031-0/+9
| | | | | | | | | | | | | | | This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option.
* manpage: slightly improve description of --cache-pause optionwm42018-01-031-3/+4
|
* vo_gpu/context_android: replace both options with android-surface-sizesfan52018-01-021-3/+1
| | | | This allows us to automatically trigger a VOCTRL_RESIZE (also contained).
* vo_gpu/android: fallback to EGL_WIDTH/HEIGHTAman Gupta2018-01-011-2/+4
| | | | | | | | | | Uses the EGL width/height by default when the user fails to set the android-surface-width/android-surface-height options. This means the vo-resize command is optional, and does not need to be implemented on android devices which do not support rotation. Signed-off-by: Aman Gupta <aman@tmm1.net>
* manpage: put android surface options on one lineKevin Mitchell2017-12-281-2/+1
| | | | This is required by rst2man.
* vd_lavc: add an option to explicitly workaround x264 4:4:4 bugwm42017-12-281-0/+12
| | | | | | Technically, the user could just use --vd-lavc-o with the same result. But I find it better to make this an explicit option, so we can document the ups and downs, and also avoid setting it for non-h264.
* player: add internal `vo-resize` commandsfan52017-12-271-1/+2
| | | | Intended to be used with the properties from previous commit.
* vo_gpu/context: Let embedding application handle surface resizessfan52017-12-271-0/+7
| | | | | The callbacks for this are Java-only and EGL does not reliably return the correct values.
* vo_gpu: vulkan: allow disabling async tf/compNiklas Haas2017-12-251-0/+17
| | | | | | | | | Async compute in particular seems to cause problems on some drivers, and even when supprted the benefits are not that massive from the tests I have seen, so it's probably safe to keep off by default. Async transfer on the other hand seems to work better and offers a more substantial improvement, so it's kept on.
* vo_gpu: vulkan: support split command poolsNiklas Haas2017-12-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a single primary queue, we generate multiple vk_cmdpools and pick the right one dynamically based on the intent. This has a number of immediate benefits: 1. We can use async texture uploads 2. We can use the DMA engine for buffer updates 3. We can benefit from async compute on AMD GPUs Unfortunately, the major downside is that due to the lack of QF ownership tracking, we need to use CONCURRENT sharing for all resources (buffers *and* images!). In theory, we could try figuring out a way to get rid of the concurrent sharing for buffers (which is only needed for compute shader UBOs), but even so, the concurrent sharing mode doesn't really seem to have a significant impact over here (nvidia). It's possible that other platforms may disagree. Our deadlock-avoidance strategy is stupidly simple: Just flush the command every time we need to switch queues, and make sure all submission and callbacks happen in FIFO order. This required lifting the cmds_pending and cmds_queued out from vk_cmdpool to mpvk_ctx, and some functions died/got moved as a result, but that's a relatively minor change. On my hardware this is a fairly significant performance boost, mainly due to async transfers. (Nvidia doesn't expose separate compute queues anyway). On AMD, this should be a performance boost as well due to async compute.
* vo_gpu: vulkan: properly track image dependenciesNiklas Haas2017-12-251-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | This uses the new vk_signal mechanism to order all access to textures. This has several advantageS: 1. It allows real synchronization of image access across multiple frames when using multiple queues for parallelism. 2. It allows using events instead of pipeline barriers, which is a finer-grained synchronization primitive that allows for more efficient layout transitions over longer durations. This commit also restructures some of the implicit transition code for renderpasses to be more flexible and correct. (Note: this technically drops the ability to transition the image out of undefined layout when not blending, but that was a bug anyway and needs to be done properly) vo_gpu: vulkan: remove no-longer-true optimization The change to the output_tex format makes this no longer true, and it actually seems to hurt performance now as well. So just don't do it anymore. I also realized it hurts performance when drawing an OSD, so it's probably not a good idea anyway.
* cache: lower default size to 2*10MBwm42017-12-231-2/+2
| | | | | | | | | | | | Reduce it from 75MB in both directions (forward/backwards) to 10MB each. The stream cache is kind of becoming useless in favor of the demuxer cache. Using both doesn't make much sense, because they will contain duplicated data for no reason. Still leave it at 10MB, which may help with mp4 a bit. libavformat's mp4 demuxer tends to seek too much, so we try to avoid triggering network level seeks by having some caching in the stream layer.
* demux: bump the demuxer cache readahead durationwm42017-12-231-1/+3
| | | | | | Set it to 10 hours, which is practically unlimited. (Avoiding use of "inf", since that might interact strangely with the option parser and such.)
* options: deprecate --ff- options and propertieswm42017-12-211-0/+2
| | | | | | | | | | | Some old crap which nobody needs and which probably nobody uses. This relies on a GCC extension: using "## __VA_ARGS__" to remove the comma from the argument list if the va args are empty. It's supported by clang, and there's some chance newer standards will introduce a proper way to do this. (Even if it breaks somewhere, it will be a problem only for 1 release, since I want to drop the deprecated properties immediately.)
* vo_mediacodec_embed: implement hwcontextAman Gupta2017-12-201-1/+0
| | | | Fixes vo_mediacodec_embed, which was broken in 80359c6615658f2784
* client API: change --stop-playback-on-init-failure defaultwm42017-12-171-5/+4
| | | | | | | | | | | | | | | | This was off for mpv CLI, but on for libmpv. The motivation behind this was that it would be confusing for applications if libmpv continued playback in a severely "degraded" way (without either audio or video), and that it would be better to fail early. In reality the behavior was just a confusing difference to mpv CLI, and has confused actual users as well. Get rid of it. Not bothering with a version bump, since this is so minor, and it's easy to ensure compatibility in affected applications by just setting the option explicitly. (Also adding the missing next-release-marker in client-api-changes.rst.)
* msg: bump up log level of --log-fileNiklas Haas2017-12-151-3/+3
| | | | This now logs -v -v by default, instead of -v.
* vd_lavc: rename --hwdec=rpi to --hwdec=mmalwm42017-12-151-2/+2
| | | | | | Annoying exception that makes no sense to keep. Normally, users or client applications will either use --hwdec=auto, or not set the option at all, which both leads to the expected result.
* manpage: clarify --sub-file(s) optionswm42017-12-071-2/+6
| | | | | | This was a bit confused, and I bet nobody understood whether to use --sub-file or --sub-files, and what the difference is. Explicitly mention that both variants exist, and how they are related.
* options: add --start=none to reset previously set start timeAman Gupta2017-12-061-0/+2
| | | | | | | | | | | | | Previously when using a libmpv instance to play multiple videos, once --start was set there was no clear way to unset it. You could use --start=0, but 0 does not always mean the beginning of the file (especially when using --rebase-start-time=no). Looking up the start timestamp and passing that in also does not always work, particularly when the first timestamp is negative (since negative values to --start have a special meaning). This commit adds a new "none" value which maps to the internal REL_TIME_NONE, matching the default value of the play_start option.
* manpage: minor fixes to documenationLeo Izen2017-12-061-3/+11
|
* Remove support for ffmpeg-mpvRostislav Pehlivanov2017-12-051-1/+1
|
* manpage: add some minor documenation fixesLeo Izen2017-12-041-0/+7
| | | | | | - replace the incorrect reference to --opengl-shader - document a caveat when using --image-display-duration - add some documentation on --vf=lavfi=
* player/misc.c: allow both --length and --end to control play endpointLeo Izen2017-12-041-0/+3
| | | | | | | | | | Most options that change the playback endpoint coexist and playback stops when it reaches any of them. (e.g. --ab-loop-b, --end, or --chapter). This patch extends that behavior to --length so it isn't automatically trumped by --end if both are present. These two will interact now as the other options do. This change is also documented in DOCS/man/options.rst.
* manpage: vaapi-copy is not limited to Intel GPUsMariusz Skoneczko2017-12-031-1/+1
| | | vaapi-copy works with some AMD cards
* man: remove incorrect note about default opengl backendMartin Herkt2017-12-021-2/+1
|
* vd_lavc: drop mediacodec direct rendering support temporarilywm42017-12-011-0/+1
| | | | | | | | | | | | The libavcodec mediacodec support does not conform to the new hwaccel APIs yet. It has been agreed uppon that this glue code can be deleted for now, and support for it will be restored at a later point. Readding would require that it supports the AVCodecContext.hw_device_ctx API. The hw_device_ctx would then contain the surface ID. vo_mediacodec_embed would actually perform the task of creating vo.hwdec_devs and adding a mp_hwdec_ctx, whose av_device_ref is a AVHWDeviceContext containing the android surface.
* vo_gpu: make it possible to load multiple hwdec interop driverswm42017-12-011-28/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
* af: remove deprecated audio filterswm42017-11-291-8/+0
| | | | | | | | | | | | These couldn't be relicensed, and won't survive the LGPL transition. The other existing filters are mostly LGPL (except libaf glue code). This remove the deprecated pan option. I guess it could be restored by inserting a libavfilter filter (if there's one), but for now let it be gone. This temporarily breaks volume control (and things related to it, like replaygain).
* video: remove automatic stereo3d filter insertionwm42017-11-291-2/+2
| | | | | | | | | | | | | The internal stereo3d filter was removed due to being GPL only, and due to being a mess that somehow used libavfilter's filter. Without this filter, it's hard to remove our internal stereo3d image attribute, so even using libavfilter's stereo3d filter would not work too well (unless someone fixes it and makes it able to use AVFrame metadata, which we then could mirror in mp_image). This was never well thought-through anyway, so just drop it. I think some "downsampling" support would still make sense, maybe that can be readded later.
* manpage: clarify bitstreaming optionsOswald Pan2017-11-191-5/+9
| | | | | | Changes: List other (commonly used) bitstreamed formats. Clarify that WASAPI can only output multichannel PCM in exclusive mode.
* demux: use seekable cache for network by default, bump prefetch limitwm42017-11-101-3/+7
| | | | | | | | The option for enabling it has now an "auto" choice, which is the default, and which will enable it if the media is thought to be via network or if the stream cache is enabled (same logic as --cache-secs). Also bump the --cache-secs default from 10 to 120.
* demux: set default back buffer to some high valuewm42017-11-101-1/+3
| | | | | | | Some back buffer is required to make the immediate forward range seekable. This is because the back buffer limit is strictly enforced. Just set a rather high back buffer by default. It's not use if --demuxer-seekable-cache is disabled, so this is without risk.
* demux: support multiple seekable cached rangeswm42017-11-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, the demuxer cache was limited to a single range. Extend this to multiple range. Should be useful for slow network streams. This commit changes a lot in the internal demuxer cache logic, so there's a lot of room for bugs and regressions. The logic without demuxer cache is mostly untouched, but also involved with the code changes. Or in other words, this commit probably fucks up shit. There are two things which makes multiple cached ranges rather hard: 1. the need to resume the demuxer at the end of a cached range when seeking to it 2. joining two adjacent ranges when the lowe range "grows" into it (and resuming the demuxer at the end of the new joined range) "Resuming" the demuxer means that we perform a low level seek to the end of a cached range, and properly append new packets to it, without adding packets multiple times or creating holes due to missing packets. Since audio and video never line up exactly, there is no clean "cut" possible, at which you could resume the demuxer cleanly (for 1.) or which you could use to detect that two ranges are perfectly adjacent (for 2.). The way how the demuxer interleaves multiple streams is also unpredictable. Typically you will have to expect that it randomly allows one of the streams to be ahead by a bit, and so on. To deal with this, we have heuristics in place to detect when one packet equals or is "behind" a packet that was demuxed earlier. We reuse the refresh seek logic (used to "reread" packets into the demuxer cache when enabling a track), which checks for certain packet invariants. Currently, it observes whether either the raw packet position, or the packet DTS is strictly monotonically increasing. If none of them are true, we discard old ranges when creating a new one. This heavily depends on the file format and the demuxer behavior. For example, not all file formats have DTS, and the packet position can be unset due to libavformat not always setting it (e.g. when parsers are used). At the same time, we must deal with all the complicated state used to track prefetching and seek ranges. In some complicated corner cases, we just give up and discard other seek ranges, even if the previously mentioned packet invariants are fulfilled. To handle joining, we're being particularly dumb, and require a small overlap to be confident that two ranges join perfectly. (This could be done incrementally with as little overlap as 1 packet, but corner cases would eat us: each stream needs to be joined separately, and the cache pruning logic could remove overlapping packets for other streams again.) Another restriction is that switching the cached range will always trigger an asynchronous low level seek to resume demuxing at the new range. Some users might find this annoying. Dealing with interleaved subtitles is not fully handled yet. It will clamp the seekable range to where subtitle packets are.
* vo_gpu: hwdec_d3d11va: allow zero-copy video decodingJames Ross-Gowan2017-11-071-0/+12
| | | | | | | | | | | | | | Like the manual says, this is technically undefined behaviour. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476085.aspx In particular, MSDN says texture arrays created with the BIND_DECODER flag cannot be used with CreateShaderResourceView, which means they can't be sampled through SRVs like normal Direct3D textures. However, some programs (Google Chrome included) do this anyway for performance and power-usage reasons, and it appears to work with most drivers. Older AMD drivers had a "bug" with zero-copy decoding, but this appears to have been fixed. See #3255, #3464 and http://crbug.com/623029.
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-071-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
* demux: add option to create CC tracks eagerlywm42017-11-031-0/+12
| | | | | | | | | | | | We don't hope to auto-detect them at load time, as that would be too much of a pain - even FFmpeg requires fetching and parsing of video packets, and exposes the information only via deprecated API. But there still needs to be a way to select them by default. This is also needed to get the first CC packet at all (without seeking back). This commit also attempts to clean up locking a bit, which is a PITA, but it's better be careful & clean.
* manpage: fix/improve --msg-level descriptionwm42017-10-30