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.
Escape all messages in osc.lua, because other than the title they
weren't being escaped at all. If for example you did mpv foo.mp4
'{\fs50}bar.mp4' and script-message osc-playlist, it would just render
the second entry as bar.mp4 in big text.
The title was escaped partially, now the escaping is complete because:
- It escapes \. Backslashes at the end of the title are escaped instead
of being stripped, and \n, \N and \h are now printed verbatim. In
particular, "\\n" is no longer converted to space and is printed
verbatim instead which is more correct.
- Newlines ("\n", not the "\\n" escape sequence) are converted to spaces
instead of rendering them and messing up the text positioning within
the OSC.
- Spaces at the start are preserved.
Fixes#11209, fixes#11275.
mp.observe_property('foo', nil, ...) calls the handler at least 2 times
on each playlist change even when the property doesn't change. This is
dangerous because if you haven't read observe_property's documentation
in a long time this is easy to forget, and you can end up using it for
handlers that are computationally expensive or that cause unintended
side effects.
Therefore, this commit discourages its use more explicitly in the
documentation, and replaces its usages in scripts.
For console.lua, observing focused with type nil leads to calling
mp.osd_message('') when changing file while playing in the terminal with
the console disabled. I don't notice issues from this, but it's safer to
avoid it.
For playlist and track-list this doesn't really matter since they
trigger multiple changes on each new file anyway, but changing it can
avoid encouraging people to imitate the code.
One usage of none in stats.lua is kept because according to b9084dfd47
it is a hack to replicate the deprecated tick event.
When the mouse cursor is hovering over the (CSD) windowcontrols title,
the osc keeps displaying, but the cursor autohide isn't disabled like
other visible regions.
Fix this by disabling the cursor autohide in this region.
All other existing behaviors of the mouse cursor in this region
are unchanged, including triggering main window area input
and allowing VO dragging.
When hovering certain elements over the OSC, using the mouse wheel can
result in special commands (such as seeking, changing audio tracks,
etc.) Not everyone neccessarily wants this feature, so add an option to
make it possible to disable all of it. Maybe more fine-tuned control
would be more ideal, but probably not worth it. Fixes#13096.
I honestly don’t care either way but I also don’t believe this innocent
and cute hat is worth repeatedly having people show up on the issue
tracker to aggressively virtue signal and then shit-talk the project
elsewhere when their “concerns” are ignored and made fun of.
For the record, I approve of neither brand of childish nonsense.
If your workflow depends on December festivities, feel free to use an
alternative OSC implementation.
Fixes#13082 and #9548
For whatever reason, some of the lua code (particularly the osc and
ytdl_hook) is full of a bunch of stuff like if (foo), if not (foo ==
nil), etc. The parenthesis aren't needed in lua and actually just look
weird since nobody actually writes lua like this. You can see most of
the other conditionals are written normally. So cleanup the style to
match when the parenthesis clearly aren't doing anything. Not directly
related, but also add some spaces on a few math operations while we're
at it.
The default `z` of an overlay is 0, which is used by e.g. console.lua.
Having the idle logo at a `z` of 1000 means that it ends up above the
console (and anything that don't set a value higher then 1000).
It doesn't make sense for the idle logo to overshadow other things, so
put it at -1000 instead to prevent that.
0b4860248b added user-data which is
completely superior and makes this property obsolete. We've already had
one mpv release with the osc using user-data so drop this.
the osc currently allows for changing volume via scrolling when on top
of the volume icon. this does the same thing for the seekbar by allowing
seeking via scroll.
DVD/PGS are definitely not common, and ones that make use of the forced
subpictures flag even less so. For this button to be useful, the
subtitle track would need to be DVD or PGS, the track would need to make
use of the forced flag, the user would have to know what forced
subpictures are, and the user would need to have the preference of only
viewing forced subpictures on a subtitle. The function of this button is
too niche to be on the osc, if this behavior is desired the user can
simply bind a key in their input.conf. Moreover, this button only adds
confusion because there's no intuitive way to show what it does, and
there's no explanation for it anywhere in the manuals. osc real-estate
is quite limited as it is, so let's not waste any space on buttons with
highly questionable utility at best and confusing or bad UX at worst.
This ensures the spacing between forced-only sub toggle button and the
volume button matches the spacing between the volume and the fullscreen
button on bottombar/topbar layouts
Fixes: 945d7c1eda
Previously, we would have a button with empty string added to the layout
for non DVD/PGS subtitles. This would cause there to be an invisible
button present that would take up space and could still be clicked
despite being invisible when the current subtitle track was not DVD/PGS.
The idea was that the button would be invisible for regular subtitle
tracks, and be visible as "[ ]"/"[F]" for DVD/PGS subtitle tracks.
This commit modifies the bar and box layouts to only add this button if
the current subtitle track is DVD/PGS. This results in there no longer
being an invisible button, and also prevents it from taking up space.
The button is added to layout as before when the current subtitle track
is DVD/PGS, matching the same logic as before.
Currently, the osc will add a margin of (osc_height / 2) to the
deadzonesize for the window controls, the topbar and the bottombar,
i.e. when osc-deadzonesize=1, the osc will show up even if the cursor
is only hovering (osc_height / 2) pixels above or below it. This is not
what this option is supposed to do according to the manual, instead
osc-deadzonesize=1 should result in the osc only appearing when it is
directly hovered. The user can simply set osc-deadzonesize=0.9 or so if
such a margin is desired, instead make the option work as advertised by
removing this margin.
It should be noted that osc-layout=box does not share this behavior,
and it already works as advertised in the manual.
The idle logo could appear on the left side of the window for a split
second after starting.
That is because when osd dimensions can be reported as 0 at the very beginning.
Since the width gets calculated based on a fixed height and the aspect ratio,
which is 0, that results in a width of 0 until the next update.
Not sure when this actually started happening, but it's probably been
like this for years. Currently, the logic for the window-controls works
by simply checking if the osc is visible and then either enabling or
disabling the associated keybindings. The problem is that this can just
constantly spam mp.enable_keybindings/disable_key_bindings on every
single render call if the user disables the border at any point in time.
This does a lot of pointless work and also results in the logs being
spammed with lines like "disable-section". Clearly, this should just
work like the code for checking the input keybindings just above it.
Keep track of an internal state variable and check when it doesn't match
the osc visibility. In that case, we can then either enable or disable
the key bindings and just update the variable.
Generally, the hard-coded sizes used for the OSC elements are
comfortable regardless of the font used, but the timecode fields have
relatively many characters, and so are affected to a greater degree by
fonts with a wider or narrower average character width than expected.
This allow users to adjust the space reserved for the timecode fields to
compensate.
This is mainly for other user scripts that may conflict with the osc
logo in some way. Although it is possible to listen for
shared-script-properties, this has many edge cases that could easily pop
up. A user could want other OSC things to happen at the same time (say
osc-message). They just don't want the logo. The idlescreen option
disables all idlescreen related things (including the santa hat) if it
is set to "no". A new script message (osc-idlescreen) is also added so
users can easily toggle the value (passing "cycle" or just explictly
setting "yes" or "no"). Some more discussion on this is found in the
below github issues.
https://github.com/mpv-player/mpv/issues/10201https://github.com/CogentRedTester/mpv-file-browser/issues/55
If the player is started with --idle and the osc-tracklist script-message
is called then the tracks_osc table will be nil,
which caused the OSC to crash due to attempting to index a nil value.
This appears to be because the osc_tracklist variable is both
initialised and updated by (ultimately) the render() function, which
is not run when the player is idling.
Rather than mess with the existing OSC logic it's easier to either
add this single check, or alternatively to initialise the the tracks_osc
table somewhere before this.
This speeds up chapter name access while hovering the seekbar:
- Fetch the chapter-list property using observation rather than on
every render while hovering the bar. Property access, especially
with potentially lots of values (chapters), can be expensive-ish,
and can involve locking, so the less per-render the better.
- Sort the list once (on change) to simplify the iteration logic when
searching the chapter which matches the mouse position. It's still
O(N) (no binary search currently), but with less work.
The cached sorted list is stored at the state. While there are other
places which access this property and could use this cache, for now we
don't touch them, because they're not performance-critical (on init
for the chapter markers, on ch_{prev,next} button click for OSD).
Caching properties using observation instead of using mp.get_property
can indeed speedup other places too, but it should be part of a system
rather than implemented per-property. Maybe some day.
Previously OSD was always displayed on {ch,pl}_{next,prev} left-click,
and seekbar-hover-chapter was always enabled and with fixed format.
Now it can be controlled with:
- chapters_osd, playlist_osd: yes/no (only affects left-click).
- chapter_fmt: lua string.format template, or "no" to disable.
Fixes#4675
Before this commit, animation-end was handled at render(), however,
it's not called on idle, which resulted in state.anitype ~= nil, with
nothing to reset it during idle, which caused in an infinite tick()
loop (starts on first mouse move).
Now tick resets the animation on idle, and also, as a safety measure,
if we're past 1s after the animation deadline.
The safety measure is because the osc states are complex, and it's
easier to detect a "we really shouldn't be animating now" at tick()
itself rather than detecting the exact states where animation should
be reset. Generally, the safety mmeasure is not needed.
osc-visibility can already be changed at runtime via script-message
or other means, but until now there was no way to tell what the
current state is.
Now shared-script-properties/osc-visibility reflects this state.
It's output-only by the osc - changing it does not affect the osc.
Useful if a script wants to change osc-visibility temporarily, and
later restore to its original state.
There's no way to coordinate if more than one script wants to change
it, but that would be a hard problem to solve anyway, even if the
osc itself tried to coordinate such requests from different sources.
Previously tick() was ensured unconditionally only after mouse-move,
but there are other mouse-events which need re-rendering (tick), like
mouse-down (icons may get grayed-out) or mouse-up (icons may change).
For instance: mpv --pause --myclip.mkv
then move the mouse over the volume/mute OSC button, then - without
moving the mouse - press and release the left mouse button.
The osc was not re-rendered because it's paused and the mouse didn't
move, so the volume icon didn't get grayed-out when held down, and the
icon doesn't change on mouse-up (to reflect the new mute state).
Now both these changes are rendered correctly.
This is not a new issue, however, until the last commit - 96b246d
init probably didn't happen much (or at all) between mouse-down and
mouse-up, but after this commit, if there are chapters in a live-stream
then osc_init() is used to re-render the markers at the adjusted
position - which breaks the OSC buttons functionality if init happened
between mouse-down and mouse-up.
Commit 6abb7e3 updates the markers when the chapters change, but it
doesn't update their relative position at the bar when the duration
changes.
This means that adding chapters to a live stream would result in
corresponding chapter markers which were static while the duration
changed and thus their positions became incorrect over time until the
OSC was reinitialized.
This is fixed by observing the duration property if chapters are present
and reinitializing the OSC when the duration changes.
The live_markers user option, which determines whether the duration
property is observed when there are chapters, has been added in order to
allow disabling this behaviour as calling request_init() frequently
might have some impact on low-end systems.
The impact of request_init() on render() was measured to increase from
1-1.5 ms to 2-3 ms on a 2010 MacBook Air, while the impact was neglible
on a 2016 Surface Book (increasing only to an average of 1.4 ms from
1.3 ms for n=1500 render cycles).
The live_markers option is enabled by default.
When the OSC initializes, it checks whether the current video has
chapters, and if it does not, it disables its chapter functionality
(chapter buttons are grayed out and unusable, chapter indicators don't
show on the seek bar). If another script changed the chapter list
after the video has loaded, those changes would be ignored by the OSC
until some other event causes it to re-initialize, because it did not
observe the chapter list property. This is fixed by adding
observation of chapter-list alongside the other properties that
trigger re-initialization.
This fixes a bug where using boxvideo with showfullscreen=no or
showwindowed=no resulted in the margins not resetting when the OSC
wasn't visible.
For example, using:
script-opts=osc-visibility=always,osc-boxvideo=yes,osc-showfullscreen=no
and then going fullscreen would make the OSC disappear but the video
margins would remain. This is because boxvideo was missing a dependence
on the showfullscreen and showwindowed user options.
This is fixed by adding the corresponding conditions to update_margins()
and setting state.marginsREQ on fullscreen changes. update_margins() is
called on tick() if there's a margins update pending, which guarantees
the boxvideo margins are reset appropriately.
Clearing state.osd.data with an empty string at render_wipe() fixes an
issue where changing the OSC visibility from "never" directly to
"always" didn't immediately update the display when the player was
paused. This could be verified by starting the player with
`--script-opts=osc-visibility=always --pause` and then running
`script-message osc-visibility never` followed by
`script-message osc-visibility always`.
Removing the overlay without changing the contents meant the overlay
wouldn't update and display when enabled again until the fields changed
in some way (e.g. seeking, mousing over the OSC area, etc.). Clearing
state.osd.data before removal of the OSC makes sure set_osd doesn't
return on re-enable and instead displays the OSC immediately as the data
is now different.
render_wipe() is now also used when the OSC needs to be cleared at
tick() as using set_osd to clear it with an empty string did not call
state.osd:remove() which can allow cleanups related to bitmap memory
allocations etc.
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.
The message_timeout field was basically polled. But ever since the OSC
was changed to work more event based, this didn't quite work. It was
quite visible when switching subtitle or audio tracks while paused (and
with caching disabled, since the cache update triggered some extra
redrawing).
Fix by using a proper timer.
I noticed that changing tracks with the message call commented didn't
redraw properly either, but, uh, I guess the message is always triggered
anyway, and happens to take care of this.
The "seekbarkeyframes" option is now interpreted such if it's true, the
player default is used. Too lazy to make this a choice option or
whatever; the Lua option parser doesn't have support for that anyway.
Someone who cares can adjust this.
sunpenghao
Guido Cella
Kacper Michajłow
Dudemanguy
nanahi
HRXN
Niklas Haas
Mia Herkt
Christoph Heinrich
Mike Will
llyyr
NRK
Dave
rcombs
Harri Nieminen
Ryan Hendrickson
CogentRedTester
Cœur
Avi Halachmi (:avih)
Funami580
Sagnac
Retusthese
ossifrage
wm4