It is unclear why this should be recommended. If it were recommended it
would be the default. The consensus is that centered justification looks
better.
Document more shared fields with input.get().
I originally omitted them because they didn't seem useful for
input.select(), but now opened can be used to override keybindings, and
default_text = "'" can be used to default to exact search (which I do
for history in my build).
closed, default_text and cursor_position may be used to remember the
last input line for the next call.
If you set file-local-options/foo at runtime and run playlist-play-index
current or playlist-play-index $current_pos, file-local-options/foo is
reset. Add a flag to make it preserve file-local-options.
The advantage of this change is that it allows binding Ctrl+r set
file-local-options/start ${=time-pos}; playlist-play-index current yes
to reload the current file while preserving all options, independently
of --no-config, --watch-later-options or --reset-on-next-file, and
without writing watch later files to disk. It also preserves
file-local-options set on the CLI unlike loadfile.
most of the time not doing so will still work since ffmpeg has
some heuristics in place to detect if the url is percent encoded
already or not. but these heuristics are not foolproof and so
document this quirk explicitly.
Previously, it was impossible to generate a list of completions for an
`input.get()` request asynchronously, as the values had to be returned
by the callback function.
This commit provides a way to send completions asynchronously by passing
a second argument to the complete callback; a function which can be
passed the return values to respond to the complete event.
The optimal way would be to use custom rate based on telecine cadence,
but it's not supported by any driver in practice. So instead, allow
driver to field match and output with duplicated frames, which can be
removed using decimate filter.
Note that in practice all GPU vendors uses single video processor for
all deinterlacing, so IVTC will be done even if mode is not explicitly
selected. At least the field matching part, because correct rate output
is not supported. The main difference is that when selecting more we
output at video frame rate, not field rate.
This was a typo. Although this changes the user option name, this
filter, especially this option, is so niche that I fix it without a
deprecation period.
This was a mistake. It's too situational and it's not worth complicating
the API and every mp.input client with it. It made some sense before I
implemented input.select() because you could use input.get() to input a
choice and validate it, but in general for input.get() clients it's
better to show an error with input.set_log() instead of adding new lines
to the log everytime. This is what e.g.
https://framagit.org/Midgard/mpv-subber/-/blob/master/subber.lua does.
So this is only marginally useful for REPL scripts that keep adding
lines to the log, and the only such scripts are commands.lua and my
lua-repl.lua. commands.lua never used it and I already removed it from
lua-repl.lua. Cloning all scripts in the wiki reveals that **nobody** is
using log_error(), confirming that it is safe to deprecate.
As per Samillion's suggestion, reduce the contrast between separators
and the background to match other context menus. Using the already
defined disabled_color works for this and seems to be what GTK and Qt
do at a glance.
Rebind MENU to show the context menu. Shift+F10 is also bound because it
is a standard context menu binding.
MENU is not added to restore-old-bindings.conf because it is uncommon.
Make select.lua parse menu.conf on the first vo-configured and fill
menu-data with the properties referenced in menu.conf change. This is
disabled in the libmpv profile.
This is done from select.lua to reuse functions to format the data and
retrieve key bindings.
There is also a script-binding that opens the correct context menu
depending on --load-context-menu.
While the context menu is scrollable, for the playlist it is better to
start from around the current entry rather than from the beginning, and
since menu-data has no way to specify where to start, when there are
more than 25 items playlist items this adds … entries that open the
scrollable console menu when clicked.
input-bindings is parsed to show the shortcuts bound to commands. Since
it is not observable, it just uses the bindings from the first time the
context menu is opened.
Multimedia and numpad keys are also not shown to reduce clutter.
The old Context Menu section of the docs is merged in the more detailed
context_menu.rst to not repeat the same information.
Add a default context menu definition in etc/menu.conf. It will be used
to populate the context menu.
The format is meant to be easily readable with just tabs as separators
and submenus denoted by indentation. It avoids complicating the builtin
input.conf like similar scripts do.
By not defining the shortcut keys in the builtin input.conf, menu
entries won't be associated to wrong shortcuts when the user's
input.conf changes key bindings without redefining the menu. Note that
external scripts don't have this issue.
I used 3+ spaces as separators at first but then realized that since we
have Windows users tabs will look better in editors with proportional
fonts like notepad, though it still won't be perfectly aligned depending
on the font. But I am still not sure what is better.
On a curious note, etc/menu.conf already existed in the past as mplayer
used to have a menu. git log -p etc/menu.conf will show commits from
2002 to 2011.
Before 17551b2d43 keep_open was needed to make nested mp.input calls.
Even after that change it is still better to pass it to not show the
console quickly closing and reopening to the user, so recommend it.
Co-authored-by: CogentRedTester <cogent.redtester@outlook.com>
This commit modifies the log methods in mp.input to always send the id
of the latest `input.get()` request with log entries.
Previously, the log methods applied to whichever input request happened
to be open when the log message was received. Even when scripts used
these methods correctly, there was the risk of sending a log to the
wrong log buffer if the active input request changed while the log
message was in transit; a race condition.
Now the id of the latest `input.get()` request is sent alongside the log
messages, preventing data races between scripts while also preventing
those logs from being discarded.
This commit ensures that `input.terminate()` can only close input
requests made by the same script, and prevents any in-transit events
for old input requests from being processed.
Previously, there was no way to guarantee that the input request being
terminated was the one intended; the asynchronous nature of the API
meant that it was always possible (though unlikely) that another client
may have activated its own input request while the termination request
was in transit.
This commit removes the race condition between different scripts calling
`input.terminate()` by sending the script name alongside the termination
message.
In addition, when a script overwrites one of its own input requests,
there may be incoming events still in transit. Some of these events may
have a decent chance of calling `input.terminate()` if they are
processed (e.g., `submit`). This commit avoids this issue by only
processing `closed` requests once a new `input.get()` request is made.
Before this commit, deinterlace=auto and deinterlace=yes had the same
exact behavior for d3d11 and vaapi, the only difference being that
`auto` would create/destroy the deinterlacing filter on every frame that
changed the deinterlace flag and with `yes`, we left that the
responsibility to determine whether to deinterlace or not to d3d11vpp
and vavpp and the filters were always inserted.
Inserting and removing filters on every frame the interlaced flag changes
is expensive and it will be more efficient to let the deinterlacing
filters handle this distinction instead.
With this change, `yes` works as it should: the filter is inserted
always and deinterlacing is forced regardless of the frame flag. `auto`
will insert the deinterlacing filter only when mpv sees the first
interlaced frame, and the filter will only deinterlace the frames marked
as interlaced. Note that perfect detection of interlaced frames is not
possible, and in such cases the user has to set `yes` manually.
One downside of this change is that we don't know if the filter is
actually deinterlacing or not, we can only guess that if the filter is
inserted and the frame is interlaced then it should be deinterlacing.
It's possible for it to fail for whatever reason, and it's also possible
future changes to ffmpeg (since bwdif implementation lives in ffmpeg),
might make the logic more complicated than this check. However, for now
this is good enough.
It's the future and well contributions of this nature aren't going to
disappear. Might as well address it in the contribute.md hope that maybe
a would-be vibe coder out there does a slightly better job before
sending anything our way.
We should have done this ages ago. These commands essentially consist of
a combination of a load action and whether or not playback should be
started. The old `-play` aliases are kept for backwards compatibility.
Bind Shift+LEFT, Shift+RIGHT, Shift+WHEEL_DOWN, Shift+WHEEL_UP,
WHEEL_LEFT, WHEEL_RIGHT to scroll the menu horizontally.
This lets you see long items that get clipped, like long history entries
and key bindings.
We don't know how many log lines wrap, so scrolling the log with page up
and down with wrapped lines would skip lines, and those are also already
bound to history navigation.
This therefore only implements scrolling of one item at a time. While
not perfect because when the item is wrapped it scrolls multiple lines,
it is usable.
The number of log lines kept in memory is increased from 100 to 10000.
Closes https://github.com/mpv-player/mpv/discussions/14718.
D3D11 only for now. Documentation says that only D3D11 and D3D12 is
supported, but it looks like Vulkan is possible too. But I realized this
after implementing this version. Vulan may be added later.
Fixes: #16613