| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Previously, the code required a check against the old saved geometry to
make sure the size and/or position was different before updating. The
doesn't work with the previous changes that allow a geometry value to be
set again with the same value as before. It would probably be nicer to
check against something that always keeps track of the actual window
size in real time, but it seems geometry in x11 doesn't quite work that
way so we'll do it the easier way instead.
|
|
|
|
|
| |
Same reasoning as window-scale. This still requires that the windowing
backend correctly reacts to the notification.
|
|
|
|
|
|
| |
As described in the previous commit, update_window_scale will always
execute whenever window-scale is written even if the value doesn't
change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv's core does not propagate option notifications unless they actually
change to the rest of the player. Most of the time, this makes perfect
sense. If the user sets fullscreen multiple times, there's no reason to
care about anything other than the change in state. However, there are
certain options where it makes sense to always broadcast a notification
even if the value doesn't change. For example, consider the window-scale
case. A user may set window-scale to some value, resize the window
further through some other means (such as mouse resizing) and then want
to set the window-scale again to the same value as earlier. The
window-scale value did not change from before so no notification is sent
and nothing happens even though it is desirable and expected that it
operates again.
This was solved by making the current-window-scale property writable a
few years ago, but actually the easier solution is to just always force
the option to update on any write. For the big callback, the needed
changes are trivial. Unfortunately, it requires a hot mess in order to
have this work with the m_config_cache_update APIs. Spooky stuff in
there, but it does send the notification now.
|
|
|
|
|
| |
This adds a new configuration option vidscale, which controls whether
stats display is scaled with video, similar to the option for OSC.lua.
|
|
|
|
|
| |
This adds a new configuration option plot_bg_border_width, which
controls the border width of plots.
|
| |
|
|
|
|
| |
Fixes #13192, fixes #13431. See the comment for details.
|
|
|
|
|
|
|
|
|
| |
This option type is not used only by filter options: they're already
used by --ao, --vo, and --gpu-context. Replace the mentions of
"filter" to "item" instead, and changes some languages to improve clarity.
Also change the documentation on "Filter options" to describe what it
really is, and fix a typo.
|
|
|
|
| |
The settings list conversion means a custom priority list can now be used.
|
|
|
|
|
|
|
| |
Now that obj_settings_list is used for GPU contexts, detailed
descriptions can be added so that --gpu-context=help can print
the descriptions of the GPU contexts using standard
obj_settings_list help printing.
|
|
|
|
|
|
|
|
|
|
| |
This adds a dummy context at the start of the context lists, which
serves three purposes:
- The "auto" option is listed for --gpu-context=help.
- Some special handlings of "auto" string are removed.
- Make sure that lists have at least one element, so MP_ARRAY_SIZE()
works as intended.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the list of available GPU contexts is a compile time constant,
use obj_settings_list instead of opt_string_validate for GPU contexts.
This has several advantages:
- Aligns with the existing usage of vo, ao, and filter lists.
- Allows custom probing order.
- Allows list option suffixes. (--gpu-context-append, etc.)
- Allows autocomplete in console.lua.
- Uses the standard obj_settings_list help printing, so the custom
help printing function is no longer needed.
This also deduplicates some context creation code for ra_ctx_create
and ra_ctx_create_by_name.
|
|
|
|
|
| |
For contexts that have no API, just use a separate list for them.
This keeps validate func for the main contexts simpler.
|
| |
|
|
|
|
| |
This gives these properties the "time" type, which allows them to be pretty-printed as HH:MM:SS easily (but also still allows raw formatting using e.g. ${=sub-start}).
|
|
|
|
| |
See: https://code.videolan.org/videolan/libplacebo/-/merge_requests/659
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets you press / in page 4 of the stats and type a keybinding or
part of its command to filter it by using mp.input.
This works badly without a VO because both stats.lua and console.lua use
show-text and only one can be displayed at a time, but it's still better
than not having the search available at all.
|
|
|
|
|
| |
The mouse input information is available from the INPUT_RECORD
with MOUSE_EVENT event type.
|
|
|
|
|
|
| |
The size of the console font can be acquired with GetCurrentConsoleFont,
and the terminal size can be calculated from the rols, cols, and font
size.
|
| |
|
|
|
|
| |
This function is used to enable/disable mouse input for win32 and unix.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
21d434d2dbadf91d7bd2089ca1ca92c2d918b114 attempted to ignore unknown
CSI sequences with a specific termination rule. This however does not
apply to mouse CSI sequences which can have characters out of that
range. Fix this by throwing away the whole sequence when an unhandled
mouse sequence is detected.
|
|
|
|
|
|
|
|
| |
These 6-byte codes have the format of \e [ M <button> <xpos> <ypos>.
Support the first 3 mouse bottons + scroll up/down for now as
button numbers > 5 are pretty non-portable across terminals.
Pixel-based mouse position values are calculated and sent to the
input system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable ASS_FEATURE_{WHOLE_TEXT_LAYOUT, BIDI_BRACKETS} and auto base
detection by default, and add an option to disable this if needed.
This is strictly an improvement for webvtt files as they always use
auto base detection. This _fixes_ right-to-left text rendering for
webvtt files which correctly mark rtl/ltr. Webvtt files obtained from
sources which sideload the RTL information through css also see an
improvement due to the auto detection.
Generally SRT files also want this, but some are also written to
workaround VSFilter quirks.
See also: https://github.com/mpv-player/mpv/pull/12985#issuecomment-1839565138
|
|
|
|
|
| |
Also save old playresx and use it instead of assuming values of things
we know.
|
| |
|
| |
|
|
|
|
|
| |
When the window style changes, use WS_EX_TOOLWINDOW style to exclude
the window from the taskbar and Alt+Tab switching.
|
|
|
|
|
|
|
|
|
| |
This adds a new option --show-in-taskbar, which controls whether
mpv appears in taskbars. This is useful for picture-in-picture
setups where the video window should not appear in taskbars.
On X11, this can be controled by setting the
_NET_WM_STATE_SKIP_TASKBAR window state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid having to configure both the OSD and the stats script opts when
you change the OSD options, in particular avoid having to convert colors
to BGR.
Also document the shadow options.
font_size, border_size and shadow offset defaults are kept because the
same values look much bigger in the stats than in the corresponding OSD
options.
osd-back-color is now respected without extra checks until you
explicitly set a shadow_color.
|
| |
|
|
|
|
|
|
| |
Showing media titles in the playlist is pointless when sources are ill
tagged and media titles contain only garbage. Being able to opt for
file names at least gives us a choice in such cases.
|
|
|
|
|
|
|
| |
sub->sd can be destroyed and recreated when update_segment is called
inside a lock.
Fixes: f9918b53901db2fbc3cfc1be509a32d3ed89556a
|
|
|
|
|
| |
It's currently always a meaningless 1. Make it so it returns 0 is cmd
is NULL. Remove the unused return value from queue_cmd.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
92a9f11a0b4fda60c8880014be5920dcf3e95253 added locking for dec_sub.
At that time, because the lock was exposed to the outside world,
a recursive mutex was used. However, this is no longer true after
e9e883e3b2a64867aae014fb8a1416d0177fe493, when the public locking
functions were removed. This means that the lock is now private.
Unlike input.c, dec_sub already enforces said call hierarchy, so
combined with the aforementioned change, the lock is only ever
called once and never recursively. Thus the lock can be converted to
a normal mutex.
|
|
|
|
|
|
|
| |
These public functions should use locks to keep its usage
consistent with input.c.
Fixes: 024e0cd4c1405a41edd6a8b302ec6b747bc60ea3
|
|
|
|
|
|
| |
Previous commits made sure that the lock will never be called for more
than once for all public functions. Thus deadlock is impossible, so
recursive mutex is unneeded and can be converted to a normal mutex.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The absense of a call hierarchy between public and private functions
results in many unnecessary recursive locks: public functions require
locks, which are also called by other public and private functions in this
file. Fortunately, since the lock is private to this file, this situation
can be avoided by establishing a call hierarchy:
- Public functions must lock, and can only call private functions in
this file
- Private functions must not lock, and can only call private functions
in this file
- No function can call any public function in this file, the only
exception being mp_input_wakeup and mp_input_parse_cmd.
This arrangement ensures that there will be no locks more than necessary:
All public function calls will lock only once, and never recursively.
|
|
|
|
|
| |
This makes it easy to eyeball check the call hierarchy between public
and private functions.
|
|
|
|
|
|
|
| |
This is a public function, yet its access to ictx through
get_bind_section is not locked.
Fixes: 4614d432a8d21ab135af25a183f57efd5059bb62
|
| |
|
|
|
|
|
|
|
|
| |
Depending on the options:
For AV_CODEC_ID_ARIB_CAPTION this allows using bitmap output.
For AV_CODEC_ID_DVB_TELETEXT this allows using text output.
Fixes: #13471
|
|
|
|
| |
Also set teletext page while at it.
|
|
|
|
| |
Will be useful for future commits.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 36d5b5261282dd964f80cd2bb04bb53a7c6d895b.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--stop-playback-on-init-failure=no is documented to continue playback in
audio-only mode if video init fails. However, this does not function
properly after a0804329927904fdeb70d9712ff23baaab161bb4: because video
is initialized first, if video init fails, ao_chain is still null.
As a result, !(mpctx->vo_chain || mpctx->ao_chain) is true, a playback
error is raised, so the playback ends and audio does not play.
Fix this by reverting that change, so it checks the tracks instead.
Fixes: a0804329927904fdeb70d9712ff23baaab161bb4
|
|
|
|
|
|
|
|
| |
Turns out that adding more medatata like HDR10+ and Dolby Vision would
produce a lot of duplication and it is better to centralize it around
the track-list property.
Fixes: e720159f72be2a816db849acb286f36a1ac4622b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the player is paused, switching subtitle track requires us to read
subs packets for an indefinite amount of time in order to actually
display the subtitles. The problem with this is that it puts a blocking
loop in the play thread which can be slow in cases where it takes a long
time to fetch the subtitle (e.g. over a network).
9e27b1f523071db184443d78f7144cb599dd0829 alleviates this when a pause
happens because of buffering, but it's not complete. One could encounter
this if the user pauses the video first manually and then switches the
subtitle track.
To solve this better, make it so the loop has a time out (totally
arbitrary number) so the player isn't blocked forever. If subtitles are
not fetched within that time, we flag the track and try again later in
the playloop.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Section 12 of Matroska Media Container Format Specifications says:
If a BCP 47 Language Element and an ISO 639-2 Language Element are used
within the same Parent Element, then the ISO 639-2 Language Element MUST
be ignored and precedence given to the BCP 47 Language Element.
Fixes: #8144
|
|
|
|
| |
For less formal questions GitHub discussions should be used instead.
|
|
|
|
|
|
| |
May be interesting information for users.
Fixes: #13839
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adds support for extracting codec profile. Old properties are redirected
to new one and removed from docs. Likely will stay like that forever as
there is no reason to remove them.
As a effect of unification of properties between audio and video,
video-codec will now print codec (format) descriptive name, not decoder
long name as it were before. In practice this change fixes what docs
says. If you really need decoder name, use the `track-list/N/decoder-desc`.
|
|
|
|
| |
Fixes: 895f40e150d4 ("wayland: only perform a rescale if window is on one output")
|
|
|
|
| |
Fixes #13872
|
|
|
|
|
|
|
| |
The protocol strongly implies that this only happens when the value
changes, and it's also what you would naturally expect. But maybe it's
worth guarding this in cause for some reason the same value twice in a
row happens.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mpv window overlapping multiple outputs with different scale values
can result in some weird behavior when dragging it from one monitor to
another one. This is due to the way some compositors implement
preferred_scale or preferred_buffer_scale (integer scale equivalent).
Depending on the scale values, mpv window has to be resized to match the
new scaling value (due to fractional scaling requiring a viewport). This
can cause the window to become smaller and no longer overlap the monitor
you were just trying to drag it to. Repeat this and the window will
become smaller and smaller. Depending on the layout, the reverse can
also happen (the window becomes larger). This can cause additional
events to fire as the preferred_scale value may change again which does
more weird things.
It seems kwin is not affected by this because their implementation of
preferred_scale sends the event only if the window is fully on the new
monitor. Honestly, this is probably more logical anyway but we should at
least deal with the other implementations better. Try to deal with it by
reworking scaling changes so they only occur when the mpv window is
fully on one monitor. If we get a preferred_scale event and there is an
overlap, save it as a pending change to be performed on the next
surface_enter or surface_leave event (whichever results in there being
only one monitor. Some weird rendering glitches can still happen during
overlap but this makes it usable again.
|
|
|
|
| |
This case will work fine, even if those are explicitly set.
|