| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
I think that makes more sense.
And also remove the graph from the total cache usage, since that wasn't
very interesting. So there's still a total of 2 graphs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
| |
The new code is pretty much equivalent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more or less a minimal hack to make _some_ text measurement
functionality available to scripts. Since libass does not support such a
thing, this simply uses the bounding box of the rendered text.
This is far from ideal. Problems include:
- using a bitmap bounding box
- additional memory waste and/or flushing caches
- dependency on window size
- odd small deviations with different window sizes (run osd-test.lua and
resize the window after each timer update; the bounding boxes aren't
adjusted in an overly useful way)
- inability to query the size _after_ actual rendering
But I guess it's a start. Since I'm aware that it's crap, add a threat
to the manpage that this may be changed/removed again. For now, I'm
interested whether anyone will have use for it in its current form, as
it's an often requested feature.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Much more verbose, but on the other hand format_note is useless for the
alphabetic site with fragmented DASH streams.
|
|
|
|
|
| |
"format_note" normally contains a semi-informative description of the
format. But some extractors, confusingly, have it in the "format" field.
|
|
|
|
|
| |
E.g. soundcloud. While it still worked, not having the audio codec was
pretty annoying.
|
|
|
|
|
|
| |
This was obviously nonsense. In Lua 5.1 this appeared to work correctly,
but it really turned "\." into "." (making the pattern accept any
character). The proper way is using "%" for escaping.
|
|
|
|
| |
Well, didn't help much in the case I was interested it.
|
| |
|
|
|
|
| |
Should not be needed anymore. In fact, it's probably dangerous.
|
|
|
|
|
|
|
|
|
| |
In all_formats mode, we've ignored what --ytdl-format did so far, since
we've converted the full format list, instead of just the formats
selected by youtube-dl.
But we can easily restore --ytdl-format behavior: just mark the selected
tracks as default tracks.
|
|
|
|
|
| |
This was done for each media type, so muxed tracks had it twice, which
logged a dumb warning. Move it out of the per-media type loop.
|
|
|
|
|
| |
I think this is unnecessary, and at worst done by youtube-dl itself
(didn't check).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vbr and abr are the video and audio bitrates. Sometimes there is a weird
mix of any of them available, but in these cases, it's not good to fall
back to tbr if a specific track has no vbr/abr.
For example, the alphabetic site provides tbr only for the muxed
fallback stream, but using tbr would make the primitive mpv hls_bitrate
selection pick the compatibility stream for audio, because it appears to
have a higher bitrate than the other audio-only streams (because the
bitrate includes video). So we must not use tbr in this case.
On the other hand, formats coming from youtube-dl HLS master playlist
use will only have tbr set.
So as a heuristic, use the tbr only if it's the only bitrate available
in any track entry.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think the skip_muxed option was overlay useful. While it was
nice to filter out the low quality muxed versions (as it happens on the
alphabetic site, I suspect it's compatibility stuff), it's not really
necessary, and just makes for another tricky and rarely used
configuration option. (This was different before muxed tracks were also
delay-loaded, and including the muxed versions slowed down loading.)
Add the force_all_formats option instead, which handles the HLS case.
Set it to true because they are also delay-loaded now, and don't slow
down startup as much.
|
|
|
|
|
|
| |
(Or if it's about HLS, just "muxed"/multiplexed streams.)
This only affects all_formats=yes,skip_muxed=no modes.
|
|
|
|
|
|
| |
If all streams were delay loaded, there was actually no duration present
at all in the EDL metadata. So the length was considered unknown by the
player frontend.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See manpage additions. We would have to extend delay_open to support
multiple sub-tracks (for audio and video), and we'd still don't know (?)
whether it might contain more than one stream each (thinking of HLS
master streams). And if it's a true interleaved file (such as a "normal"
mp4 file provided as fallback for more primitive players), we'd either
have to signal such "bundled" tracks, or waste bandwidth.
This restructures a lot. The if/else tree in add_single_video for format
selection was a bit annoying, so it's split into separate if blocks,
where it checks each time whether a URL was determined yet.
|
|
|
|
| |
It even has a typo.
|
|
|
|
| |
If available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a "format" has both audio and video codec set, it might contain both
audio and video. all_format assumes that each format is just a quality
variant containing a single track.
This seems to happen with sites that provide a HLS master URL.
youtube-dl tends to "butcher" it, and the result isn't very ideal. I
guess HLS "renditions" simply don't map well to youtube-dl's output
format and what mpv expects. Playing master HLS directly is also less
than ideal, because of libavformat's stupid probing.
Fix this by not using the delay-opening mechanism if it appears like we
detected such a case. Add a metadata override to set the track titles to
"muxed-N", to indicate that they form a single unit. (Mostly helpful for
testing.)
|
|
|
|
|
| |
Shouldn't have any consequences. Probably makes the user-visible order
more stable.
|
|
|
|
|
|
|
|
|
| |
Pretty worthless I guess. I only tested one site (and 2 videos), it's
somewhat likely that it will break with other sites. Even if you leave
the option disabled (the default).
Slightly related to #3548. This will allows you to use the bitrate
stream selection mechanism, that was added for HLS, with normal videos.
|
|
|
|
| |
Might be helpful for... whatever.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uses the infrastructure added in the previous commits. This is
admittedly a bit weird (constructing EDL URLs and such). But on the
other hand, adding this as "first class" mechanism directly to the
sub-add command or so would increase weirdness and unexpected behavior
in other places, or at least that's what I think.
To reduce confusion, this goes through the effort of mapping the webvtt
codec, so it's shown "properly" in the codec list. Without this it would
show "null", but still work. In particular, any non-webvtt codecs should
still work if libavcodec supports it.
Not sure if I should remove the --all-subs hack from the code. But I
guess it does no harm.
|
|
|
|
| |
Avoids an additional property access; see previous commit.
|
|
|
|
| |
Now keypad enter actually works.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While mpv normally uses the text a key produces (as opposed to physical
key mappings), this is different with the keypad. This is for the sake
of making it possible to distinguish between these keys and the normal
number keys on the left side of a full size keyboard.
There were complaints that the keypad doesn't interact with console.lua,
so manually map them. This ignores numlock (behaves as if it's always
on), and maps KP_DEC to "." (even though it's mapped to "," on some
keyboards). The /*-+ keys produce ASCII on mpv (at least with X11) as an
inexplicable inconsistency, so there are no mappings for these.
Fixes: #7431
|
|
|
|
|
|
|
| |
The script was set up to only call on_update when the changelist
was non-empty. However, since the size operator does not operate
on dicts, it always returned 0 (which is truthy), thus on_update
would always be called when the script-opts property changed.
|
|
|
|
|
|
| |
When switching between having a video visible or not,
stats.lua now picks up the required formatting changes
for the cache stats page to display correctly.
|
|
|
|
|
|
|
|
| |
this deprecates the old cocoa backend only option and moves it to the
general macos ones. add support for the new option in the cocoa-cb
layer creation and use the new option in the olde cocoa backend.
Fixes #7272
|
|
|
|
|
|
|
|
| |
Cache display updates, especially when it's bigger than few minute,
could have been be very infrequent to the point that one is not sure
if it updates at all.
Reduce the 10% change-threshold to 5% and add another threshold of 5s.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two improvements here:
1) Correct the right-side padding on the title box. This was messed
up previously because I was passing the title box width when I
should be passing the x coordinate. I've also increased the
spacing to separate the title from the window controls more
clearly.
2) I'ved added a mouse tracking area over the title bar so that the
osc doesn't disappear if you hover over the title box. This didn't
work previously because the input area only covers the actual
window controls. The implementation here is simplified in that
it's only a mouse area and not an input area. This is enough to
keep the osc visible, but it won't stop the mouse pointer
disappearing. Fixing that requires a full input area which, for
now, I will say isn't worth the effort.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a bit unintuitive today when you use the un-maximise control
while fullscreened. Depending on the VO in use, this might silently
change the maximise state without any visible effect, or it might
do nothing. It's less surprising if the control exits the fullscreen
state.
Note that the exact behaviour is still VO dependent. If the window
was maximised before being fullscreened, it might exit fullscreen
back to maximised or back to regular window mode.
I thought about trying to explicitly control that behaviour but
it makes the osc code weird and probably wouldn't work all the time.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not really great. But I think it's good enough to save someone
who's lost. Most importantly, it should become obvious _what_ the
console expects (input commands), and how to exit it.
Would be nice if we could show some documentation, or give a link to
documentation, but that's out of scope and/or not easy.
I considered implementing the "help" command as builtin command in
command.c. On the other hand, this could not show console.lua specific
help, so I implemented it in console.lua. The ad-hoc command parsing
(that sort-of mirrors mpv input command syntax) for the "help" command
is probably the worst part of this.
|
|
|
|
| |
As suggested by TheAMM and avih.
|
|
|
|
|
|
|
|
| |
It's deprecated. The new solution works almost exactly the same way
(since the still existing internal tick event triggers vsync-jitter
change command), though as far as API usage goes, it's somewhat
questionable. (The comment is meant to discourage anyone trying to copy
the idea for external scripts.)
|
|
|
|
|
|
| |
This affects behavior when using the "del" default key binding.
Sometimes, setting visibility to always did not draw it correctly. This
probably fixes it.
|
|
|
|
|
|
|
|
|
|
| |
A minority of users have expressed a dislike of hats, calling them
"cancer [that] don't belong in software" describing the people who add
them as "shitty circlejerks" and "chucklefuck."
While I personally disagree with those opinions, it's probably easier
to let them have it their way. For that reason this adds the option
`greenandgrumpy` to the osc, which allows users to disable the hat.
|
|
|
|
|
| |
This was incorrectly converted from the original C code. Change it to
what the original code used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libass uses integers for PlayResX/Y, so the osd-overlay command also
does. Lua (pre-5.3) does not have an integer type, but the command
interface makes a difference anyway. If you pass a Lua number with a
fractional part to an integer parameter (using mp.command_native()), it
will result in an error and complain about incompatible types.
I think that's fine, but since this behavior extends to
mp.set_osd_ass(), this is a compatibility problem.
Fix this by explicitly coercing the resolution parameters to integer
numbers.
|
|
|
|
|
|
|
|
| |
The main reason for this is just to make show the OSC always above
console.lua, instead of a random order.
(And this is also the only reason osc.lua was changed to the new API.
The old API could have been extended, but lets not.)
|
|
|
|
|
|
|
|
|
| |
This tries to avoid the update() call if nothing changed. This brings it
more into line with the old code (the osd-overlay command simply does
not skip the update if nothing changed). I don't know whether this
matters; most likely not. Normally, code should try to avoid redundant
updates on its own, so it's not the job of the command. However, for the
OSC we simply want to reduce the differences.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lua scripting has an undocumented mp.set_osd_ass() function, which is
used by osc.lua and console.lua. Apparently, 3rd party scripts also use
this. It's probably time to make this a public API.
The Lua implementation just bypassed the libmpv API. To make it usable
by any type of client, turn it into a command, "osd-overlay".
There's already a "overlay-add". Ignore it (although the manpage admits
guiltiness). I don't really want to deal with that old command. Its main
problem is that it uses global IDs, while I'd like to avoid that scripts
mess with each others overlays (whether that is accidentally or
intentionally). Maybe "overlay-add" can eventually be merged into
"osd-overlay", but I'm too lazy to do that now.
Scripting now uses the commands. There is a helper to manage OSD
overlays. The helper is very "thin"; I only want to force script authors
to use the ID allocation, which may help with putting multiple scripts
into a single .lua file without causing conflicts (basically, avoiding
singletons within a script's environment). The old set_osd_ass() is
emulated with the new API.
The JS scripting wrapper also provides a set_osd_ass() function, which
calls internal mpv API. Comment that part (to keep it compiling), but
I'm leaving it to @avih to finish the change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lua scripting implements key bindings by defining an input section with
all the bindings in it. Every add_key_binding() call ran a mpv command
to update this section. This caused a lot of spam at debug log levels.
Reduce the spam and more it efficient by batching updates into a single
mpv command when the script becomes inactive. This is pretty simple,
because there's already the concept of idle handlers.
This requires that the script actually goes to sleep, which might not
happen in various extremely bogus corner cases, such as polling the mpv
message queue with active waiting. Just don't do that.
|
|
|
|
|
|
|
|
|
|
| |
During the 12th month (checked during script initialization), draw a Santa hat
on top of the idle message's logo.
Slightly refactors and optimizes the drawing process as well: reorder original
logo layers and remove redundant holes in them, use a shared line prefix
to clear the style and set start position.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
This looks better if the ASS canvas size is used to scale according to
HiDPI factor (instead of font size).
|
|
|
|
|
| |
Looks awkward otherwise. This means that even if boxvideo is enabled,
nothing gets "boxed" if the OSC is set to auto-hide.
|
|
|
|