summaryrefslogtreecommitdiffstats
path: root/DOCS/man
Commit message (Collapse)AuthorAgeFilesLines
* encode: remove old timestamp handlingwm42018-05-031-33/+0
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* manpage: -pre, -del etc. does not work on some options anymorewm42018-05-031-25/+4
| | | | | | With the internal change from stringlist to keyvaluelist, these sub-options stop working. I don't really care enough to bring them back. (Order doesn't matter, -del always seemed annoying.)
* docs/vo: fixup some minor typos a la "planed" instead of "plane"Jan Ekström2018-05-011-3/+3
|
* drm/atomic: refactor planes namesLongChair2018-05-011-0/+14
| | | | | | | | We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesLongChair2018-05-011-5/+7
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* manpage: remove 4 previously removed optionswm42018-05-011-24/+0
| | | | The manpage parts were forgotten when removing the options.
* manpage: --demuxer-seekable-cache is not experimental anymorewm42018-05-011-2/+1
| | | | | This seems to work surprisingly well, and it's enabled by default (unlike the old text claims).
* command: change cycle-value command behaviorwm42018-04-292-14/+7
| | | | | | | | | | | | | | | | | | | | Instead of using an internal counter to keep track of the value that was set last, attempt to find the current value of the property/option in the value list, and then set the next value in the list. There are some potential problems. If a property refuses to accept a specific value, the cycle-values command will fail, and start from the same position again. It can't know that it's supposed to skip the next value. The same can happen to properties which behave "strangely", such as the "aspect" property, which will return the current aspect if you write "-1" to it. As a consequence, cycle-values can appear to get "stuck". I still think the new behavior is what users expect more, and which is generally more useful. We won't restore the ability to get the old behavior, unless we decide to revert this commit entirely. Fixes #5772, and hopefully other complaints.
* vd_lavc: enable dr by defaultwm42018-04-291-7/+4
| | | | | I had this enabled for quite a while and experienced no issues. I'm not aware of other issues either.
* encode: rewrite half of itwm42018-04-291-9/+6
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* encoding: deprecate a bunch of obscure optionswm42018-04-201-4/+4
| | | | | --audio-delay does not work correctly yet, but hopefully this can be fixed later.
* scripting: change when/how player waits for scripts being loadedwm42018-04-182-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fundamentally, scripts are loaded asynchronously, but as a feature, there was code to wait until a script is loaded (for a certain arbitrary definition of "loaded"). This was done in scripting.c with the wait_loaded() function. This called mp_idle(), and since there are commands to load/unload scripts, it meant the player core loop could be entered recursively. I think this is a major complication and has some problems. For example, if you had a script that does 'os.execute("sleep inf")', then every time you ran a command to load an instance of the script would add a new stack frame of mp_idle(). This would lead to some sort of reentrancy horror that is hard to debug. Also misc/dispatch.c contains a somewhat tricky mess to support such recursive invocations. There were also some bugs due to this and due to unforeseen interactions with other messes. This scripting stuff was the only thing making use of that reentrancy, and future commands that have "logical" waiting for something should be implemented differently. So get rid of it. Change the code to wait only in the player initialization phase: the only place where it really has to wait is before playback is started, because scripts might want to set options or hooks that interact with playback initialization. Unloading of builtin scripts (can happen with e.g. "set osc no") is left asynchronous; the unloading wasn't too robust anyway, and this change won't make a difference if someone is trying to break it intentionally. Note that this is not in mp_initialize(), because mpv_initialize() uses this by locking the core, which would have the same problem. In the future, commands which logically wait should use different mechanisms. Originally I thought the current approach (that is removed with this commit) should be used, but it's too much of a mess and can't even be used in some cases. Examples are: - "loadfile" should be made blocking (needs to run the normal player code and manually unblock the thread issuing the command) - "add-sub" should not freeze the player until the URL is opened (needs to run opening on a separate thread) Possibly the current scripting behavior could be restored once new mechanisms exist, and if it turns out that anyone needs it. With this commit there should be no further instances of recursive playloop invocations (other than the case in the following commit), since all mp_idle()/mp_wait_events() calls are done strictly from the main thread (and not commands/properties or libmpv client API that "lock" the main thread).
* f_lavfi: add an option to use old audio PTS handling for af_lavfiwm42018-04-151-0/+13
| | | | | The fix-pts option basically uses the old af_lavfi's (before filter rewrite) timestamp logic. The rest is explained in the manpage.
* audio: don't recreate AO if a filter changes the output formatwm42018-04-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Until recently, the AO was reinitialized strictly only on decoder format changes. But the commit for simplifying audio format negotiation removed this. Now the AO is recreated for any format change. This is sort of annoying if you change playback speed. The insertion/removal of af_scaletempo can change the sample format. For example, the acompressor filter will convert output to double, so toggling scaletempo will force the format back to float. This recreates the AO under the --gapless-audio=weak default. This likely affects a lot of other filters too. Work this around by allowing sample format changes, and keeping the current AO format in these cases. This is probably not a big problem. Most audio APIs force the output format to float anyway. This means you actually have to worry about what the default gapless mode does to your audio. If you start with a file that uses 8 bit per sample, and then continue playing a 24 bit FLAC, it will be converted down to 8 bit per sample. (Assuming they are played in a way that uses the gapless logic.)
* ao_pulse: reduce requested device buffer sizewm42018-04-151-1/+1
| | | | | | Same deal as with the previous commit for ALSA. Untested.
* ao_alsa: add options for controlling period/buffer sizewm42018-04-151-0/+14
|
* ao/openal: Remove notes on experimentality from the documentationLAGonauta2018-04-151-4/+1
| | | | | Also, multi-channel audio should be fast now with the use of the MC extensions.
* ao/openal: Add option to set buffering characteristicsLAGonauta2018-04-151-0/+8
| | | | | | | | | One can now set the number of buffers and the buffer size. This can reduce the CPU usage and the total latency stays mostly the same. As there are sync mechanisms the A/V sync continue intact and working. It also modifies 6.1 channel order, as per OpenAL spec and add AOPLAY_FINAL_CHUNK support
* ao/openal: Add support for direct channels outputLAGonauta2018-04-151-0/+6
| | | | | | | Uses OpenAL Soft's AL_DIRECT_CHANNELS_SOFT extension and can be controlled through a new CLI option, --openal-direct-channels. This allows one to send the audio data direrctly to the desired channel without effects applied.
* manpage: document vaapi-deviceKevin Mitchell2018-04-081-0/+4
| | | | This was left out of e3e2c79 by mistake.
* manpage: move cuda-decode-device with hwdec optionsKevin Mitchell2018-04-081-10/+10
|
* js: implement mp.register_idleAvi Halachmi (:avih)2018-04-071-5/+16
| | | | | | | | | | Due to earlier misinterpretation of the Lua docs as if mp.register_idle registers a one-shot callback, the JS docs suggested to use setTimeout. But the behavior and Lua docs are such that it's a repeating callback which fires just before the script thread goes to sleep. Implement it for JS too.
* js: implement mp.options.read_optionsAvi Halachmi (:avih)2018-04-071-8/+8
|
* config: replace config dir lua-settings/ with dir script-opts/Avi Halachmi (:avih)2018-04-074-4/+4
| | | | lua-settings/ is still supported, with deprecation warning.
* client API: add a first class hook API, and deprecate old APIwm42018-03-261-34/+43
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* client API: deprecate mpv_get_wakeup_pipe()wm42018-03-261-1/+1
| | | | I don't think anything even uses it.
* manpage: mention how to get multiple video tracks for --lavfi-complexwm42018-03-261-0/+2
| | | | See #5670.
* manpage: document that ---ao overrides --audio-devicewm42018-03-151-1/+3
| | | | Fixes #5640.
* video: add an option to tune waiting for video timingwm42018-03-151-0/+20
| | | | Probably mostly useful for the libmpv render API.
* DOCS/options: clarify that --end also supports relative timeRicardo Constantino2018-03-151-2/+2
|
* doc: fix formatting of video-frame-info propertiesAman Gupta2018-03-111-5/+5
|
* input: minor additions to default key bindingswm42018-03-041-6/+41
| | | | | | | | | This adds key bindings for some semi-popular features. It also tries to cleanup some old bindings. For example w/e for panscan is now changed to w/W. In all cases, the old bindings are still kept and work, though. Part of an ongoing attempt to cleanup the default key bindings. See #973 for some context.
* video: add option to reduce latency by 1 or 2 frameswm42018-03-031-0/+20
| | | | | | | | | | | | | | | | | | | | The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
* manpage: describe how to list/inspect/apply profileswm42018-03-031-0/+5
| | | | | This is all documented elsewhere in the manpage, but hard to find from here.
* options: add a builtin low-latency profilewm42018-03-031-0/+39
| | | | | | | | | | Well I guess it doesn't help that much. Also add some stuff that might help to the manpage. The fundamental problem with some "live" sources (e.g. x11grab) is actually that the player gets behind initially, and never thinks it has to catch up. This is also why --untimed can help.
* demux_lavf: add --demuxer-lavf-probe-info=nostreamswm42018-03-031-1/+5
| | | | Another attempt to try to make it behave in certain situations.
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-282-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* cocoa-cb: make fullscreen resize animation duration configurableAkemi2018-02-281-0/+12
|
* cocoa-cb: change border and borderless window stylingAkemi2018-02-281-0/+12
| | | | | | | | | | | the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-261-1/+14
| | | | | | | | | | | | | This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
* stream_file: add mode for reading appended fileswm42018-02-211-0/+13
| | | | | | | | | | | | | Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time.
* vo_gpu: introduce --target-peakNiklas Haas2018-02-201-0/+33
| | | | | | | | | | | | | This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
* lua+js: Implement utils.getpid()sfan52018-02-132-0/+6
| | | | | | | Usable for uniquely identifying mpv instances from subprocesses, controlling mpv with AppleScript, ... Adds a new mp_getpid() wrapper for cross-platform reasons.
* vf_vavpp: select best quality deinterlacing algorithm by defaultwm42018-02-131-1/+5
| | | | | | | | This switches the default away from "bob" to the best algorithm reported as supported by the driver. This is convenient for users, and there is no reason to use something worse by default. Untested.
* manpage: remove mention of --vf=eqwm42018-02-131-1/+1
| | | | This doesn't work anymore.
* input: add a keybinding to toggle hardware decodingwm42018-02-131-0/+3
| | | | | We sure as hell won't enable hardware decoding by default, but we can make it more accessible with a key binding.
* video: make --deinterlace and HW deinterlace filters always deinterlacewm42018-02-132-4/+6
| | | | | | | | | | | | | | | | Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-122-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* osx: always deactivate the early opengl flush on macOSAkemi2018-02-121-0/+3
| | | | | | | | | | | early flushing only caused problems on macOS, which includes: - performance problems and huge amount of dropped frames - problems with playing back video files with fps close to the display refresh rate - rendering at twice the rate of the video fps - not properly detected display refresh rate we always deactivate any early flush for macOS to fix these problems.
* ytdl_hook: add script opt for using manifest URLsRicardo Constantino2018-02-111-0/+4
| | | | | | | | | | | Disable by default. This feature was added in 7eb342757, which allowed stream selection in runtime. Problem with this atm is that FFmpeg will try to demux every first packet of every track leading to noticeable delay opening the URL. This option can be changed to enabled by default or removed when HLS/DASH demuxers are improved upstream.
* vo_gpu: make screenshots use the GL rendererwm42018-02-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
* vo_gpu: port HDR tone mapping algorithm from libplaceboNiklas Haas2018-02-051-11/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The curre