1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 16:33:02 +00:00
Commit Graph

48014 Commits

Author SHA1 Message Date
wm4
7bb3f53cf5 command, vo: add a mechanism for runtime DPI scale changes
Follow up to commit a58585d5e0. It turned out that the OSX backend
needs this.
2020-01-09 19:13:42 +01:00
der richter
57f9de7b53 travis: update macOS images and make building faster
don't build our own ffmpeg anymore and instead use the bottled version
from homebrew. update the newest macOS image. also handle macOS 10.12
as a legacy OS since homebrew and Apple stopped supporting it.
nevertheless it's helpful to build on that version since it's the last
version we support building on. it's a bit special since we have to pin
the homebrew-core version to a previous one where all the bottles for
macOS 10.12 are still available, otherwise it would build nearly
everything from source and that would take ages. also start caching the
homebrew cache folder for downloads.
2020-01-09 19:11:38 +01:00
wm4
363048077f client API: fix property notification from non-playloop sources
This code assumed that the function is only called from the playloop
itself (and since property notification is done at the end of it, i.e.
before sleeping, it obviously would not have needed to wake up the
core).

But this function is actually called from some comments (such as
playlist-move), so this assumption was incorrect. Use the same method as
the other function.

Untested.

Fixes: #7339 (probably)
2020-01-09 18:16:41 +01:00
wm4
3a9f0f537f client API: change event mask to event number in one place
Cosmetic change. Slightly more convenient/readable.
2020-01-09 18:12:10 +01:00
wm4
33e999de82 stream_libarchive: fix unnecessarily opening all volumes on opening
Seems like I'm still not done with rar playback stuff...

It turns out the reason for archive_read_open1() opening all volumes had
nothing to do with libarchive's rar code, but was a consequence of how
multi volume support is implemented in libarchive, and due to the fact
that we enabled archive_read_support_format_zip_seekable() (through
archive_read_support_format_zip()).

The seekable zip format will seek to the end of the file and search for
a zip "header" there. It could possibly be considered a libarchive bug
that it does that even if it's fairly sure that it's a RAR file.

