summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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_bmp: add integer blending for 8 bit formatswm42020-05-122-41/+79
| | | | | | | | Whatever it's worth. Instead of doing a pretty stupid conversion to float, just blend it directly. This works for most RGB formats that are 8 bits per component or below (the latter because we expand packed fringe RGB formats for simplicity). For higher bit depth RGB this would need extra code.
* repack: fix incorrect assert()wm42020-05-121-1/+1
| | | | | Used the output of the first step instead of the input when checking the real input.
* draw_bmp: don't make strange decisions on broken iknput csp paramswm42020-05-123-64/+66
| | | | | | | | | | | | This checked params->color.space for being RGB. If the colorspace is unset, this did dumb things because even if the imgfmt was a RGB one, the colorspace was not set to RGB. This actually also happened to the tests. (Short-cutting RGB like this is actually wrong, since RGB could still have strange gamma or primaries, which would warrant a full conversion. So you'd need to check for these other parameters as well. To be fixed later.)
* vo_vaapi: use new overlay APIwm42020-05-111-123/+85
| | | | | | | | | | | | | This will probably make it slower. But since I don't care about vo_vaapi, that's perfectly OK. It serves mostly as a test for the previous commit. In addition, this code was pretty bad (custom broken scaling and not-blending that probably broke in some situation). If that wasn't enough, some vaapi drivers also provide only a single overlay at a time, while this code required a bunch. There also seems to be a Mesa bug: the overlay gets stretched when src_x/y was not 0. Or maybe I misunderstood how this is supposed to work. A bug is probably more likely? Nobody cares about this API.
* draw_bmp: add a function to return a single-texture OSD overlaywm42020-05-114-50/+265
| | | | | | | | | | | | | | Maybe this is useful for some of the lesser VOs. It's preferable over bad ad-hoc solutions based on the more complex sub_bitmap data structures (as observed e.g. in vo_vaapi.c), and does not use that much more code since draw_bmp already created such an overlay internally. But I still wanted something that avoids having to upload/render a full screen-sized overlay if for example there's only a tiny subtitle line on the bottom of the screen. So the new API can return a list of modified pixels (for upload) and non-transparent pixels (for display). The way these pixel rectangles are computed is a bit dumb and returns dumb results, but it should be usable, and the implementation can change.
* video: remove RGB32/BGR32 aliaseswm42020-05-115-18/+9
| | | | | | | They are sort of confusing, and they hide the fact that they have an alpha component. Using the actual formats directly is no problem, sicne these were useful only for big endian systems, something we can't test anyway.
* js: mp.set_osd_ass: ignore identical inputs (match ccbb8b1c)Avi Halachmi (:avih)2020-05-101-0/+5
|
* vo: fix forgotten debug codewm42020-05-101-1/+1
| | | | | | | This was not intended to be committed in 0e3f8936062967a9db. It disables the extra wakeup if working==true. I've convinced myself that the wakeup was really needed at the time, so no idea how I didn't notice this until someone pointed it out on the commit diff on github (lol).
* lua: do not use Lua filesystem functions for loading scriptswm42020-05-101-3/+6
| | | | | | | | | | | Bill Gates did not only create COVID, he's also responsible for the world's worst OS, where you have to literally jump through hoops of fire to open files with Unicode file names. Lua did not care to implement any jumping, so it's our turn to jump. Untested (on win32). Fixes: #7701
* stream: make stream_read_file() more robustwm42020-05-103-23/+41
| | | | | | | | | Change it to strictly accept local paths only. No more http://, no more $HOME expansion with "~/" or mpv config path expansion with "~~/". This should behave as if passing a path directly to open(). Reduce annoying log noise to further facilitate it using as open() replacement.
* msg: add function to reduce log levelwm42020-05-102-2/+19
| | | | | | | | | | Sometimes it's helpful to override this for specific mp_log instances, because in some specific circumstances you just want to suppress log file noise you never want to see. -1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like the libplacebo wrapper still does this wrong, so it will probably trigger UB in some cases. I guess I don't care, though.
* vo_gpu: manually resolve user shader prefixeswm42020-05-101-1/+4
| | | | | | | | This resolves prefixes such as "~/" and "~~/" at the caller, instead of relying on stream_read_file() to do it. One of the following commits will remove this from stream_read_file() itself. Untested.
* player: make external subtitle auto-loading stricterwm42020-05-092-25/+41
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* options: update OSD when writing some OSD-related optionswm42020-05-091-9/+9
| | | | | | Just the usual change notification mess. Fixes: #7697
* vo: another minor wakeup reductionwm42020-05-091-5/+10
| | | | | | The caller of render_frame() re-iterates without waiting if this function returns true. That's normally meant for DS, where we draw frames as fast as possible to let the driver perform waiting.
* vo: always reset redraw flag to avoid immediate wakeups wasting CPU timewm42020-05-091-1/+2
| | | | | | | This could temporarily hog the core or something because it's a stupid fragile state machine that should best be wiped out. Fixes: #7699
* draw_bmp: rewritewm42020-05-096-411/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
* repack: add support for converting from/to float formatswm42020-05-094-3/+402
| | | | | Will be needed by draw_bmp.c. The tests cross-check this with zimg to control whether we're getting it right.
* csputils: add function for getting uint/float transformationwm42020-05-092-1/+44
| | | | | | | | | | | | | | This provides a way to convert YUV in fixed point (or pseudo-fixed point; probably best to say "uint") to float, or rather coefficients to perform such a conversion. Things like colorspace conversion is out of scope, so this is simple and strictly per-component. This is somewhat similar to mp_get_csp_mul(), but includes proper color range expansion and correct chroma centering. The old function even seems to have a bug, and assumes something about shifted range for full range YCbCr, which is wrong. vo_gpu should probably use the new function eventually.
* video: add yuv float formatswm42020-05-095-11/+181
| | | | | | | | | | | Adding all these so I can use them for obscure processing purposes (see later draw_bmp commit). There isn't really a reason why they should exist. On the other hand, they're just labels for formats that can be handled in a generic way, and this commit adds support for them in the zimg wrapper and vo_gpu just by making the formats exist. (Well, vo_gpu had to be fixed in the previous commit.)
* vo_gpu: fix green shit with float yuv inputwm42020-05-095-12/+28
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* video: fix rgb30 component orderwm42020-05-095-5/+8
| | | | | | | | | Was broken with a zimg wrapper refucktor before the previous commit. In addition, it seems this didn't match the vo_drm format, or the format naming convention. So the order actually changes, and the format is redefined. (The img_format.h comment was probably wrong.) Change vo_gpu to the new format as well, so we can still test it.
* video: separate repacking code from zimg and make it independentwm42020-05-099-895/+1688
| | | | | | | | | | | | | For whatever purpose. If anything, this makes the zimg wrapper cleaner. The added tests are not particular exhaustive, but nice to have. This also makes the scale_zimg.c test pretty useless, because it only tests repacking (going through the zimg wrapper). In theory, the repack_tests things could also be used on scalers, but I guess it doesn't matter. Some things are added over the previous zimg wrapper code. For example, some fringe formats can now be expanded to 8 bit per component for convenience.
* sws_utils: allow setting zimg options directlywm42020-05-094-8/+18
| | | | One could wonder, why not just use the zimg wrapper directly?
* img_format: make component order in comment more logicalwm42020-05-091-1/+1
|
* sd_lavc: fix occasional problems with certain VOs when changing scalingwm42020-05-091-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | The OSD is passed to VOs via struct sub_bitmaps, which has a change_id field. This field is incremented whenever there is a (potential) change to the other struct contents. If not, the VO can rely on it not having changed. This must include for example sub_bitmap.x and sub_bitmap.dw. If these two fields (and y equivalents) change, change_id must change, even if the subtitle bitmap data might still be the same. sd_lavc.c stopped respecting this at some unknown point. It could sometimes cause problems, though usually only with bad and old VOs which somehow relied on this more than vo_gpu. (I've actually encountered this before with sd_lavc subtitle scaling, as indicated by a nasty comment, though probably didn't track this down, since said old VOs can die in a fire.) Fix this by maintaining the change_id explicitly. Unfortunately adds even more code. Instead of comparing the result we could track property changes, but I think this is better. The number of parts is always very low with this subtitle decoder, so there's no actual performance issue to worry about. This could be triggered by scaling changes (video-zoom etc.), but probably also changing bitmap subtitle position or scaling.
* osd: add change timestamp and screen size to struct sub_bitmap_listwm42020-05-093-1/+23
| | | | | | | | Should be somewhat helpful. (All VOs are full of code trying to compensate for this, more or less, and this will allow simplifying some code later. Maybe.) The screen size is mostly for robustness checks.
* osd: add subtitle software blending to statswm42020-05-091-0/+4
|
* build: add -fno-math-errnowm42020-05-091-0/+1
| | | | | | | | | | | glibc/gcc make certain math functions set errno by default. This is not required by the standard, and makes everything complexer and slower (well done glibc). It typically prevents inlining certain math functions too, where the compiler can turn a function call to a single instruction, such as observed with lrint(). So this has possibly some minor performance advantages, and no disadvantages.
* drm_prime: fallback to drmModeAddFB2Anton Kindestam2020-05-081-3/+9
| | | | | | | | | | Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've observed it failing on a pinebook pro running manjaro. We also got "0" as modifiers from FFmpeg anyway, which might or might not have something to do with this. Instead of trying to find the source of the problem, just add this fallback.
* drm_prime: get the modifier for all planesAnton Kindestam2020-05-081-6/+5
| | | | | | Untested (I don't have a platform that requires modifiers to work here). Might break something, or might fix something. At least this looks more intuitive to me.
* drm_prime: print out errno in error messageAnton Kindestam2020-05-081-1/+4
| | | | It is interesting to know why drmModeAddFB2WithModifiers failed.
* w32_common: Scale window when moving to display with different DPIPiotr Gasior2020-05-081-0/+5
| | | | | For applications that are DPI aware WM_DPICHANGED message contains suggested size and position of window
* w32_common: Support HiDPI on WindowsRealDolos2020-05-083-12/+29
|
* vo_gpu: d3d11: only use presentation feedback with flip modelJames Ross-Gowan2020-05-071-4/+12
| | | | | | | | | | | The current implementation of presentation feedback was designed to be used with flip model presentation. With the bitblt model, GetFrameStatistics returns totally different values and it's not clear if we can use them at all. Previously, this wasn't a problem because with the bitblt model, GetFrameStatistics only worked in exclusive fullscreen. Now that mpv supports exclusive fullscreen, we should explicitly check for a flip model swapchain before using presentation feedback.
* client API: correct an outdated commentwm42020-05-061-2/+1
|
* options: don't trigger bool "compact" path for --loop-filewm42020-05-062-2/+4
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
|
* test: fix some idiotic UBwm42020-05-061-3/+3
|
* mp_image: add some helperswm42020-05-062-0/+23
| | | | | | | | | | This is really basic for planar image data access; not sure why there weren't such helpers before. They also handle trickier formats that use bit-packing, or they would be mich simpler. (This affects only BGR4/BGR4/MONOW/MONOH, I hope whoever invented them is proud of triggering so many special cases for so little gain.)
* vo_gpu: suppress PL_FATAL logs during probingNiklas Haas2020-05-031-2/+0
| | | | | | | | | These were still mapped to MP errors during probing, but they also get triggered when instance creation fails due to lack of support for e.g. wayland. Since waylandvk is probed above x11vk, we should probably suppress these by default. Closes #7626
* documentation: fix some ReST syntax mistakes in lua.rstEmanuele Torre2020-05-011-1/+1
|
* player: round position percentage to the nearest integerRicardo Garcia2020-05-011