summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* zimg: add slice threading and use it by defaultwm42020-07-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | This probably makes it much faster (I wouldn't know, I didn't run any benchmarks ). Seems to work as well (although I'm not sure, it's not like I'd perform rigorous tests). The scale_zimg test seems to mysteriously treat color in fully transparent alpha differently, which makes no sense, and isn't visible (but makes the test fail). I can't be bothered with investigating this more. What do you do with failing tests? Correct, you disable them. Or rather, you disable whatever appears to cause them to fail, which is the threading in this case. This change follows mostly the tile_example.cpp. The slice size uses a minimum of 64, which was suggested by the zimg author. Some of this commit is a bit inelegant and weird, such as recomputing the scale factor for every slice, or the way slice_h is managed. Too lazy to make this more elegant. zimg git had a regressio around active_region (which is needed by the slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the bug was never released, so just add a warning to the manpage.
* x11: add option to make window appear on a specific workspacewm42020-07-121-4/+7
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* x11: remove terrible xdg-screensaver hackwm42020-07-082-1/+46
| | | | | | | | | | | | | | I'm tired of dealing with this frequent spawning of xdg-screensaver when debugging and what not. xdg-screensaver was never a serious tool anyway, it's more like some self-deprecating joke by FDO folks. This will affect X11 on GNOME and other DEs. I'm singling out GNOME though, because they are the ones actively sabotaging any sane technical solutions and community cooperation. I have been accused of taking it out on innocent GNOME users, while none of this will reach GNOME developers. Of course that is not the intention.
* client API: add software rendering APIwm42020-07-081-0/+1
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* vo_gpu: vulkan: add ability to disable eventsNiklas Haas2020-06-301-0/+5
| | | | | | | | | | | libplacebo exposes this feature already, because this particular type of bug is unusually common in practice. Simply make use of it, by exposing it as an option. Could probably also bump the libplacebo minimum version to get rid of the #if, but that would break debian oldoldstable or something. Fixes #7867.
* path: do not use old_home for win32 exe dirwm42020-06-251-0/+2
| | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works.
* path: switch back to using non-XDG config dir by defaultwm42020-06-251-23/+41
| | | | | | | | | | | | | | | | | | | | | XDG is stupid, so change back to the standard behavior. Unfortunately, most users will now have the XDG one, so we will still need to load this. (This is exactly the same problem as when XDG support was introduced, just the other way around). This should not affect any normal users. Hopefully I tested this well enough; my intention is not to torment miserable XDG fans; they can keep using their config dir if they want it. This changes behavior in two cases: - new users (now creates ~/.mpv/ instead of ~/.config/mpv/) - users which have both directories The latter case will behave subtly or obviously different, not sure. Just fix your shit. Extend the manpage with all the messy details, as far as I could reverse engineer them from the code.
* manpage: --demuxer-seekable-cache is uselesswm42020-06-231-19/+18
| | | | | | | | | De-emphasize it, since a user should usually not use it. This _could_ be used to make the cache seekable with --cache=no, but it's better and more intuitive to use --cache=yes. As such, the only use of this is for debugging. I'm not quite sure if this should be removed entirely, but I still see some value in it (for example if you want the cache lookahead, but you're using a stream where cache seeking is somehow broken).
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-191-0/+7
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: add BT.2390 tone-mappingNiklas Haas2020-06-151-0/+3
| | | | | | | | | | | | Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-151-3/+3
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* options: add --video-scale-x/ywm42020-06-031-0/+9
| | | | | | Requested. Fixes: #6303
* audio: redo internal AO APIwm42020-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm, ao_lavc. There are changes to the other AOs too, but that's only about renaming ao_driver.resume to ao_driver.start. ao_openal is broken because I didn't manage to fix it, so it exits with an error message. If you want it, why don't _you_ put effort into it? I see no reason to waste my own precious lifetime over this (I realize the irony). ao_alsa loses the poll() mechanism, but it was mostly broken and didn't really do what it was supposed to. There doesn't seem to be anything in the ALSA API to watch the playback status without polling (unless you want to use raw UNIX signals). No idea if ao_pulse is correct, or whether it's subtly broken now. There is no documentation, so I can't tell what is correct, without reverse engineering the whole project. I recommend using ALSA. This was supposed to be just a simple fix, but somehow it expanded scope like a train wreck. Very high chance of regressions, but probably only for the AOs listed above. The rest you can figure out from reading the diff.
* player: add --term-title optionwm42020-05-251-0/+9
| | | | | | | | | | | | | | This simply printf()s a concatenation of the provided string and the relevant escape sequences. No idea what exactly defines this escape sequence (is it just a xterm thing that is now supported relatively widely?), and this simply uses information provided on the linked github issue. Not much of an advantage over --term-status-msg, though at least this can have a lower update frequency. Also I may consider setting a default value, and then it shouldn't conflict with the status message. Fixes: #1725
* manpage: document "vf remove"wm42020-05-231-1/+4
| | | | And mention it on "vf del" as non-deprecated alternative.
* player: remove some display-adrop leftoverswm42020-05-232-7/+3
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* audio: redo video-sync=display-adropwm42020-05-232-1/+9
| | | | | | | | | | | | | | | | | This mode drops or repeats audio data to adapt to video speed, instead of resampling it or such. It was added to deal with SPDIF. The implementation was part of fill_audio_out_buffers() - the entire function is something whose complexity exploded in my face, and which I want to clean up, and this is hopefully a first step. Put it in a filter, and mess with the shitty glue code. It's all sort of roundabout and illogical, but that can be rectified later. The important part is that it works much like the resample or scaletempo filters. For PCM audio, this does not work on samples anymore. This makes it much worse. But for PCM you can use saner mechanisms that sound better. Also, something about PTS tracking is wrong. But not wasting more time on this.
* options: add option to control display-sync factorwm42020-05-231-0/+11
| | | | | | | | Can be useful to force it to adapt to extreme speed changes, while a higher limit would just use a fraction closer to the original video speed. Probably useful for testing only.
* video: clean up some imgfmt related stuffwm42020-05-182-5/+1
| | | | | | | | | | | | | | | | Remove the vaguely defined plane_bits and component_bits fields from struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove the bytes[] field, replace uses with bpp[]. Fix some potential alignment issues in existing code. As a compromise, split mp_image_pixel_ptr() into 2 functions, because I think it's a bad idea to implicitly round, but for some callers being slightly less strict is convenient. This shouldn't really change anything. In fact, it's a 100% useless change. I'm just cleaning up what I started almost 8 years ago (see commit 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* stats: UP/DOWN scrolling on page 2 (frame stats)Julian2020-05-171-1/+1
| | | | | | Code contributed by @avih with only minor modifications to comments by me. Fixes #7727.
* scripting: make socket FD number for subprocesses dynamicwm42020-05-151-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | Before this, we pretty much guaranteed that --mpv-ipc-fd=3 would be passed. The FD was hardcoded, so scripts started by this mechanism didn't need to actually parse the argument. Change this to using a mostly random FD number instead. I decided to do this because posix_spawnp() and the current replacement cannot "guarantee" a FD layout. posix_spawn_file_actions_adddup2() just runs dup2() calls, so it may be hard to set FD 3/4 if they are already used by something else. For example imagine trying to map: {.fd = 3, .src_fd = 4}, {.fd = 4, .src_fd = 3}, Then it'd do dup2(4, 3), dup2(3, 4) (reminder: dup2(src, dst)), and the end result is that FD 4 really maps to the original FD 4. While this was not a problem in the present code, it's too messy that I don't want to pretend it can always done this way without an unholy mess. So my assumption is that FDs 0-2 can be freely assigned because they're never closed (probably...), while for all other FDs only pass-through is reasonable.
* command: add input-key-list propertywm42020-05-141-0/+3
| | | | Fixes: #7698
* command: add property to return text subtitles in ASSwm42020-05-141-0/+13
| | | | | | | | | See manpage additions. This was requested, sort of. Although what has been requested might be something completely different. So this is speculative. This also changes sub_get_text() to return an allocated copy, because the buffer shit was too damn messy.
* ipc: make --input-ipc-client terminate player on connection closewm42020-05-141-0/+2
| | | | | | | | As discussed in the referenced issue. This is quite a behavior change, bit since this option is new, and not included in any releases yet, I think it's OK. Fixes: #7648
* vo_direct3d: rip out texture video rendering pathwm42020-05-132-25/+1
| | | | | | | | | | | | | This isn't useful anymore. We have a much better d3d11 renderer in vo_gpu. D3D11 is available in all supported Windows versions. The StretchRect path might still be useful for someone (???), and leaving it at least evades conflict about users who want to keep using this VO for inexplicable reasons. (Low power usage might be a justified reason, but still, no.) Also fuck the win32 platform, it's a heap of stinky shit. Microsoft is some sort of psycho clown software company. Granted, maybe still better than much of the rest of Silly Con Valley.
* player: make external subtitle auto-loading stricterwm42020-05-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | By default --sub-auto uses "exact". This was far from an "exact" match, because it added anything that started with the video filename (without extension), and seemed to end in something that looked like a language code. Make this stricter. "exact" still tolerate a language code, but the video's filename must come before it without any unknown extra characters. This may not load subtitles in some situations where it previously did, and where the user might think that the naming convention is such that it should be considered an exact match. The subtitle priority sorting seems a bit worthless. I suppose it may have some value in higher "fuzz" modes (like --sub-auto=fuzzy). Also remove the mysterious "prio += prio;" line. I probably shouldn't have checked, but it goes back to commit f16fa9d31 (2003), where someone wanted to "refine" the priority without changing the rest of the code or something. Mostly untested, so have fun. Fixes: #7702
* w32_common: Support HiDPI on WindowsRealDolos2020-05-081-2/+2
|
* options: don't trigger bool "compact" path for --loop-filewm42020-05-061-0/+2
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* documentation: fix some ReST syntax mistakes in lua.rstEmanuele Torre2020-05-011-1/+1
|
* DOCS/contribute.md: add some blabla about fixup commits in pull requestswm42020-05-011-0/+16
| | | | | | | I have to say this in PR reviews all the time, so maybe I should make i explicit. In too many words of course, many, many, too many words which nobody will read, I get it, now shut up. Sneak in some subtle or not so subtle comments about how I think that github is ruining code quality.
* video: add alpha type metadatawm42020-04-241-0/+8
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* manpage: fix wrong option name for --fbo-formatwm42020-04-141-1/+1
| | | | Fixes: #7609
* player: do not fall back to a default track with explicit selectionswm42020-04-131-0/+18
| | | | | | | | | | | | | | | | | | Consider e.g. --aid=2 with a file that has only 1 track. Then it would fall back to selecting track 1. Stop doing this. If no matching track is found, this will not select any track now. Note that the fingerprint stuff (track_layout_hash in the source) prevents softens the impact of this change. Without the fingerprint, playing a dual-audio file with the second track selected, and then a single-audio file, would play the second file without audio. But the fingerprint resets it due to differences in the track list. Try to exhaustively document this and tricky interactions between the other features. What a damn mess, I think it's simply cursed. Of course it's still my fault. See: #7608
* player: mess with track selection details againwm42020-04-132-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some time ago, properties and options were mostly unified. However, the track selection properties/options semantics are incompatible to this change. I'm still trying to handle the fallout. There are two things that are in the way: 1. Track properties somehow return the runtime selection, not the option value (all while properties are supposed to be aliases to options with the same name). 2. The user's track options are not supposed to be changed without interaction. If a track is auto-selected, the property should return its ID, but the option value should remain at "auto". Only if the user actually writes to the property the option should change. E.g. playing e.g. an audio-only file and then a normal video file not play the video file with --vid=no just because the audio file had no video track. In addition to each of them being in conflict with the property/option unification, attempt to fix one of them breaks the other one. Today, we're trying to fix parts of this and avoiding an unfortunate case where you can get a conflicting option/property value, and where trying to select a track does nothing if the track to select has the same ID as the option value. This breaks 2. from above in certain situations. See manpage additions. See: #7608
* vf_format: add gross mechanism for forcing scaler for testingwm42020-04-131-0/+4
| | | | | | | | | | | This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
* DOCS/interface-changes: add d3d11-exclusive-fs to list of changesJan Ekström2020-04-121-0/+2
| | | | Was forgotten in finishing up the pull request.
* vo_gpu: d3d11: add support for exclusive fullscreenJames Ross-Gowan2020-04-121-0/+6
| | | | | Lets the application fully control the rendering onto the screen instead of the compositor.
* stats: support UP/DOWN to scroll at page 4 (perf)Avi Halachmi (:avih)2020-04-111-2/+18
| | | | | | | | | | | | | | Keys and lines-to-scroll are configurabe, and the scroll keys are only bound on pages which support scrolling (currently only page 4) - also during oneshot (like the page-switching keys). Scroll offset is reset for all pages on any key - except scroll keys, so that entering or switching to a page resets the scroll, as well as when "re-entering" the same page or "re-activating" the stats oneshot view. TODO: print_page(..) is highly associated with extending the oneshot timer if required. The timer handling can probably move into print_page and removed from all the places which boilerplate its management.
* manpage: finish a sentencewm42020-04-091-1/+2
|
* ipc: add --input-ipc-client optionwm42020-04-092-2/+32
| | | | | | | | | While --input-file was removed for justified reasons, wanting to pass down socket FDs this way is legitimate, useful, and easy to implement. One odd thing is that Fixes: #7592
* stats: some more performance graphswm42020-04-092-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* command: make input speed available as part of cache statge propertywm42020-04-031-0/+7
| | | | | | That's where it comes from after all. The other property does not have much of a reason to exist anymore, but there's no real reason to remove it either.
* ao_oss: remove this audio outputwm42020-03-281-14/+1
| | | | | | | | | | Ancient Linux audio output. Apparently it survived until now, because some BSDs (but not all) had use of this. But these should work with ao_sdl or ao_openal too (that's why these AOs exist after all). ao_oss itself has the problem that it's virtually unmaintainable from my point of view due to all the subtle (or non-subtle) difference. Look at the ifdef mess and the multiple code paths (that shouldn't exist) in the removed source code.
* ao_rsound: remove this audio outputwm42020-03-281-8/+0
| | | | | | I wonder what this even is. I've never heard of anyone using it, and can't find a corresponding library that actually builds with it. Good enough to remove.
* ao_sndio: remove this audio outputwm42020-03-281-8/+0
| | | | | | It was always marked as "experimental", and had inherent problems that were never fixed. It was disabled by default, and I don't think anyone is using it.
* manpage: clarify some event/hook detailswm42020-03-281-4/+18
|
* input: remove deprecated --input-file optionwm42020-03-282-16/+1
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-272-1/+20
| | | | | | May or may not help when dealing with playlist loading in scripts. It's supposed to help with the mean fact that loading a recursive playlist will essentially edit the playlist behind the API user's back.
* scripting: remove race condition when toggling internal scriptswm42020-03-261-0/+4
| | | | | | | | | | Scripts such as the OSC can be loaded and unloaded at runtime by toggling the option that enables them. (It even works, although normally it's only used to control initial loading.) Unloading was racy because it used the client name; fix this. The load-script change is an accidental feature. And probably useless.
* client API: add a per client unique IDwm42020-03-261-0/+1
| | | | | | I mostly intend this for internal purposes. Probably pretty useless for external API users, but on the other hand trivial to expose. While it makes a lot of sense internally, I'll probably regret exposing it.
* lua: restore recent end-file event, and deprecate itwm42020-03-222-4/+7