We already do probing on a small buffer read from the start of the file
(i.e. not giving libarchive a way to seek the stream before we think
it's an archive), but that does not help, since libarchive needs to
probe _again_. libarchive does not seem to provide a function to query
the format (no archive_read_get_format()). Which seems quite strange,
but at least I didn't find one.

This commit works this around by doing some manual rar/zip probing. We
could have gone only with rar probing. But detecting zip separately
allows us to avoid that stream_libarchive seeks to the end during early
probing. This is an additional bonus on top of "fixing" multi volume
rar.

The zip probing is from archive_read_format_zip_streamable_bid(). The
rar signature is the common prefix of the rar and rar5 formats in
libarchive (presumably the RAR fixed header parts without version).

If the demuxer seeks to the end of the rar entry, this will still open
all volumes; I'm not sure whether the old/removed rar code in mpv could
handle this better.

See: #7182
2020-01-09 02:25:13 +01:00
Avi Halachmi (:avih)
5e0875c9e0 js: use osd-dimentions for mp.get_osd_{size,margins}
This matches lua's 11b9315b but with the lagacy field names which the
js code used previously.

Currently the property always returns an object (with dummy/last/null
field values if there are no dimensions), but the code is ready for
a future case where it might return null if there are no dimensions - at
which case it will forward the null, breaking backward compatibility for
a better API.
2020-01-08 11:49:49 +02:00
wm4
f612de1712 vo_gpu: fix crash if dither texture fails to allocate
Theoretically possible (and quite unlikely due to the small texture
size). The code was originally written with the assumption that texture
allocations can't fail, and it was never updated out of laziness.
Untested.
2020-01-08 03:45:17 +01:00
wm4
1c83ded3b0 osc: don't delay updates on resize
The idea is that if the player is resized, we do not delay redrawing
(which is normally done to limit the redraw rate to something
reasonable).

Not sure if this even does anything. For one, reacting to osd-dimensions
changes is cleaner than just polling the screen size with the next tick
event, and hoping that resizes generate tick events for whatever
logically unrelated reasons.
2020-01-08 02:37:12 +01:00
wm4
4a65c22c50 osd: fix possible misses of osd-dimensions property updates
check_obj_resize() in sub/osd.c calls mp_client_broadcast_event(), which
calls notify_property_events(). This is pretty unexpected, because
check_obj_resize() may be called from the VO thread. While that's sort
of awful, it seems to be OK locking-wise. But it breaks an assumption in
notify_property_events() that the core doesn't need to be woken up,
which could possibly lead to a missed/delayed property update (although
rather unlikely).

Fix this by explicitly waking up the core when it's called from the OSD
code.
2020-01-08 02:31:18 +01:00
wm4
a58585d5e0 command: cache display-hidpi-scale property
This is a gross hack for the shitty design of how VO properties are
handled (which was fine with MPlayer, but became increasingly a shit tub
with mpv's VO thread).

The problem here is that console.lua reads display-hidpi-scale on every
render, but which may take a long time for video timing and vsync
blocking. It will also block the core, making osc.lua unable to react to
window resizing quickly enough.

This should be solved by not using the "classic" blocking VOCTRL
mechanism, and instead side-stepping it with something that doesn't
require any waiting (like for example the "fullscreen" property does).

But this require more thinking and work my "brain" can handle at the
moment. So for now add a shitty hack that will cause a lot of problems,
and which will have to be replaced later. Most importantly, it'll break
theoretic support for multiple screens with different DPI, or runtime
DPI changes. Possibly could affect the Cocoa backend; the X11 isn't
dynamic enough by nature, and other backends do not implement this.
2020-01-08 02:16:45 +01:00
wm4
7ce41cda05 command: remove outdated MP_EVENT_WIN_STATE entries
These properties are handled very differently now, and being in that
list did pretty much nothing.
2020-01-08 02:01:49 +01:00
wm4
11b9315b3f lua: use new OSD property
See previous commit.

A nice side-effect is that mp.get_osd_margins() is not a special
Lua-only thing anymore. I didn't test whether this function still works
as expected, though.
2020-01-08 00:16:58 +01:00
wm4
db9048f21a command: add osd-dimensions property
This "bundles" all OSD properties. It also makes some previously
Lua-only values available (Lua has mp.get_osd_margins(), unsure if
anything uses it).

The main intention is actually to allow retrieving all fields in an
"atomic" way. (Could introduce a mechanism on the level of the mpv
client API to do this, but doing ti ad-hoc all the time like this commit
is easier.)
2020-01-08 00:16:01 +01:00
wm4
d3cef97ad3 options: change option parsing when using a single dash
Addresses dumb things like accidentally overwriting a media file with
e.g. "mpv --log-file test.mkv" (when the user thought that --log-file
was a flag option, when it actually takes a filename). This example will
now print an error. It still works with "-log-file overwritten.mkv", but
prints a warning.

Not sure if I'm being too careful or not "radical" enough. In any case,
both the syntax that stops working and the syntax that produces a
warning now have been discouraged and were called legacy for almost a
decade.
2020-01-07 23:08:45 +01:00
wm4
5b56be0e91 build: fix minimum libarchive version
Seems like 3.3.3 was not correct and too early.

Fixes: #7334
2020-01-07 22:31:35 +01:00
Dave
bcc921bd2f manpage: explain deprecated usage of multiple items with *-add 2020-01-07 18:13:12 +01:00
Dave
343bf8a9ac DOCS/encoding.rst: remove deprecated usage of multiple items with *-add
4a084c0df8 deprecated multiple -add items
with d3e3bd4307 explicitly warning against
this usage.
2020-01-07 18:13:12 +01:00
wm4
28650e116a stream_libarchive: enable anger management
Well that was too much misery when trying to deal with an idiotic
feature, so it had to be compensated for.
Replace insults with proper explanation, libarchive sort of isn't guilty
in the first place, and their format support is pretty good all things
considered.
2020-01-07 15:32:27 +01:00
Dudemanguy
9eb399193e wayland: don't exit the option loop
More than one option may change at the same time so don't break out of
this loop.
2020-01-04 22:02:36 +00:00
wm4
d26b5daf3e command: make sub-step command actually apply sub-delay change properly
The change was not propagated to the OSD/subtitle code, since that still
uses an "old" method. Change it so that the propagation is actually
performed.

(One could argue the OSD/subtitle code should use other ways to update
the options, but that would probably be more effort for now.)
2020-01-04 21:12:29 +01:00
wm4
1b0129c414 stream_libarchive: remove "old" rar volume pattern
This turned every "normal" .rar filename into a multi-volume one
accidentally. Since the detection is purely by filename (due to lack of
support by libarchive I guess), it causes the nasty message added in the
previous commit to appear for every .rar file. Just drop it.
2020-01-04 20:49:00 +01:00
wm4
119bad4daa stream_libarchive: add annoying message regarding multi-volume archives
I'm done.
2020-01-04 20:00:43 +01:00
wm4
1b283f6b60 libarchive: some shitty hack to make opening slightly faster
See manpage additions. The libarchive behavior mentioned in the last
paragraph there is technically unrelated, but makes this new option
mostly pointless.

See: #7182
2020-01-04 19:56:09 +01:00
wm4
4231ce6f5f stream_libarchive: log each opened volume
To annoy the user.
2020-01-04 19:48:55 +01:00
wm4
5016a1e4a6 demux: add per-demuxer sub-options
Until now, they were all just added to options.c (e.g. demux_mkv_conf).
This adds a mechanism which can be used to add future options in a
(very) slightly more elegant way.
2020-01-04 19:47:36 +01:00
wm4
8150b8552b options: add mechanism to add sub-options from component lists
There are a lot of ad-hoc component lists in mpv: for example the stream
and demuxer lists. It doesn't seem to make sense to add any abstractions
around it since they are completely trivial and have very specific
probing mechanisms and so on, so they will remain ad-hoc.

This commits add a way to let these add arbitrary per-component options,
without giving up the ad-hoc way, and without having to dump them into
options.c with lots of ifdeffery (like it was done until now).

Also see next commit.
2020-01-04 19:45:50 +01:00
wm4
4419d29bb0 stream_libarchive: remove unnecessary string list of volumes
Just add the entries as volumes directly.
2020-01-04 19:31:08 +01:00
wm4
04bde06095 stream_libarchive: some more hacks to improve multi-volume archives
Instead of opening every volume on start just to see if it's there, all
all volumes that could possibly exist, and "handle" it on opening. This
requires working around some of libarchive's amazing stupidity and using
some empirically determined behavior. Will possibly break if libarchive
changes some of this behavior.

See: #7182
2020-01-04 18:59:23 +01:00
wm4
657ce1b15c stream_libarchive: enable rar5 support
We whitelist formats (and not all of them). RAR v5 is a separated format
entry for inexplicable reasons. (It's a separate implementation, but who
really wants to support only either of the rar formats?)

I'm not sure if it was libarchive 3.3.3. Their git history is absolutely
chaotic. These people do not know how to use git. I couldn't be bothered
to dig deeper.
2020-01-04 17:15:09 +01:00
wm4
99700bc52c demux_edl: restore relative path resolution
Playing e.g. "dir/f.edl" should make all non-absolute paths in f.edl
relative to "dir".

Commit 0e98b2ad8e accidentally broke this.
2020-01-02 23:31:02 +01:00
Philip Langdale
daa125cb45 osc: reset input handling state on a change in visibility mode
Currently, the activation and deactivation of input handling is done
inside the render() loop, but this does not run when the osc mode is
`never` - which does make sense.

That means that if you are cycling the visibility mode, the input
state will be whatever it was at the time of the mode change. And,
as our modes are ordered `auto` -> `always` -> `never`, the input
state will be enabled when you cycle to `never`.

There are various ways you can imagine fixing this, and in this
change I propose we reset the input state to disabled on a mode
change, and then let render() re-enable input if that's appropriate.

Fixes #7298.
2020-01-02 07:32:57 -08:00
Dudemanguy
5feee11e43 wayland: disable by default for gnome
It turns out that gnome wayland still has very serious issues that make
it unusable for playback with mpv. Other compositors mostly behave fine
(Plasma is just missing feature but it's not seriously broken), so GNOME
gets the special honor of having a warning printed out. The only
solution for GNOME users at this time of writing is to either use the
Xorg session or use another wayland compositor.
2020-01-01 20:27:54 +00:00
Dudemanguy
7d08491cd9 Revert "vo_gpu: move wayland below X11 in autoprobe order"
This reverts commit a6d8e9b7ff.
2020-01-01 20:27:54 +00:00
wm4
934f8e1026 Bump copyright year
Merry Christmas or whatever it fucking is now.
2019-12-31 17:10:46 +01:00
wm4
3b6c4e7be1 demux: make track switching instant with certain mpegts files
When switching tracks, the data for the new track is missing by the
amount of data prefetched. This is because all demuxers return
interleaved data, and you can't just seek the switched track alone.
Normally, this would mean that the new track simply gets no data for a
while (e.g. silence if it's an audio track). To avoid this, mpv performs
a special "refresh seek" in the demuxer, which tries to resume demuxing
from an earlier position, in a way that does not disrupt decoding for
the non-changed tracks. (Could write a lot about the reasons for doing
something so relatively complex, and the alternatives and their
weaknesses, but let's not.)

This requires that the demuxer can tell whether a packet after a seek
was before or after a previously demuxed packet, sort of like an unique
ID. The code can use the byte position (pos) and the DTS for this. The
DTS is normally strictly monotonically increasing, the position in most
sane file formats too (notably not mp4, in theory).

The file at hand had DTS==NOPTS packets (which is fine, usually this
happens when PTS can be used instead, but the demux.c code structure
doesn't make it easy to use this), and pos==-1 at the same time. The
latter is what libavformat likes to return when the packet was produced
by a "parser" (or in other words, packets were split or reassembled),
and the packet has no real file position. That means the refresh seek
mechanism has no packet position and can't work.

Fix this by making up a pseudo-position if it's missing. This needs to
set the same value every time, which is why it does not work for
keyframe packets (which, by definition, could be a seek target).

Fixes: #7306 (sort of)
2019-12-31 00:17:46 +01:00
Chris Down
b721f9d095 configfiles: Fix utime retcode check
In final fixups for #7139 it seems I managed to screw up utime error
checks. Everything still works, but we MP_WARN when we don't need to.
2019-12-31 00:17:07 +01:00
wm4
fcf0b80dc9 player: make unpausing directly after seek work with --keep-open
When using --keep-open, and the end of the file is reached, the player's
"pause" property is set to true. Attempting to set it to false reverts
it back to true immediately. That's how it's designed, for better or
worse.

Running "seek -10 ; set pause no" did not work, because the seek is
first queued and pause is unset, but then the decoding functions
determine that EOF is still a thing, and "mpctx->stop_play =
AT_END_OF_FILE;" is set again. handle_keep_open() then sets pause again.
Only then the seek is actually run.

Fix this by not setting stop_play if a seek is queued.
2019-12-30 17:40:21 +01:00
wm4
a6d8e9b7ff vo_gpu: move wayland below X11 in autoprobe order
I'm sick of mpv being accused of not doing it right.
You can't do it right on Wayland? Long live X11.

Fixes: #7307
2019-12-30 13:12:33 +01:00
Philip Langdale
5fcad696a9 manpage: update discussion of nvidia hardware acceleration
The text here has become somewhat outdated over the years, and it's
worth updating to reflect the current situation.
2019-12-29 15:09:46 -08:00
Philip Langdale
9c05be8999 video: cuda: add explicit context creation for copy hwaccels
In the distant past, the cuviddec backed copy hwaccel could be
configured directly using lavc options. However, since that time,
we gained support for automatic hw ctx creation which ended up
bypassing the lavc options.

Rather than trying to find a way to pass those options again, a
better idea is to make the 'cuda-decode-device' option, used by
the interop hwaccels, work for the copy hwaccels too.

And that's pretty simple: we have to add a create function that
checks the option and passes it on to ffmpeg.

Note that this does require a slight re-jig to the configuration
flags, as we now have a scenario where we want to build with support
for the cuda copy hwaccels but not the interop ones. So we need
a distinct configuration flag for that combination.

Fixes #7295.
2019-12-29 14:32:47 -08:00
wm4
f0d0822595 demux: fix --stream-record runtime change handling
Well, if that wasn't particularly dumb.
2019-12-29 20:18:35 +01:00
der richter
0737d842b0 build: actually remove MediaPlayer sources from build when disabled
a small oversight on my side when i added the new flag to fix an include
problem for the vo_sub_opts struct.
2019-12-29 18:43:58 +01:00
Philip Langdale
49cbc5017c vo_gpu: hwdec_vaegl: remove support for old-style interop
In vaapi 1.1.0 (which confusingly is libva release 2.1.0), they
introduced a new surface export API that is more efficient, and
we've been supporting that and the old API ever since (Feb 2018).

If we drop support for the old API, we can do some fairly nice cleanup
of the code.

Note that the pkgconfig entries are explicitly versioned by the API
version and not the library version. I confirmed the upstream pkgconfig
files.
2019-12-28 14:31:34 -08:00
Philip Langdale
eb852dc50c vo_gpu: hwdec_vdpau: remove direct_mode
As we are less and less interested in vpdpau, with nvdec and vaapi
being better choices in general on nvidia and AMD respectively, we
might consider removing direct_mode, where we bypass the vdpau
mixer and work directly with yuv textures. Normally, working with
yuv textures would be great, but vdpau built in an assumption that
all frames are delivered as separate fields, causing us to have
to re-interleave them.

nvidia then introduces a new OpenGL extension that can return the
yuv frames as frames, but we can't just unconditionally switch to
that as we'd want to keep supporting older hardware where the drivers
are no longer getting new features. The end result is that we
wouldn't be able to get rid of the old code paths.

Removing direct_mode means we always use the mixer, and work with
rgba frame textures. There are some theoretical limitations to
this, but in practice they probably don't matter much - unsupported
colourspaces don't matter because without 10bit decoding support,
we can't use them anyway, and apparently we're not doing separate
chroma scaling these days, so scaling the rbga doesn't really lose
anything (and the vdpau hq scaling option remains available).
2019-12-28 14:31:06 -08:00
wm4
5a26150717 command: add a playlist-unshuffle command
Has a number of restrictions.

See: #2491, #7294
2019-12-28 21:32:15 +01:00
wm4
582f3f7cc0 playlist: change from linked list to an array
Although a linked list was ideal at first, there are cases where it
sucks, and became increasingly awkward (with the mpv command API
preferring integer indexes to access the list). In future, we probably
want to add more playlist-related functionality, so better change it to
an array now.

An array isn't always ideal either. Since playlist entries are still
separate objects (because in some cases you need a stable "iterator" to
it), but you still need to efficiently get the next/previous playlist
entry, there's a pl_index field, that needs to be maintained. E.g.
adding an entry at the start of the playlist => update the pl_index
field for all other entries. Well, it's not really worth to do something
more complicated to avoid these things.

This commit is probably buggy as shit. It's not like I bothered to test
everything. That's _your_ role.
2019-12-28 21:32:15 +01:00
wm4
4564a22d13 ta: add another funny macro 2019-12-28 21:32:15 +01:00
wm4
65337c032f ta: document funny macros 2019-12-28 21:32:15 +01:00
der richter
e2c6919da0 travis: fix python3 for macOS machines
python3 couldn't be set up as system default because it was blocked by
the old python2.
2019-12-28 21:10:08 +01:00
Oliver Freyermuth
1571276d64 stream_dvb: Remove implicit fallthroughs and consistify debug messages.
The code is more explicit now and less confusing,
and debug messages for the channel parsing for the several delivery systems
are now more similar.
2019-12-28 19:16:07 +01:00