Commit Graph

48321 Commits

Author SHA1 Message Date
wm4 8d5abb16f5 meh 2020-03-26 15:58:43 +01:00
wm4 537f011c6d video: report negative subtitle/OSD margins if necessary
Until now, it used only coordinates clipped to the screen for this,
which meant no negative margins were ever reported to libass. This broke
proper rendering of explicitly positioned ASS events (libass simply
could not know the real video size in this case.)

Fix this by reporting margins even if they're negative. This makes it
apparently work correctly with vo_gpu at least.

Note that I'm not really sure if anything in the rendering chain
required non-negative margins. If so, and that code implicitly assumed
it, I suppose crashes and such are possible.
2020-03-26 12:23:32 +01:00
der richter 30f6f27976 travis: reactivate notifications on failure 2020-03-25 23:50:29 +02:00
der richter 570839c68e travis: fix config validation warnings
private keys should be prefixed with an underscore (_). the sudo key is
deprecated and doesn't influence anything anymore.
2020-03-25 23:50:29 +02:00
wm4 e31fbbeeee vd_lavc: make hwdec fallback message more consistent
The "rule" is that a fallback warning message should be shown only shown
if software decoding was used before, or in other words when either
hwdec was enabled before, but the stream suddenly falls back, or it was
attempted to enable it at runtime, and it didn't work.

The message wasn't printed the first time in the latter case, because
hwdec_notified was not set in forced software decoding mode. Fix it with
this commit. Fortunately, the logic becomes simpler.
2020-03-24 23:40:01 +01:00
Avi Halachmi (:avih) 7768452f2d lua: mp.get_property[_osd] don't need special handling anymore
Because they recently became normal autofree functions.
2020-03-23 01:26:01 +02:00
Avi Halachmi (:avih) 5a2fa3f29a lua: readdir: fix double closedir, use one more autofree
The double closedir is a regression from the previous commit, which also
forgot to use the autofree context with the fullpath string.
2020-03-22 23:49:51 +02:00
Avi Halachmi (:avih) 8deffd9fbb lua: autofree: use in few more places where it could leak
This also uses talloc destructors- like the JS autofree does.

The lua autofree is now used at the same places where the JS autofree
is used.
2020-03-22 23:34:19 +02:00
Avi Halachmi (:avih) fb984a3609 lua: autofree: the ctx is now an argument
There's no more need to call mp_lua_PITA to get the ctx, and the
autofree prototype is now enforced at the C level at compile time.

Also remove the redundant talloc_free_children at these functions
since it's now freed right after the function completes.

Also, rename auto_free_node to steal_node_allocations to be more
explicit and to avoid confusion with the autofree terminology.
2020-03-22 23:34:19 +02:00
Avi Halachmi (:avih) eb5635131d lua: use an autofree wrapper instead of mp_lua_PITA
Advantages of this approach:

- All the resources are released right after the function ends
  regardless if it threw an error or not, without having to wait
  for GC.

- Simpler code.

- Simpler lua setup which most likely uses less memory allocation and
  as a result should be quicker, though it wasn't measured.

This commit adds the autofree wrapper and uses it where mp_lua_PITA
was used. It's not yet enforced at the C level, there are still
redundant talloc_free_children leftovers, and there are few more
places which could also use autofree. The next commits will address
those.
2020-03-22 23:34:19 +02:00
wm4 6169fba796 encode: fix occasional init crash due to initialization order issues
Looks like the recent change to this actually made it crash whenever
audio happened to be initialized first, due to not setting the
mux_stream field before the on_ready callback. Mess a way around this.

Also remove a stray unused variable from ao_lavc.c.
2020-03-22 21:08:44 +01:00
wm4 37f441d61b lua: restore recent end-file event, and deprecate it
Lua changed behavior for this specific event. I considered the change
minor enough that it would not need to go through deprecation, but
someone hit it immediately and ask on the -dev channel.

