summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* input: add text produced by key to script key eventswm42019-11-222-1/+14
| | | | | | | Particularly for "any_unicode" mappings, so they don't have to special-case keys like '#' and ' ', which are normally mapped to symbolic names for input.conf reasons. (Though admittedly, this is a pretty minor thing, since API users could map these manually.)
* manpage: correct "complex" key binding descriptionwm42019-11-221-2/+2
| | | | | | | The key is never nil if it's invoked through the normal input path. The key name could be "" if mp_cmd.key_name==NULL. This should not happen, but there's no strong guarantee in input.c that it cannot happen, so whatever.
* manpage: improve "complex" key binding list of table entrieswm42019-11-221-6/+13
|
* input: introduce a pseudo key name that grabs all text inputwm42019-11-221-0/+5
| | | | | | | | | The intended target for this is the mpv.repl script, which manually added every single ASCII key as a separate key binding. This provides a simpler mechanism, that will catch any kind of text input. Due to its special nature, explicitly do not give a guarantee for compatibility; thus the warning in input.rst.
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-202-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I often watch sporting events. On many occasions I get files with the same filename for each session. For example, for F1 I might have the following directory structure: F1/ FP1.mkv FP2.mkv FP3.mkv Qualification.mkv Race.mkv Since usually one simply watches one race after the other, I usually just rsync the new event's files over the old ones, so, for example, Race.mkv will be replaced from the file for the last event with the file from the new event. One problem with this is that I like to use --resume-playback for other kinds of media, so I have it on by default. That works great for, say, a movie, but doesn't work so well with this scheme, because you can trivially forget to pass --no-resume-playback on the command line and end up 2 hours in, watching spoilers as the race results scroll down the screen :-) This patch adds a new option, --resume-playback-check-mtime, which validates that the file's mtime hasn't changed since the watch_later configuration was saved. It does this by setting the watch_later configuration to have the same mtime as the file after it is saved. Switching back and forth between checking mtime and not checking mtime works fine, as we only choose whether to compare based on it, but we update the watch_later configuration mtime regardless of its value.
* manpage: extend documentation of key nameswm42019-11-191-0/+74
| | | | These things weren't written down anywhere yet.
* lua: report key name for "complex" key bindingswm42019-11-191-3/+4
| | | | This might make certain use cases less of a mess.
* manpage: deprecate input section commandswm42019-11-192-0/+8
| | | | | | | | | | These were a bad idea and are obscure. Scripting key mapping support still uses them, but this is not relevant to scripting authors, because the mpv provided helper code (defaults.lua) takes care of this. In addition, the OSC uses a legacy form of this. Hopefully, this input section stuff can be removed, and replaced by a simpler mechanism.
* DOCS/contribute.md: some clarificationswm42019-11-181-3/+7
| | | | Even if nobody ever reads this file.
* options: deprecate --video-sync=display-adropwm42019-11-171-0/+2
| | | | A stupid thing that will probably be in the way.
* manpage: add section about using mpv from programs and scriptswm42019-11-161-0/+45
| | | | | | | | | | | | | | | Give an overview over the various methods. I feel like I've written text like this over and over again (compatibility.rst and interface-changes.rst for example duplicate the list of mpv API abstractions), but such is life in hell. Use this in particular to strongly suggest not to parse terminal output. This suggestion got lost or de-emphasized at some point (maybe when removing MPlayer and "slave mode" references). Some of this text is still there, but it can be considered "fine print" at best, that nobody will see. Now we have it in a more prominent place. This is especially important since MPlayer-style use of mpv still seems to be prevalent, see for example #7153.
* options: deprecate --input-filewm42019-11-162-0/+4
| | | | | | I have no idea why this still exists, since we have --input-ipc-server. I think there was something about Windows, but the latter option is implemented even on Windows.
* demux_lavf: fight ffmpeg API some more and get the timeout setwm42019-11-161-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | It sometimes happens that HLS streams freeze because the HTTP server is not responding for a fragment (or something similar, the exact circumstances are unknown). The --timeout option didn't affect this, because it's never set on HLS recursive connections (these download the fragments, while the main connection likely nothing and just wastes a TCP socket). Apply an elaborate hack on top of an existing elaborate hack to somehow get these options set. Of course this could still break easily, but hey, it's ffmpeg, it can't not try to fuck you over. I'm so fucking sick of ffmpeg's API bullshit, especially wrt. HLS. Of course the change is sort of pointless. For HLS, GET requests should just aggressively retried (because they're not "streamed", they're just actual files on a CDN), while normal HTTP connections should probably not be made this fragile (they could be streamed, i.e. they are backed by some sort of real time encoder, and block if there is no data yet). The 1 minute default timeout is too high to save playback if this happens with HLS. Vaguely related to #5793.
* stream_lavf: set --network-timeout to 60 seconds by defaultwm42019-11-141-5/+8
| | | | | | | | | | | Until now, we've made FFmpeg use the default network timeout - which is apparently infinite. I don't know if this was changed at some point, although it seems likely, as I was sure there was a more useful default. For most use cases, a smaller timeout is more useful (for example recording something in the background), so force a timeout of 1 minute. See: #5793
* wayland: use hidpi-window-scale optiondudemanguy2019-11-121-1/+1
|
* manpage: expand MPV_LEAK_REPORT environment variable descriptionwm42019-11-091-1/+5
|
* wscript: add --enable-ta-leak-report optionwm42019-11-081-0/+1
| | | | Kind of more convenient because I'm lazy.
* test: make tests part of the mpv binarywm42019-11-081-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
* vo_gpu: vdpau actually works under EGLwm42019-11-071-2/+1
| | | | | | | | | | | | | | | | | | The use of glXGetCurrentDisplay() restricted this to the GLX backend. But actually it works under EGL as well. Removing the GLX-specific call and using the general mpv-internal method to get the X "Display" makes it work in mpv. I didn't know this. Nvidia didn't list this as extension in the EGL context when I still used their GPUs. Note that this might in theory break use of vdpau in some libmpv clients using the render API. But only if MPV_RENDER_PARAM_X11_DISPLAY is not used, and they relied on mpv using glXGetCurrentDisplay(). EGL does not provide such an API, and hwdec_vaapi.c also uses what hwdec_vdpau.c uses now. Considering that vaapi is preferable these days, it's not bad at all if these clients get "broken". They can be easily fixed by passing the display to mpv correctly.
* manpage: vdpauglx backend was removedwm42019-11-071-5/+0
| | | | A while ago. It was 100% useless.
* DOCS/contribute.md: add #include order to coding stylewm42019-11-071-0/+11
| | | | Another thing nobody will read, or consciously follow.
* DOCS/contribute.md, zimg: remove 2 instances of an extraneous "s"wm42019-11-071-1/+1
|
* stream: bump default buffer size from 2K to 64Kwm42019-11-061-1/+1
| | | | | | | | | (Only half of the buffer is actually used in a useful way, see manpage or commit which added the option.) Might have some advantages with broken network filesystem drivers. See: #6802
* stream: turn into a ring buffer, make size configurablewm42019-11-061-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* manpage: update input protocolswm42019-11-041-55/+20
| | | | | | | | | tv:// and pvr:// are gone, DVD almost. The former didn't really have any uses left, except webcams. Provide a replacement example for that. We don't need a separate section for DVD. If you use DVD, you're on your own. There's still enough documentation left to puzzle things together even if you don't read the source code.
* manpage: opengl-cb -> libmpvwm42019-11-041-5/+5
| | | | | This was renamed ages ago. Fix the outdated usage. Except where opengl-cb was correct.
* manpage: fix global config file path in --hwdec descriptionwm42019-11-041-1/+1
|
* manpage: shovel around --hwdec description (again)wm42019-11-041-25/+39
| | | | | | | Not like anyone reads it. Although putting all this text before listing the allowed option values sort of has the intention to discourage users from using the option at all. Advertise Ctrl+h, which is a decent way of enabling hardware decoding temporarily.
* DOCS/interface-changes.rst: improve entry about sws changeswm42019-11-031-2/+7
| | | | | This was pretty vague. Add some context, and explicitly mention how these options now affect screenshots.
* vd_lavc: don't keep packets for fallbacks if errors are toleratedwm42019-11-021-0/+5
| | | | | | | | | | | | | | The user can raise the number of tolerated hardware decoding errors. On the other hand, we have a static limit on packets that are "saved" for fallback handling (and that's a good idea to avoid unbounded memory usage). In this case, it could happen that the start of a file was fine after a fallback, but after that buffered amount of data, it would suddenly skip. It's more useful to skip buffering entirely if the number of tolerated decoding errors exceeds the fixed buffer. (And also, I'm sure nobody gives a shit about this feature.)
* manpage: update --framedrop optionwm42019-11-021-10/+26
| | | | | | | | | | | | | The statement about the display FPS is outdated by several years. "audio"-sync mode does not use the display FPS anymore, and that it's X11 only also isn't true anymore. These modes have separate implementations for audio and display video sync. modes, so the explanations are separate. Why the hell are users playing around with this anyway? The explanations are probably too special to make sense for anyone who doesn't know the code (and who knows the code doesn't need them anyway), but whatever.
* zimg: make --zimg-fast=yes defaultwm42019-11-021-1/+1
| | | | | | This is mostly just because of the odd RGB default gamma issue, which shouldn't have any real impact. This also sets allow_approximate_gamma, which I hope is fine for normal use cases.
* options: make --show-profile without parameters list all profileswm42019-10-311-1/+2
|
* manpage: fix another typowm42019-10-311-1/+1
|
* manpage: update --zimg-scaler defaultwm42019-10-311-3/+3
| | | | Forgotten in previous commit.
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-313-3/+52
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* manpage: document stats page 3wm42019-10-311-0/+3
|
* interface-changes: fixup the location of d3d11-output-cspJan Ekström2019-10-301-1/+2
| | | | 0.30.0 is already cut, so +1 it is.
* vo_gpu/d3d11: add support for configuring swap chain color spaceJan Ekström2019-10-302-0/+15
| | | | | | | | | | | | | | | | By default utilizes the color space of the desktop on which the swap chain is located. If a specific value is defined, it will be instead be utilized. Enables configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.
* osc: Unify bottom and topbar codeJan Janssen2019-10-281-2/+2
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* manpage: Update information about default mouse bindingsCameron Cawley2019-10-281-3/+12
|
* DOCS/release-policy.md: clarify a few detailssfan52019-10-271-3/+7
|
* input: disable gamepad code by defaultwm42019-10-251-1/+1
| | | | | | | Enabling this by default probably causes a number of issues, such as breaking vo_sdl, or reacting to various input devices while the window is not focused. It's also pretty obscure, or at least new. Disable it by default.
* manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --scripts accepts a list, but uses the mplayer-inherited platform-dependent path separator. Fixes: #5996
* vo_gpu, options: don't return NaN through APIwm42019-10-252-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* manpage: fix RST formatting errorin vf_format descriptionwm42019-10-241-1/+1
|
* manpage: slap "do not use" label on vf_vapoursynthwm42019-10-241-4/+10
| | | | Plus some other minor corrections.
* vf: improve vf_vapoursynth descriptionwm42019-10-231-18/+71
| | | | | | | In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-231-0/+3
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* DOCS/client-api-changes.rst: fix formattingsfan52019-10-221-0/+1
|
* manpage: finish an unfinished sentencewm42019-10-211-5/+7
|
* filters: extend vf_format so that it can convert color parameterswm42019-10-211-4/+44
| | | | | | | | | | | | | | | | | | | | | | | | | Form some reason (and because of my fault), vf_format converts image formats, but nothing else. For example, setting the "colormatrix" sub-parameter would not convert it to the new value, but instead overwrite the metadata (basically "reinterpreting" the image data without changing it). Make the historical mistake worse, and go all the way and extend it such that it can perform a conversion. For compatibility reasons, this needs to be requested explicitly. (Maybe this would deserve a separate filter to begin with, but things are messed up anyway. Feel free to suggest an elegant and simple solution.) This demonstrates how zimg can properly perform some conversions which swscale cannot (see examples added to vf.rst). Stupidly this requires 2 code paths, one for conversion, and one for overriding the parameters. Due to the filter bullshit (what was I thinking), this requires quite some acrobatics that would not be necessary without these abstractions. On the other hand, it'd definitely be more of a mess without it. Oh whatever.
* manpage: describe stride parameter in screenshot-raw commandwm42019-10-201-0/+6
| | | | | This is mentioned and called "obvious", but it's conceivable users don't necessarily know about the concept. Just explain it.
* wayland: add various render-related optionsdudemanguy2019-10-201-0/+15
| | | | | The newest wayland changes have some new logic that make sense to expose to users as configurable options.
* sws_utils: hack in zimg redirection supportwm42019-10-201-0/+15
| | | | | | | | | | | | | | | | Awful shit. I probably wouldn't accept this code from someone else, just so you know. The idea is that a sws_utils user can automatically use zimg without large code changes. Basically, laziness. Since zimg support is still very new, and I don't want that anything breaks just because zimg was enabled at build time, an option needs to be set to enable it. (I have especially especially obscure stuff in mind, which is all what libswscale is used in mpv.) This _still_ doesn't cause zimg to be used anywhere, because the sws_utils user has to opt-in by setting allow_zimg. This is because some users depend on certain libswscale features.
* video: add zimg wrapperwm42019-10-201-0/+8
| | | | | | | | | | | | | | | |