summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* CI: add FreeBSD jobJan Beich2020-05-252-0/+63
|
* osdep: remove confstr() fallback for subprocess spawningsfan52020-05-251-7/+2
| | | | | It doesn't exist on bionic (Android) and accurately emulating execvpe's behaviour isn't all that important.
* x11_common: added ICCCM WM_HINTSArthur Williams2020-05-241-0/+11
| | | | | | | | | | | | | | | | | | When the window is mapped, some ICCCM WM_HINTS are set. The input field is set to true and state is set to NormalState. To quote the spec, "The input field is used to communicate to the window manager the input focus model used by the client" and "[c]lients with the Passive and Locally Active models should set the input flag to True". mpv falls under the Passive Input model, since it expects keyboard input, but only listens for key events on its single, top-level window instead of subordinate windows (Locally Active) or the root window (Globally Active). From the end users prospective, all EWMH/ICCCM compliant WMs (especially the minimalistic ones) will allow the user to focus mpv, which will allow mpv to receive key events. If the input field is not set, WMs are allowed to assume that mpv doesn't require focus.
* 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-237-24/+3
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* command: fix dump-cache parameter parsingwm42020-05-231-2/+4
| | | | | | Commit 9d32d62b615 broke this when it changed OPT_TIME. I simply forgot to adjust the command definition. The effect was that "no" was not accepted as value.
* README: remove trollingwm42020-05-231-4/+0
| | | | | | | | | | | | | | | | | | I guess this qualifies as trolling. It's becoming increasingly clear that Microsoft will not be able to deliver on this promise, at least not in the way they made it seem at first. I'm not sure if Microsoft was the one who did the trolling, or me. I actually expected that we'd get full GUI integration of Linux applications including accelerated graphics, but it was always clear that it wasn't going to work as well as natively. In any case, there is no need to frighten any users. The time when you can run only "Windows Store Apps" on Windows (== the end for mpv and many other applications on Windows) will come soon enough. The "faster than native" statement is based on other people's real experience of software running faster in Linux VMs than native windows ports, by the way.
* audio: redo video-sync=display-adropwm42020-05-2312-56/+192
| | | | | | | | | | | | | | | | | 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.
* af_scaletempo: fix theoretical UBwm42020-05-231-1/+2
| | | | | Passing NULL to memset() is undefined behavior, even if the size argument is 0. Could happen on init errors and such.
* options: add option to control display-sync factorwm42020-05-234-3/+18
| | | | | | | | 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.
* vo_x11: allow OSD rendering outside of video regionwm42020-05-221-65/+52
| | | | | | | | | | | | | | | | | | | | | | | | I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
* mp_image: add helper for clearing regions outside of a rectanglewm42020-05-222-0/+16
| | | | Not sure if generally useful; the following commit uses it.
* common: add helper for subtracting rectangleswm42020-05-222-0/+24
| | | | Not sure if generally useful; the following commit uses it.
* video: add AV_PIX_FMT_UYYVYY411 conversion supportwm42020-05-224-34/+60
| | | | | | | | | | It may be completely useless, and I can't verify it as no known samples or other known/accessible software using it, but why not? Putting this together with he 422 code requires making it slightly more generic. I'm still staying with a "huge" if tree instead of a table to select the scanline worker callback, because it's actually small and not huge (although it not being generic still feels slightly painful).
* repack: use new imgfmt metadata in more caseswm42020-05-211-74/+59
| | | | | | Now everything is super generic and super undebuggable. Some awkwardness because the new metadata is basically a transposed version of the mp_regular_imgfmt metadata, which was used for component info before.
* img_format: expose another helperwm42020-05-212-2/+6
|
* mp_image: reimplement mp_image_clear()wm42020-05-211-25/+104
| | | | | | | | | | | | The old code ignored many corner cases, and even wrote "blacker than black" to YUV images. Use the new pixel format metadata and other recently added gimmicky crap, which should make this more correct. Even the almighty fuckup of a format AV_PIX_FMT_UYYVYY411 should work, although that couldn't be tested for obvious reasons. This doesn't work for "monow", but this is so extremely fringe while at the same time painful that I just won't care. In theory, it could be modeled as some sort of inverted gray colorspace or something.
* video: remove useless mp_imgfmt_desc.avformat fieldwm42020-05-203-5/+2
| | | | Had 1 user; easily replaced.
* vo_x11: minor improvement in format matchingwm42020-05-201-5/+5
| | | | | | | | | Make sure to accept only native endian mpv formats. Previously, it didn't check, and simply matched LE, because these are usually defined before the BE formats. red_mask etc. are defined as unsigned long, so use that instead of hardcoding a 32 bit limit.
* video: clean up pixel metadata stuff some morewm42020-05-204-509/+545
| | | | | | | | | | | | | | | A repeat of the previous useless commits. Pondered whether to use separate fields or just a flags integer for color and component types; the latter won for now. Functions like mp_imgfmt_get_component_type() are now discouraged, and mp_imgfmt_desc.flags is back for defining all information. Some days ago I felt like the opposite would be the better design. Fortunately, it doesn't matter. With this, I think all image format properties that mpv needs are exhaustively defined all in one place.
* command: save state on stop when user requested save-position-on-quitMikhail Rudenko2020-05-201-0/+7
| | | | | | | | Execution of "stop" command in the case when idle mode was not enabled resulted in player termination scenario not honoring user setting "save-position-on-quit" from config file. This patch addresses the issue by checking for "save-position-on-quit" in cmd_stop and saving state when idle mode is not enabled.
* vo_x11: use imgfmt metadata instead of hardcoded format tablewm42020-05-201-32/+21
| | | | | | Useless, but super generic! Actually may add support for other fringe formats, however vo_x11 in itself is useless, so nothing won here. Also I didn't bother with big endian support.
* video: shuffle imgfmt metadata code aroundwm42020-05-205-278/+265
| | | | | | | | | | | | | | | | | I guess I decided to stuff it all into mp_imgfmt_desc (the "old" struct). This is probably a mistake. At first I was afraid that this struct would get too fat (probably justified, and hereby happened), but on the other hand mp_imgfmt_get_desc() (which builds the struct) calls the former mp_imgfmt_get_layout(), and the separation doesn't make too much sense anyway. Just merge them. Still, try to keep out the extra info for packed YUV bullshit. I think the result is OK, and there's as much information as there was before. The test output changes a little. There's no independent bits[] array anymore, so formats which did not previously have set this now show it. (These formats are mpv-only and are still missing the metadata. To be added later). Also, the output for the cursed packed formats changes.
* README: looks like we won't need win32 support anymorewm42020-05-191-0/+3
|
* repack: make generic weird pixfmt shit even more generic and obfuscatedwm42020-05-181-54/+20
| | | | | | | | | | | | | | Use the new pixfmt metadata to replace the format tables with weird generic code. As you can see, this removes the tables that essentially duplicate information (which is baaaaaaaaaad), in exchange for code which is probably more fragile and has less of a chance of being understood by someone new to the code (which is probably even worse from a maintenance and robustness point of view, but LALALA I CAN'T HEAR YOU). There are some more formats which can be handled like this (RGB30 and packed YUV I guess), maybe later.
* video: fix AV_PIX_FMT_UYYVYY411 allocationwm42020-05-182-3/+2
| | | | | | | My previous commit added support for this format, but it was still broken, and prevented the allocation code from working. It's unknown whether it's correct now (because this pixfmt is so obscure and useless, there are no known samples around), but who cares.
* wayland: only use presentation on CLOCK_MONOTONICDudemanguy2020-05-181-2/+2
| | | | | | | Trying to use anything other than CLOCK_MONOTONIC here would be a disaster. No idea if it's even possible for the clockid here to be something other than CLOCK_MONOTONIC in this function but it's better safe than sorry. Closes #7740.
* build: allow wlshm on more Wayland platforms after a6000d311421Jan Beich2020-05-181-6/+6
|
* video: add pixel component location metadatawm42020-05-184-130/+875
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I'd probably want something like this, so the hardcoded stuff in repack.c can be removed eventually. Of course this has no purpose at all, and will not have any. (For now, this provides only metadata, and nothing uses it, apart from the "test" that dumps it as text.) This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite, because the format is 100% useless). Support for some mpv-only formats is missing, ironically. The code goes through _lengths_ to try to make sense out of the FFmpeg AVPixFmtDescriptor data. Which is even more amazing that the new metadata basically mirrors pixdesc, and just adds to it. Considering code complexity and speed issues (it takes time to crunch through all this shit all the time), and especially the fact that pixdesc is very _incomplete_, it would probably better to have our own table to all formats. But then we'd not scramble every time FFmpeg adds a new format, which would be annoying. On the other hand, by using pixdesc, we get the excitement to see whether this code will work, or break everything in catastrophic ways. The data structure still sucks a lot. Maybe I'll redo it again. The text dump is weirdly differently formatted than the C struct - because I'm not happy with the representation. Maybe I'll redo it all over again. In summary: this commit does nothing.
* video: clean up some imgfmt related stuffwm42020-05-1815-756/+747
| | | | | | | | | | | | | | | | 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.
* test: explicitly test repacking for all packed RGB variantswm42020-05-182-36/+117
| | | | This stuff is very annoying, so it's good to have full coverage.
* stats: UP/DOWN scrolling on page 2 (frame stats)Julian2020-05-172-3/+25
| | | | | | Code contributed by @avih with only minor modifications to comments by me. Fixes #7727.
* vo_wlshm, vo_drm: set image size with mp_image_set_sizeMichael Forney2020-05-172-4/+2
| | | | | | | | | | The image w and h members must match params.w and params.h, so should not be changed directly. The helper function mp_image_set_size is designed for this purpose, so just use that instead. This prevents an assertion error with the rewritten draw_bmp. Fixes #7721.
* zsh completion: helper functions in private namespaceEd Santiago2020-05-171-6/+6
| | | | | | | | | | | The generate_xxx() helpers, once defined, would appear as user-visible functions; this would lead to unexpected and confusing completion suggestions for gene<tab> after having once run mpv in that shell. This PR adds the prefix '_mpv_' to all completion functions as a convention to make them less user-visible and less likely to collide with other packages.
* osc: fix hovering timestamp sticking around when moving mouse awaywm42020-05-161-3/+11
| | | | | | | | | | | | | | The OSC calls this "tooltip" (and although a general mechanism, there's only one instance using it). One particular problem was that with the default OSC layout, moving the mouse down and out of the window, the tooltip stuck around, because the returned mouse position was the last pixel row in the window, which still overlaps with the seek bar. Instead of introducing mouse_in_window, you could check last_mouse_X for nil, but I think this is clearer. This returns (-1, -1) to the caller if the mouse is outside. Kind of random, but works.
* vo_gpu: ra_pl: add timers supportNiklas Haas2020-05-161-0/+95
| | | | | | | | | | | | | | | Added in libplacebo v60, unfortunately with some changes in design that make it a bit of an awkward fit for the way timers are used in mpv. Timer queries in libplacebo don't support "start" and "stop"-style operations, and instead are attached directly to operations. The only sane way of implementing this in the ra API is to have a single 'active timer' that gets attached to every pass, taking care to sort distinct operations into distinct pl_timer queries within that ra_timer. This design unfortunately doesn't let us have multiple 'active timers' concurrently, similar to the current such limitation in ra_gl. But it's also not a big deal.
* scripting: make socket FD number for subprocesses dynamicwm42020-05-152-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* sub: fix incorrect commitwm42020-05-151-3/+1
| | | | Commit c6369933f1d9cd accidentally added an old version of this comment.
* ipc: mark client sockets as CLOEXECwm42020-05-151-0/+2
| | | | | I suppose it would have left the socket open if the client closed its FD.
* scripting: correct passing FDswm42020-05-151-1/+1
| | | | | For external scripts/processes which use IPC. The mistake didn't really matter.
* osdep: remove posix_spawn() helpers and wrapperswm42020-05-156-163/+2
| | | | See previous commit. Farewell, useless shitty POSIX function.
* subprocess: replace posix_spawnp() with fork()wm42020-05-151-17/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code runs posix_spawnp() within a fork() in some cases, in order to "disown" processes which are meant as being started detached. But posix_spawnp() is not marked as async-signal-safe, so what we do is not allowed. It could for example cause deadlocks, depending on implementation and luck at runtime. Turns out posix_spawnp() is useless crap. Replace it with "classic" fork() to ensure correctness. We could probably use another mechanism to start a process "disowned" than doing a double-fork(). The only problem with "disowning" a process is calling setsid() (which posix_spawnp() didn't support, but maybe will in newer revisions), and removing as as parent from the child process (the double-fork() will make PID 1 the parent). But there is no good way to either remove us as parent, or to "reap" the PID in a way that is safe and less of a mess than the current code. This is because POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives" like win32, no doubt.) Because POSIX/UNIX is a miserable heap of shit, execvp() is also not specified as async-signal-safe. It's funny how you can run a full fledged HTTP server in an async-signal-safe context, but not start a shitty damn process. Unix is really, really, really extremely bad at this process management stuff. So we reimplement execvp() in an async-signal-safe way. The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at different times, but both must be present. io.h defines them to 0 if they don't exist, and in this case the code will error out at runtime. Surely we could do without CLOEXEC via fallback, but I'll do that only if at least 1 bug is reported wrt. this issue. The idea how to report exec() failure or success is from musl. The way as_execvpe() is also inspired by musl (for example, the list of error codes that should make it fail is the same as in musl's code).
* command: add input-key-list propertywm42020-05-144-0/+29
| | | | Fixes: #7698
* command: add property to return text subtitles in ASSwm42020-05-147-18/+62
| | | | | | | | | 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: exit client if the FD is invalidwm42020-05-141-1/+1
| | | | | | | This does not normally happen. But since the --input-ipc-client option can pass in raw FDs, it's probably a good thing in the interest of making mistakes obvious. Without this, it just burned a core on invalid FDs (poll() always returned immediately).
* ipc: make --input-ipc-client terminate player on connection closewm42020-05-142-1/+11
| | | | | | | | 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_x11: add 10 bit supportwm42020-05-141-0/+3
| | | | Requires zimg.
* build: link against single EGL providerJan Palus2020-05-142-11/+37
| | | | | when building with rpi EGL is provided by librcmegl library and libEGL should not be linked then
* build: fallback to default pc file locations on rpiJan Palus2020-05-142-3/+10
|
* drm: add typedef for PFNEGLGETPLATFORMDISPLAYEXTPROC (#7314)Jan Palus2020-05-141-0/+5
| | | | extension is not mandatory and is not provided on ie Raspberry Pi
* vo_direct3d: dumb down OSD renderingwm42020-05-131-164/+92
| | | | | | | | | | | | | | Render most of the OSD on the CPU, then draw it using a relatively simple method. Do this for minimum code maintenance overhead. (While it doesn't matter for vo_direct3d, and the effort spent here is probably more than this would ever hope, I do hope to simplify the internal OSD API for all these fringe VOs. Only vo_gpu should be allowed to do more sophisticated things.) If your GPU is shit (which it will be if you "want" to use vo_direct3d), this might actually improve performance... is what I'd say, but out of laziness a full screen sized texture gets uploaded on every OSD/subtitle change, so maybe not.
* draw_bmp: make another small guarantee to userswm42020-05-131-0/+2
| | | | Mostly self-evident.
* vo_direct3d: rip out texture video rendering pathwm42020-05-135-660/+67
| | | | | | | | | | | | | 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.
* draw_bmp: use command line options for any used scalerswm42020-05-135-16/+36
|
* vo_gpu: un-fix storable fbo format checkNiklas Haas2020-05-131-2/+1
| | | | | | | | | The original solution for #7017 was sort of a hack, but this hack is no longer needed because c05e5d9d fixed the underlying issue causing this error to be spammed in the first place. So just remove the "fix" that apparently introduced about as many issueas it fixed. Fixes #7719, hopefully.
* draw_b