Commit Graph

48707 Commits

Author SHA1 Message Date
wm4 2256a9e42b video: fix AV_PIX_FMT_UYYVYY411 allocation
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.
2020-05-18 19:29:25 +02:00
Dudemanguy 55f6ba62be wayland: only use presentation on CLOCK_MONOTONIC
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.
2020-05-18 11:01:40 -05:00
Jan Beich 82ded968aa build: allow wlshm on more Wayland platforms after a6000d3114 2020-05-18 01:57:20 +02:00
wm4 27e5416c12 video: add pixel component location metadata
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.
2020-05-18 01:54:59 +02:00
wm4 caee8748da video: clean up some imgfmt related stuff
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 00653a3eb0). With this I've decided to keep mp_imgfmt_desc,
just removing the weird parts, and keeping the saner parts.
2020-05-18 01:54:59 +02:00
wm4 00ac63c37b test: explicitly test repacking for all packed RGB variants
This stuff is very annoying, so it's good to have full coverage.
2020-05-18 01:54:59 +02:00
Julian c7b94c03f1 stats: UP/DOWN scrolling on page 2 (frame stats)
Code contributed by @avih with only minor modifications to comments by
me.
Fixes #7727.
2020-05-17 20:11:50 +02:00
Michael Forney 3cb9e93cdf vo_wlshm, vo_drm: set image size with mp_image_set_size
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.
2020-05-17 12:53:26 +02:00
Ed Santiago 43cb89fca3 zsh completion: helper functions in private namespace
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.
2020-05-17 12:47:12 +02:00
wm4 152b0e2a8c osc: fix hovering timestamp sticking around when moving mouse away
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.
2020-05-16 13:45:16 +02:00
Niklas Haas 09b68648f1 vo_gpu: ra_pl: add timers support
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.
2020-05-16 06:18:44 +02:00
wm4 5ebb498b7a scripting: make socket FD number for subprocesses dynamic
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.
2020-05-15 16:37:41 +02:00
wm4 c4d0d7a194 sub: fix incorrect commit
Commit c6369933f1 accidentally added an old version of this comment.
2020-05-15 16:37:41 +02:00
wm4 810b37fc3f ipc: mark client sockets as CLOEXEC
I suppose it would have left the socket open if the client closed its
FD.
2020-05-15 16:37:41 +02:00
wm4 1c66e03ae5 scripting: correct passing FDs
For external scripts/processes which use IPC. The mistake didn't really
matter.
2020-05-15 16:37:41 +02:00
wm4 60f8cd4072 osdep: remove posix_spawn() helpers and wrappers
See previous commit. Farewell, useless shitty POSIX function.
2020-05-15 16:37:41 +02:00
wm4 5309497727 subprocess: replace posix_spawnp() with fork()
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).
2020-05-15 16:37:41 +02:00
wm4 a58b2df3f8 command: add input-key-list property
Fixes: #7698
2020-05-14 22:22:33 +02:00
wm4 c6369933f1 command: add property to return text subtitles in ASS
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.
2020-05-14 22:14:49 +02:00
wm4 0049ea38be ipc: exit client if the FD is invalid
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).
2020-05-14 21:42:46 +02:00
wm4 26bd8479d0 ipc: make --input-ipc-client terminate player on connection close
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
2020-05-14 21:40:43 +02:00
wm4 edaefd6b47 vo_x11: add 10 bit support
Requires zimg.
2020-05-14 17:23:48 +02:00
Jan Palus 727b1bff57 build: link against single EGL provider
when building with rpi EGL is provided by librcmegl library and libEGL
should not be linked then
2020-05-14 15:08:33 +02:00
Jan Palus 65fd6c8ae9 build: fallback to default pc file locations on rpi 2020-05-14 15:08:33 +02:00
Jan Palus ac1634360b drm: add typedef for PFNEGLGETPLATFORMDISPLAYEXTPROC (#7314)
extension is not mandatory and is not provided on ie Raspberry Pi
2020-05-14 15:07:58 +02:00
wm4 fd8e856afe vo_direct3d: dumb down OSD rendering
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.
2020-05-13 23:16:32 +02:00
wm4 97706a2aec draw_bmp: make another small guarantee to users
Mostly self-evident.
2020-05-13 22:46:29 +02:00
wm4 b36484063f vo_direct3d: rip out texture video rendering path
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.
2020-05-13 22:19:00 +02:00
wm4 baabd5fce3 draw_bmp: use command line options for any used scalers 2020-05-13 20:07:59 +02:00
Niklas Haas 6d8b3f9333 vo_gpu: un-fix storable fbo format check
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.
2020-05-13 18:54:30 +02:00
wm4 0ff839d467 draw_bmp: add integer blending for 8 bit formats
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.
2020-05-12 23:10:14 +02:00
wm4 1e75f442b1 repack: fix incorrect assert()
Used the output of the first step instead of the input when checking the
real input.
2020-05-12 23:08:10 +02:00
wm4 c4b2ca83d6 draw_bmp: don't make strange decisions on broken iknput csp params
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.)
2020-05-12 22:43:29 +02:00
wm4 3451908a34 vo_vaapi: use new overlay API
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.
2020-05-11 19:57:34 +02:00
wm4 55e1f15cdb draw_bmp: add a function to return a single-texture OSD overlay
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.
2020-05-11 19:57:34 +02:00
wm4 6db890ebab video: remove RGB32/BGR32 aliases
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.
2020-05-11 19:57:34 +02:00
Avi Halachmi (:avih) b5284a6829 js: mp.set_osd_ass: ignore identical inputs (match ccbb8b1c) 2020-05-10 21:20:28 +03:00
wm4 4e94b2177a vo: fix forgotten debug code
This was not intended to be committed in 0e3f893606. 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).
2020-05-10 17:00:11 +02:00
wm4 a7d11b2fc0 lua: do not use Lua filesystem functions for loading scripts
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
2020-05-10 17:00:07 +02:00
wm4 ad9f3bfe96 stream: make stream_read_file() more robust
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.
2020-05-10 16:44:35 +02:00
wm4 a600d152d2 msg: add function to reduce log level
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.
2020-05-10 16:40:26 +02:00
wm4 0b09771ba9 vo_gpu: manually resolve user shader prefixes
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.
2020-05-10 16:36:47 +02:00
wm4 caf228b218 player: make external subtitle auto-loading stricter
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
2020-05-09 23:31:33 +02:00
wm4 327302bdb9 options: update OSD when writing some OSD-related options
Just the usual change notification mess.

Fixes: #7697
2020-05-09 22:36:06 +02:00
wm4 0e3f893606 vo: another minor wakeup reduction
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.
2020-05-09 22:32:28 +02:00
wm4 2446f5f43b vo: always reset redraw flag to avoid immediate wakeups wasting CPU time
This could temporarily hog the core or something because it's a stupid
fragile state machine that should best be wiped out.

Fixes: #7699
2020-05-09 22:23:18 +02:00
wm4 c1a961ad78 draw_bmp: rewrite
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.
2020-05-09 18:02:57 +02:00
wm4 9190b3c469 repack: add support for converting from/to float formats
Will be needed by draw_bmp.c. The tests cross-check this with zimg to
control whether we're getting it right.
2020-05-09 18:02:57 +02:00
wm4 bf19f34960 csputils: add function for getting uint/float transformation
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.
2020-05-09 18:02:57 +02:00
wm4 56dbbc3847 video: add yuv float formats
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.)
2020-05-09 18:02:57 +02:00