It's probably better to restore the behavior. But mark it as deprecated,
since it's problematic (mismatch with the C API). Unfortunately, no
automatic warning is possible. (Or maybe it is, by playing sophisticated
Lua tricks such as setting a metatable and overriding indexing, but
let's not.)
2020-03-22 19:42:59 +01:00
Jan Ekström 3fedf61532 ci: remove missed remnants of libass from the macOS script as well 2020-03-22 14:58:22 +02:00
Jan Ekström 038f2213e1 ci: remove libass enablement
This is no longer a configurable option.
2020-03-22 14:33:41 +02:00
wm4 078e4bd023 travis: shut the fuck up
Travis is currently having "problems" and is spamming IRC all the time
with pointless failure notifications. Make it so that it hopefully sends
a message only when it goes from success to failure, which should
exclude these cases.

While I'm at it, I'd like to complain how idiotic it is to store CI
configuration in a project's source repository. Such a repository should
only contain things that are inherently part of the code's function, not
part of the organization. You don't store bug reports, build results,
the website, developer access controls, etc. in this repository either.
But for CI it's supposed to be OK? I'm all for this "configuration as
code" thing, but what it should mean is that you store configuration
files in some git managed repository, NOT necessarily that you dump them
into the main source code repo. There are many arguments why it should
not be there, such as this very commit. I have a feeling this is mostly
just because all these idiotic web services just want to advertise their
shit and bind customers by not giving easy ways to treat source code and
CI service configuration orthogonal. And so, the source code repo gets
clobbered with stupid shit (both in the set of files and the commit
history). It's fairly idiotic and my tolerance for it is waning. (Oh, of
course you could probably jump through hoops to make it a separate repo,
but I bet that is complicated and has all kinds of downsides because it
won't be the way "it's meant to be used".)
2020-03-22 13:28:50 +01:00
wm4 019f95cf99 encode: deprecate encoding mode
While I'd like to keep it, I'm apparently the maintainer now, and I have
no idea what the heck some of this code does, so it's deprecated.
2020-03-22 13:09:34 +01:00
wm4 63311762ed encode: add some shit that does some shit
?????????????

Makes no sense, can endless loop, but whatever.

Part of #7524.
2020-03-22 13:07:36 +01:00
wm4 de53155971 encode: restore audio muxer timebase use
Seems to crash hard if an error happens somewhere at init. Who cares.

Part of #7524.
2020-03-22 13:06:59 +01:00
wm4 b572f116da encode: fix whitespace 2020-03-22 13:05:50 +01:00
Avi Halachmi (:avih) ee70e8ce50 js: make wait_event autofree
The VM could throw at pushnode and before mpv_free_node_contents, which
would have resulted in leaked content.

Now this case is handled without leaks.

Note: the lua code still leaks on such case, but mp_lua_PITA doesn't
have destructors like the JS autofree has, which, specifically here,
can do mpv_free_node_contents. So TODO: enhance the lua PITA code to
behave more similar to the JS autofree.
2020-03-22 00:53:30 +02:00
Avi Halachmi (:avih) c4cc48c83d js: use unified events (match 218d6643, 8a58a699) 2020-03-21 23:35:51 +02:00
wm4 8a58a69930 lua: simplify further
As suggested by avih. Obviously this was unnecessarily convoluted.
2020-03-21 22:17:05 +01:00
wm4 d375cc304a client API, lua: unify event code further
Move some parts that can be generic to the client API code. It turns out
lua.c doesn't need anything special.

This adds the "id" field. I think this was actually missing from the
JSON IPC code (i.e. it's a very recent regression that is fixed with
this commit).
2020-03-21 22:09:07 +01:00
wm4 0fbe7f9e54 command: fix accidental stack dumping 2020-03-21 22:05:50 +01:00
wm4 218d6643e9 client API, lua, ipc: unify event struct return
Both Lua and the JSON IPC code need to convert the mpv_event struct (and
everything it points to) to Lua tables or JSON.

I was getting sick of having to make the same changes to Lua and IPC. Do
what has been done everywhere else, and let the core handle this by
going through mpv_node (which is supposed to serve both Lua tables and
JSON, and potentially other scripting language backends). Expose it as
new libmpv API function.

The new API is still a bit "rough" and support for other event types
might be added in the future.

This silently adds support for the playlist_entry_id fields to both Lua
and JSON IPC.

There is a small API change for Lua; I don't think this matters, so I
didn't care about compatibility. The new code in client.c is mashed up
from the Lua and the IPC code. The manpage additions are moved from the
Lua docs, and made slightly more "general".

Some danger for unintended regressions both in Lua and IPC. Also damn
these node functions suck, expect crashes due to UB.

Not sure why this became more code instead of less compared to before
(according to the diff stat), even though some code duplication across
Lua and IPC was removed. Software development sucks.
2020-03-21 19:33:48 +01:00
wm4 7e885a3bc3 client API: add a playlist entry unique ID
This should make dealing with some async. things easier.

It's intentionally not a globally unique ID.
2020-03-21 19:33:03 +01:00
wm4 956a5d9ac6 player: add potentially forgotten property change trigger
Unfortunately, merely changing the playlist current position affects the
flags returned by the "playlist" property, so the entirely thing needs
to be marked as changed. Seems to be a design mistake.
2020-03-21 19:32:50 +01:00
wm4 e9e93b4dbe player: add a number of new playlist contol commands/properties
Should give a good deal more explicit control and insight over the
player state.

Some feel a bit pointless, and/or expose internal weirdness. However,
it's not like the existing weirdness didn't exist before, or can be made
go away. (In part, the weirdness is because certain in-between states
are visible. Hiding them would make things simpler, but less flexible.)

Maybe this actually gives users a better idea how the API _should_ look
like, too.

On a side note, this tries to really guarantee that mpctx->playing is
set between playback start/end. For that, the loadfile.c changes assume
that mpctx->playing is set (guaranteed by code above the change), and
that playing->filename is set (probably could never be false; was broken
before and actually would have crashed if that could ever happen; in any
case, also add an assert to playlist.c for this).

playlist_entry_to_index() now tolerates playlist_entrys that are not
part of the playlist. This is also needed for mpctx->playing.
2020-03-21 19:32:50 +01:00
wm4 68d9d11ddf player: playlist-pos now use -1 for "no entry selected"
It's odd that this state is observable, but is made implicit by making
the property unavailable. It's also odd that an API user cannot directly
put the player into such a state.

Just allow reading/writing -1 (or in fact, any out of bounds index) for
this case.

I'm also refraining from using OPT_CHOICE for the "no selection" case,
because although that would be cleaner in theory, it would cause only
problems to API users due to the more complex property type (worse is
better).

One reason for not restricting the integer range on the input property
anymore is that if there are no playlist elements, the range would
contain only 1 integer, which cannot be represented anymore since the
recent m_option change. This was actually broken with 1 element
playlists before (and still is, with the constricted type for OSD and
the add/cycle commands). Doesn't matter too much.
2020-03-21 19:32:50 +01:00
wm4 2de783125b demux: average reported download speed some more
Currently, this reported the number of received bytes per second.
Improve this slightly by averaging over 2 seconds (but still updating
every second).
2020-03-21 19:32:50 +01:00
wm4 c892eff929 manpage: improve loadfile description 2020-03-21 19:32:50 +01:00
wm4 9815887435 osc: avoid using a deprecated event
The new code is pretty much equivalent.
2020-03-21 19:32:50 +01:00
wm4 4a2fd2daf6 client API: actually warn against enabling any deprecated events
Like it was done for the "tick" event, but for all deprecated events.

Not entirely effective, since the C API enables all events by default.
2020-03-21 19:32:50 +01:00
wm4 26ac6ead91 player: fix subtle idle mode differences on early program start
If the user manages to run a "loadfile x append" command before the loop
in mp_play_files() is entered, then the player could start playing
these. This isn't expected, because appending files to the playlist in
idle mode does not normally start playback. It could happen because
there is a short time window where commands are processed before the
loop is entered (such as running the command when a script is loaded).

The idle mode semantics are pretty weird: if files were provided in
advance (on the command line), then these should be played immediately.
But if idle mode was already entered, and something is appended to the
playlist using "append", i.e. without explicitly triggering playback,
then it should remain in idle mode.

Try to follow this by redefining PT_STOP to strictly mean idle mode.
Remove the playlist->current check from idle_loop(), since only the
stop_play field counts now (cf. what mp_set_playlist_entry() does).

This actually introduces the possibility that playlist->current, and
with it playlist-pos, are set to something, even though playback is not
active or being started. Previously, this was only possible during state
transitions, such as when changing playlist entries.

Very annoyingly, this means the current way MPV_EVENT_IDLE was sent
doesn't work anymore. Logically, idle mode can be "active" even if
idle_loop() was not entered yet (between the time after mp_initialize()
and before the loop in mp_play_files()). Instead of worrying about this,
redo the "idle-active" property, and deprecate the event.

See: #7543
2020-03-21 19:32:50 +01:00
wm4 2a85e8a186 player: remove additional newline before exit message
What was this even for? Also, most times, the cleared status line will
show up as an empty new line anyway, so this commit reduces the empty
new lines from 2 to 1.
2020-03-21 13:09:41 +01:00
wm4 a5af126f91 player: actually report an exit error if encoding mode fails on closing
The code that determines the process exit code ignores all stop_play
values other than PT_QUIT. Generally, PT_ERROR is meaningless outside of
play_current_file(), and is mostly equivalent to PT_NEXT_ENTRY.

Do something that makes it report a non-0 exit code, and indicates in
the terminal exit message that something went wrong.

Untested.
2020-03-21 13:03:38 +01:00
Jan Ekström 33519d61aa wayland: simplify mouse wheel direction calculation
Based on an idea by sfan5. Remove abs usage, and instead just
check for negative value, and set variable to either +/-1.
2020-03-19 20:27:55 +00:00
Kevin Mitchell 3aad89829f ao_wasapi: try mix format except for chmap
In shared mode, we previously tried to feed the full native format to
IsFormatSupported in the hopes that the "closest match" returned was
actually that.

Turns out, IsFormatSupported will always return the mix format if we
don't use the mix format's sample rate. This will also clobber our
choice of channel map with the mix format channel map even if our
desired channel map is supported due to surround emulation.

The solution is to not bother trying to use anything other than the mix
format sample rate. While we're at it, we might as well use the mix
format PCM sample format (always float32) since this conversion will
happen anyway and may avoid unecessary dithering to intermediate
integer formats if we are already resampling or channel mixing.
2020-03-19 20:39:44 +02:00
Kevin Mitchell 609d0ef478 ao_wasapi: handle S_FALSE in mp_format_res_str
IsFormatSupported may return S_FALSE (considered SUCCESS) if the
requested format is not suppported, but is close to one that is.
2020-03-19 20:39:44 +02:00
wm4 433c9a90a5 win32: pthread: define PTHREAD_MUTEX_ERRORCHECK
mpv uses it now. Doesn't need to do anything.
2020-03-19 00:11:23 +01:00
wm4 0b9ed9c274 build: make libass non-optional
Using mpv without libass isn't really supported, since it's not only
used to display ASS subtitles, but all text subtitles, and even OSD.

At least 1 user complained that the player printed a warning if built
without libass. Avoid trying to create the impression that using this
software without libass is in any way supported or desirable, and make
it fully mandatory.

(As far as making dependencies optional goes, I'd rather make ffmpeg
optional, which is an oversized and bloated library, rather than
something tiny like libass.)
2020-03-18 22:45:59 +01:00
wm4 cb82cbbbae osdep: add a pthread debugging wrapper
Because pthread failures are virtually undebuggable (which sure is
pretty strange, given all these heavy instrumentation tools these days).

Of course it affects only files which include osdep/threads.h.

I'm departing from the usual way to add symbols with config.h and using
"#if", and defining it on the compiler command line + "#ifdef" because I
don't want to include config.h from a header (which would be necessary
in this case) to keep things slightly cleaner. Maybe this is misguided,
but still.

