I don't know why I didn't get it before but Lua's LSP now complains with
Compute `"Edition " .. (edition.id + 1)` first. You may need to add
brackets. [ambiguity-1].
Just move the parenthesis to make it happy.
osd_surface is a sync sub-surface of video_surface meaning that a commit
of osd_surface will not take effect until the next commit of
video_surface.
Some compositors (wlroots) do not implement sync sub-surface correctly,
meaning that the difference cannot be observed there. But it can easily
be seen on Jay and GNOME:
1. Open an mpv window.
2. Pause the video.
3. Enter the surface with the mouse.
Expected behavior:
1. The OSD shows up immediately.
Actual behavior:
1. Nothing happens for a few seconds.
2. The OSD shows up and immediately fades out.
This is because the fade-out commits cause the initial osd_surface
commit to become effective.
This reverts part of PR #15899 (commit dd6e3a0ece).
"Why is this even useful?": It's very useful for multi-disc playlists. Compare:
`mpv bd:///DISC{1..4}`
`mpv -\{ bd:// --bluray-device=DISC1 -\} -\{ bd:// --bluray-device=DISC2 -\} -\{ bd:// --bluray-device=DISC3 -\} -\{ bd:// --bluray-device=DISC4 -\}`
Basically just bits of a9d83eac40 that was
removed and ported to here. Not really smart but it seems like flushing
buffers during seek generally leads to better behavior and avoids some
errors. The additional stream_seek call that was being performed is
definitely bogus (will never work and spams errors). So that is skipped
for bd/dvd. SEEK_FORCE is no longer needed. Instead demux_disc calls
drop_buffers on the slave demuxer (i.e. lavf).
Need to shuffle some stuff around but it's pretty simple. Mute the
audio stream before the frame step and then unmute it when we're done.
It's exactly the same as the default play mode otherwise.
You probably wouldn't guess what this does from the name alone, but it
actually selects a range of tracks to play. It's slightly different than
using --start because it confines the range to just that track and you
cannot seek before it. The functionality is useful, but you can
accomplish exactly the same thing with --start and --end. Also the
implementation of the cdda option is weird because starting from a track
after 1 makes it impossible to seek before it. There's no reason to have
this when using the core option is simply better and works fine.
This is allowed but it's pretty weird. You'd end up typing something
like dvd:////dev/sr0 or cdda:///dev/sr0 (notice the differing amount of
/). Why is this even useful? Just use the matching --cdda-device option.
There's no need to have two ways to do the same thing here.
modal dialogs steal the key/mouse input and possibly eat corresponding
key up events when opening via key binding. this leads to key sequence
ends to not reported and key bindings not being triggered if no key up
event was triggered after closing the modal.
This is only needed for spawning main mpv process, there is no need to
spin CRT just to call main() and support basic memcpy.
Additionally adjust compilation flags to reduce the size of mpv.com.
This is the small binary using only kernel32 as dependecy now.
Stripped mpv.com built with clang 19.1.7 (x86_64-w64-windows-gnu)
Before:
text data bss dec hex filename
6982 7281 0 14263 37b7 mpv.com
After:
text data bss dec hex filename
1094 2894 0 3988 f94 mpv.com
Depending on compiler and options the size may vary. For example with
-flto and -Wl,-gc-sections it is:
text data bss dec hex filename
833 750 0 1583 62f mpv.com
but gc-sections were rejected as an default option before.
As a bonus add some error checking to this code.
No need for pointless prefix, print error directly. Don't use CRT
function. This will write only to console, but it's not meant to be
written to file anyway.
This adds --video-aspect-method=ignore to replace --video-aspect-override=0.
--video-aspect-override=0 and --video-aspect-override=-1 will no longer be
handled specially. For compatibility, 0 is mapped to always use ignore
and -1 is always mapped to always use container.
"no" is now the replacement for --video-aspect-override=-1, which is
internally remapped to -2 to avoid using a deprecated value.
This is poorly implemented and will break existing scripts which set
the value directly with double without a string value, like
mp.set_property_native, or if the value is set with add/multiply commands.
Revert this until a better solution is found.
This reverts commit cb91de2a34.
Maybe the xx version was different (probably not), but looking over this
code again it's pretty clear that there is a lot of unneeded
complication. There's no need to keep track of the image description,
creator params, etc. globally. This can all be passed around on the fly.
Also, reset_color_management was redundant because it would execute on
reconfig and also on the first draw after the reconfig. We don't need
both so delete the reconfig path. Collapse the various color functions
into one simple "set_color_management" and let the wayland listeners do
all the object destroying for us.
343a5fd345 killed all mmal hardware
decoding, but there was still some junk lying around. There's
IMGFMT_MMAL still, but that's harmless to keep around.
I started doing this in f594482451 for
protocol objects that were newer than the lowest version, but I can't
remember why (some waf-related reason?). This wasn't even followed for
other PRs merged recently like ext-data-control and color-management.
Anyways, it's not needed and works fine if you're on wayland-protocols
1.31 so stop doing this void weirdness.
Previously stats_time_start first sampled cpu-time and then real-time,
while stats_time_end sampled them in reverse order.
This resulted in real-time delta values being possibly a bit smaller
than the respective cpu-time deltas, which could become meaningful if
the start/end durations are consistently very short and very frequent.
In one test case (measuging the time spent at the event loop of
a script which spins on zero timeouts), this resulted in accumulated
real-time value of ~230ms per second, with a respective cpu-time
values of ~500ms. This should not be possible with single thread load.
Now start and end sample the values at the same order, so that it
balances on average. Each start/end delta now includes overhead of one
of each sample type, and excludes one of each sample type on average.
With the test case above, it's now 490 +-1 ms for both.
(the other 510ms real-time are at the excluded mpv_wait_event calls
and the unmeasured-overhead-parts of stats_time_start/end).
This fixes a bug where if stats reset happened after stats_time_start
and before stats_time_end, then the next reported cpu-time value of
that measurement was from the thread startup.
The long version:
stats resets the time-accumulated values if more than two seconds
ellapsed since last poll.
The reset keeps the elements, but makes them as if no measurement was
yet taken, so that they don't show up at new reports until a new
measurement is taken.
While the events and (untimed) cpu are reset, the timed-cpu value
was only partially reset - the values are reset but the indication
that the element is empty was not enough for stats_time_end.
So when reset happened between start/end calls, stats_time_end was
entered eventhough it shouldn't have, but with reset cpu-time value
it calculated the time since the thread's startup, hence this bug.
Further polls were ok, because they are of the delta since the
previous poll. But at the next reset it happened again.
Now the cpu-value is reset correctly, which fixes this bug.
stats_time_start and stats_time_end accumulate real-time and cpu-time
between these calls, but the total was only updated on stats_time_end.
This resulted in two issues:
- Inaccurate measured value if a report (read the perf-info property)
happened between start/end. No biggie because it's OK on average and
typically each start/end duration is quite smaller than the interval.
- If the start/end duration is bigger than the interval, then one or
more intervals had a report value (delta) of 0, and then one report
with a value bigger than the interval - which shouldn't be possible.
This commit effectively does end+start at the report time for ongoing
timed measurements, so that the report accounts for them too.
Doing end+start at the report required two more changes:
Store the element type (VAL_TIME) at stats_time_start rather than at
the end. Otherwise if the report happens after the first start but
before the first end, then the type is not yet set and the element
is skipped at the report (bypassing the end+start).
Store the thread id at the element. start/end measure the cpu-time at
the current thread so they used pthread_self(), but with the report
usually running on a different thread, it needs the thread id for the
measurement. Measuring cpu-time from a different thread is OK, and
already happens with VAL_THREAD_CPU_TIME elements during the report.
While at it, stats_time_end now uses the thread id which was stored on
start instead of using pthread_self(). This also serves as a general
protection against measuring start/end from different threads, which
would yield generally meaningless results anyway. In mpv all the
start/end calls for the same element are at the same thread.
On Windows and any other platform where cpu-time is unsuported,
previously the cpu-time was reported as 0, and now it's omitted
(at the perf-info property native value).
Code which process this report, like stats.lua, could not distinguish
between 0 which was due to unsupported platform, and "real" 0 which
indicates zero cpu activity in this poll-period.
In stats.lua this resulted in a whole lot of empty cpu graphs,
including one for every loaded script.
Now cpu-time is excluded from the report on unsupported platforms.
Real-time is obviously still being reported where requested.
Implementation wise, this is slightly hacky, by literally only
excluding the cpu-time nodes from the report itself, while keeping
all the other cpu-tinme code intact.
A more correct solution might be to identify support at compile
(configure) time, and no-op the relevant code if needed.
However, stats.c is already hacky in parts, and there's no real cost
to keeping the code active even if the result is excluded at the
report, and it's also way simpler and less bug prone. So be it.
