summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* player: warn if both proper and compat. config directories existwm42020-06-251-2/+11
| | | | | No idea why there's logic to add them all to the search path, so "both" are used. In any case, this isn't something anyone should use.
* path: do not use old_home for win32 exe dirwm42020-06-253-1/+4
| | | | | | | | | | | | | 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-252-30/+48
| | | | | | | | | | | | | | | | | | | | | 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.
* vo_gpu: fix typo in struct namesfan52020-06-241-1/+1
|
* 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).
* ci: replace mingw build scriptssfan52020-06-222-28/+139
|
* vo_gpu: use highp float if available for GLESStephen Salerno2020-06-211-0/+5
| | | | | | Using mediump float on GLES causes problems with kernel resampling, PQ HDR, and possibly others. The issues are fixed by using highp, which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-194-0/+21
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: fix scaler/window validation to allow unsettingNiklas Haas2020-06-181-0/+4
| | | | | | | | | | --dscale= and --*scale-window= (i.e. an empty string) are respectively valid settings for their options (and, in fact, the defaults). This fixes the bug that it was impossible to reset e.g. tscale-window back to the default "unset" setting after setting it once. Credit goes to @CounterPillow for locating the cause of this bug.
* vo_x11: partially restore operation on bad endian systemswm42020-06-171-6/+22
| | | | | | | | | | | | | For testing in VMs I guess? This features a very broken hack that probably works. Though I didn't test the packed format case. Again, the mismatch is essentially due to big endian byte addresses decreasing as bit addresses increase, so you can't represent a bit position in a byte stream with a single address, which the mpv metadata does. OSD is broken because repack.c doesn't support big endian. You'll have to live with it.
* video: some concessions to big endian hostswm42020-06-171-8/+11
| | | | | | | | | | | | | | | | | | | | | | The recent changes to the image format metadata broke big endian, and that was intentional. Some things are inherent to little endian (like the idea to coalesce bit and byte offsets into a single bit offset), and they don't be fixed. But some obvious things can be fixed, such as marking LE vs. BE formats the right way around on BE hosts. The metadata is formally still in LE, except that if the LE/BE flag matches the host endian, the host endian can be used when accessing packed formats with bit shifts, or when computing byte aligned component byte offsets. The former may work because formats with LE/BE variants use the same bit offsets after byte swapping, the latter may work because little endian is the natural concept for addressing memory. But it will "subtly" fail to do the right thing in some cases, and code using this can't know, so have fun. Many things are broken, but this makes e.g. vo_gpu mostly work. My general opinion about BE computers is that you should get a better computer, you can get one for free from any garbage dump.
* test: update to new ffmpeg pixfmtswm42020-06-175-5/+25
| | | | | Mainly, X2RGB10BE is added. Add our own unpack test for this format. Also, swscale seems to have added support for GBRPF conversion.
* video: alias IMGFMT_RGB30 to AV_PIX_FMT_X2RGB10wm42020-06-171-0/+4
| | | | | | | IMGFMT_RGB30 was added first; FFmpeg added AV_PIX_FMT_X2RGB10 later. This is exactly the same, so treat them as such. For some reason, libswscale still seems to output incompatible data - not sure what this is about, but I'm not going to debug it.
* repack: handle endian in a more general waywm42020-06-171-6/+7
| | | | | | | | Instead of applying this only to "regular" formats, do it with all formats. For some reason, some repackers still have their own endian code. These could probably be removed, but whatever.
* img_format: fight ffmpeg pixdesc some morewm42020-06-171-28/+49
| | | | | | | | | | | | | | | | | | | | | This change attempts to fix detection of how endian swapping is to be performed. Details can be found in the code comments. It should not change anything, other than fixing handling of the X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and the component location metadata was discarded due to an internal consistency check. With this commit, it is handled correctly. At first I thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears to be correct. The problem with this format is that it's the first packed RGB format that requires bit shift to access, and where the endian word size is larger than the (rounded up) component size, all while pixdesc would "require" you to perform 3 memory accesses (instead of 1), and the code tries to reverse this. It appears that trying to use the pixdesc metadata is much, much more work than just duplicating it in a saner form. To be fair, most problems are with big endian, and the mpv internal format does not care much about endian _hosts_.
* audio: don't lock ao_control for pull mode driversKevin Mitchell2020-06-171-2/+7
| | | | | | | | | | | | | The pull mode APIs were previously required to have thread-safe ao_controls. However, locks were added in b83bdd1 for parity with push mode. This introduced deadlocks in ao_wasapi. Instead, only lock ao_control for the push mode APIs. fixes #7787 See also #7832, #7811. We'll wait for feedback to see if those should also be closed.
* vo_gpu: placebo: add fallback code for stride mismatchNiklas Haas2020-06-161-12/+52
| | | | | | | | | | | | | | | For cases in which the requirements of the GPU API prevent directly uploading a texture with a given stride, we need to fix the stride manually in host memory. This incurs an extra memcpy, but there's not much we can do about it. (Even in `ra_gl` land, the driver will just hide this memcpy from the user) Note: This code could be done better. It could only copy as many texels as needed, and it could pick a stride that's a multiple of `gpu->limits.align_tex_xfer_stride` for better performance. Patches welcome (tm) Fixes #7759
* vo_gpu: add BT.2390 tone-mappingNiklas Haas2020-06-154-7/+61
| | | | | | | | | | | | 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-154-9/+13
| | | | | | | | | | | | 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.
* vo_gpu: move coherent specifier to the correct locationNiklas Haas2020-06-102-2/+2
| | | | | | | | | | glslang accepted this, perhaps erronneously, but mesa does not. It seems to be incorrect. A caveat is that this means *all* SSBOs are now coherent, but since we only use SSBOs for peak detection, that's a non-issue. (And besides, marking something as coherent when we don't perform any synchronization commands on it should be a no-op anyway) Fixes #7823
* player: make unpausing directly after seek work with --keep-open (again)wm42020-06-101-0/+3
| | | | | | | | | | | | Commit fcf0b80dc9dd3 fixed this the first time. Commit 85576f31a9cc2 "accidentally" removed this code again. The commit message justifying the removal is correct, except it doesn't take other side-effects of the state machine into account. I obviously didn't remember what exactly this was about. So add a comment explaining it this time. Just apply it again; the thing the latter commit fixed still works. Fixes: #7819
* audio: require certain AOs to set device_bufferwm42020-06-092-3/+3
| | | | | | | | | | AOs which use the "push" API must set this field now. Actually, this was sort of always required, but happened to work anyway. The future intention is to use device_buffer as the pre-buffer amount, which has to be available right before audio playback is started. "Pull" AOs really need this too conceptually, just that the API is underspecified. From what I can see, only ao_null did not do this yet.
* ao/pulse: properly set device_bufferNicolas F2020-06-071-0/+8
| | | | | | | | | Previously, device_buffer defaulted to 0 on pulse. This meant that commit baa7b5c would always wait with a timeout of 0, leading to high CPU usage for PulseAudio users. By setting device_buffer to the number of samples per channel that PulseAudio sets as its target, this commit fixes this behaviour.
* cocoa-cb: properly reset window isMoving state on title bar clicksder richter2020-06-061-0/+2
| | | | | | | | | since the title bar catches the mouse up and down events, the underlying events view doesn't reset the isMoving state and no mouse movements are signalled to the core. now we also reset the state in mouse up events on the title bar. Fixes #7807
* vo_gpu: fix display corruption with window screenshotswm42020-06-061-0/+1
| | | | | | | | | The "screenshot window" command (ctrl+s by default) somehow broke video colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused. I don't know the cause, but the rest of the code seems to imply gl_video_reset_surfaces() needs to be called manually to flush some caches, and it fixes the issue, so I assume there's no great mystery here.
* vo_gpu: mark peak detection buffer coherentNiklas Haas2020-06-061-1/+1
| | | | This is required for buffer memory barriers to actually work
* vo_gpu: make storage images/buffers as restrictNiklas Haas2020-06-061-2/+2
| | | | | This informs the GPU that we don't alias it with any other descriptors (which we don't).
* vulkan/wayland: fix another build breakageDaniel Bermond2020-06-051-1/+1
| | | | | | | | | | | | | | | Commit 07b0c18 introduced some build breakages. Some breakages were fixed on c1fc535 and a1adafe. This one is still remaining. This commit fixes the following build error: [153/521] Compiling video/out/vulkan/context_wayland.c ../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory 26 | #include "video/out/wayland/presentation-time.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Relevant to: #7802
* build: fix another breakagewm42020-06-041-1/+1
| | | | | | | The build was still broken. Feel free to look for a better maintainer if you don't like it. Fixes: #7802 (maybe now?)
* wayland: fix buildwm42020-06-042-3/+3
| | | | | | Broken by previous commit. I've split a commit incorrectly. Fixes: #7802
* build: change filenames of generated fileswm42020-06-0415-69/+54
| | | | Force them into a more consistent naming schema.
* audio: fix deadlock on drainingwm42020-06-041-1/+1
| | | | | | | | | | | The playback thread may obviously still fill the AO'S entire audio buffer, which means it unset p->draining, which makes no sense and broke ao_drain(). So just don't unset it here. Not sure if this really fixes this, it was hard to reproduce. Regression due to the recent changes. There are probably many more bugs like this. Stupid asynchronous nightmare state machine. Give me a language that supports formal verification (in presence of concurrency) or something.
* options: add --video-scale-x/ywm42020-06-034-4/+18
| | | | | | Requested. Fixes: #6303
* audio: adjust wait durationwm42020-06-031-6/+4
| | | | | | | | | | | | | | | I feel like this makes slightly more sense. At least it doesn't include the potentially arbitrary constant latency that is generally included in the delay value. Also, the buffer status doesn't matter - either we've filled the entire buffer (then we can wait this long), or there's not enough data anyway (then the core will wake up the thread if new data is available). But ultimately, we have to guess, unless the AO does notify us with ao_wakeup_playthread(). Draining may now wait for no reason up to 1/4th of the total buffer time. Shouldn't be a disimprovement in practice.
* vaapi: correct broken NULL checkwm42020-06-031-1/+1
| | | | | | | Clearly, we want to check whether vaGetDisplayDRM() returned NULL. out_display itself is already implied non-NULL. Fixes: #7739
* audio: avoid possible deadlock regression for some AOswm42020-06-021-2/+17
| | | | | | | | | | | | | | | It's conceivable that ao->driver->reset() will make the audio API wait for ao_read_data() (i.e. its audio callback) to return. Since we recently moved the reset() call inside the same lock that ao_read_data() acquires, this could deadlock. Whether this really happens depends on how exactly the AO behaves. For example, ao_wasapi does not have this problem. "Push" AOs are not affected either. Fix by moving it outside of the lock. Assume ao->driver->start() will not have this problem. Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm unsure whether anyone experienced the problem in practice.
* audio: further simplify internal audio API somewhatwm42020-06-025-47/+41
| | | | | | | | | | | | Instead of the relatively subtle underflow handling, simply signal whether the stream is in a playing state. Should make it more robust. Should affect ao_alsa and ao_pulse only (and ao_openal, but it's broken). For ao_pulse, I'm just guessing. How the hell do you query whether a stream is playing? Who knows. Seems to work, judging from very superficial testing.
* audio: slightly better condition for still_playingwm42020-06-021-1/+1
| | | | | | Just a detail. If wrong (not unlikely because I'm just guessing my own messy state machine), this will make the player freeze due to waiting for something that never happens. Enjoy.
* af_scaletempo: handle obscure integer overflowwm42020-06-021-4/+4
| | | | | Saw it once, not really reproducible. This should fix it, and in any case it's harmless.
* TOOLS/autocrop.lua: automatically crop at startupヒカリ2020-06-011-84/+292
|
* audio: reduce extra wakeups caused by recent changeswm42020-06-011-5/+4
| | | | | | | | | | | | | | | | The feeder thread basically woke up the core and itself too often, and caused some CPU overhead. This was caused by the recent buffer.c changes. For one, do not let ao_read_data() wake up the core, and instead rely on the feeder thread's own buffer management. This is a bit strange, since the change intended to unify the buffer management, but being more consequent about it is better deferred to later, when the buffer management changes again anyway. And also, the "more" condition in the feeder thread seems outdated, or at least what made it make sense has been destroyed, so do something that may or may not be better. In any case, I'm still not getting underruns with ao_alsa, but the wakeup hammering is gone.
* vo: refine wakeup condition, and wake up more in audio sync modewm42020-06-011-3/+3
| | | | | | | | | | | Commit 6a13954d67143fb lowered the frequency of wakeups with this condition. But it seems it sometimes the audio sync mode really should get the wakeup before the frame is rendered. Normally, vo_thread is supposed to perform this wakeup. Now the wakeup frequency is twice of what should be needed - whatever, maybe it can be fixed properly once or if timing is moved to the VO entirely in the future. Fixes: #7777 (probably, untested)
* audio: redo internal AO APIwm42020-06-0120-823/+635
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* audio: fix unpausing with some AOswm42020-05-311-1/+1
| | | | | | | | | wasapi/coreaudio/sdl were affected, alsa/pusle were not. The confusion here was that resume() has different meaning with pull and push AOs. Fixes: #7772
* terminal-win: handle 'Change Window Title' OSC sequenceJames Ross-Gowan2020-05-291-99/+131
| | | | | | | | | | | | | | | | | This should make --term-title work in Windows 8.1 and below. OSC sequences are defined in ECMA-48. The 'Change Window Title' command, as far as I can tell, is a de-facto standard defined by xterm[1]. In either case, this code is probably still not standards-compliant. This also changes mp_write_console_ansi to convert to UTF-16 before parsing control sequences, because that made it easier to pass the OSC param to SetConsoleTitleW. I think it's also more correct to do it this way, even though it doesn't really matter much for our limited terminal parsing. As a side-effect of this, mp_write_console_ansi no longer mutates its argument. [1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands
* ao_null: remove unreferenced functionwm42020-05-271-8/+0
| | | | Forgot in the previous commit to this file.
* audio: stop applying volume twice for some AOswm42020-05-271-1/+0
| | | | | | | Regression since the recent refactor. How did nobody notice? This happened because the push code now calls the function for the pull code. Both the former and latter apply the volume, so oops.
* audio: remove ao_driver.drainwm42020-05-277-48/+12
| | | | | | | | | | The recent change to the common code removed all calls to ->drain. It's currently emulated via a timed sleep and polling ao_eof_reached(). That is actually fallback code for AOs which lacked draining. I could just readd the drain call, but it was a bad idea anyway. My plan to handle this better is to require the AO to signal a underrun, even if AOPLAY_FINAL_CHUNK is not set. Also reinstate not possibly waiting for ao_lavc.c. ao_pcm.c did not have anything to handle this; whatever.
* lua: windows got what users cravewm42020-05-271-0/+3
| | | | | | It's got '\r's. Fixes: #7733
* player: add --term-title optionwm42020-05-257-0/+39
| | | | | | | | | | | | | | 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
* audio: merge pull/push ring buffer glue codewm42020-05-256-1006/+762
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is preparation to further cleanups (and eventually actual improvements) of the audio output code. AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player. This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen. One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior. This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.
* audio: add frame alloc function