This would have been easier if mpv defined its own wrappers for all
thread functions. But we don't (which to be honest is probably better
than e.g. going crazy like VLC and essentially reimplementing
everything). This seems to be a good compromise. Since it's off by
default and basically a developer tool, the minor undefined behavior
(redefining reserved symbols) isn't much of an issue.
2020-03-18 22:42:13 +01:00
wm4 373dad9962 f_decoder_wrapper: fix use of destroyed mutex
After calling the main filter's destroy callback, all child filters are
destroyed. But one of them still tried to access the cache_lock mutex
(which is destroyed in said destroy callback). This actually caused a
crash on Android with _FORTIFY_SOURCE.

Fix this by destroying the child filters first.
2020-03-18 22:31:17 +01:00
wm4 41e96d8b6b options: fix OPT_BYTE_SIZE upper limits
As an unfortunate disaster, min/max values use the type double, which
causes tons of issues with int64_t types. Anyway, OPT_BYTE_SIZE is often
used as maximum for size_t quantities, which can have a size different
from (u)int64_t.

OPT_BYTE_SIZE still uses in64_t, because in theory, you could use it for
file sizes. (demux.c would for example be capable of caching more than
2GB on 32 bit platforms if a file cache is used. Though for some reason
the accounting code still uses size_t, so that use case is broken. But
still insist that it _could_ be used this way.)

There were various inconsistent attempts to set m_option.max to a value
such that the size_t/int64_t upper limit is not exceeded. Due to the
double max field, this didn't really work correctly. Try to fix this
with the M_MAX_MEM_BYTES constant. It's a good approximation, because on
32 bit it should allow 2GB (untested, also would probably exhaust
address space in practice but whatever), and something "high enough" in
64 bit.

For some reason, clang 11 still warns. But I think this might be a clang
bug, or I'm crazy. The result is correct anyway.
2020-03-18 20:51:38 +01:00
wm4 a550bf4927 demux_mkv: fix another integer/float conversion warning
This code could assign INT64_MAX+1 (as double) to int64_t.
2020-03-18 20:44:54 +01:00
wm4 f73db96077 client API: fix MPV_FORMAT_DOUBLE => MPV_FORMAT_INT64
(Why can it do this conversion at all? This is  shitshow anyway.)
2020-03-18 20:43:56 +01:00
wm4 5a81de59a8 m_option: attempt to fix two rounding issues
Since double has a mantissa too small to hold INT64_MAX in full
precision, converting INT64_MAX to double rounds up. Insert some casts
to silence corresponding warnings (as shown by clang 11).

Also, the comparison in multiply_int64() was incorrect (I think...),
because if v==(double)INT64_MAX, then v==(1<<64), which cannot be
represented as int64_t.

There are probably better ways to solve this.
2020-03-18 20:19:13 +01:00
wm4 26f4f18c06 options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with

   {"name", ...

followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.

I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.

Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.

Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.

In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-18 19:52:01 +01:00
Dudemanguy cdd6eb0994 wayland: notify vo if an output changes
Previously, the vo wasn't always informed if something about the output
changed during playback. For instance, changing a display's refresh rate
during playback would not update mpv's display fps. Fix this by simply
using VO_EVENT_WIN_STATE in output_handle_done which executes whenever
something about the output is changed.
2020-03-15 12:42:33 -05:00
wm4 281f5c63c1 m_option: remove debug code
Forgot to remove this. Here you see my confusion and realization how
casting INT64_MAX to double becomes INT64_MAX+1 (due to mantissa
precision and rounding), so some things seemed not to make sense at
first.
2020-03-14 19:08:47 +01:00