2017-10-09 15:30:41 +00:00
|
|
|
STATS
|
|
|
|
|
=====
|
|
|
|
|
|
|
|
|
|
This builtin script displays information and statistics for the currently
|
|
|
|
|
played file. It is enabled by default if mpv was compiled with Lua support.
|
|
|
|
|
It can be disabled entirely using the ``--load-stats-overlay=no`` option.
|
|
|
|
|
|
|
|
|
|
Usage
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
|
|
The following key bindings are active by default unless something else is
|
|
|
|
|
already bound to them:
|
|
|
|
|
|
|
|
|
|
==== ==============================================
|
|
|
|
|
i Show stats for a fixed duration
|
|
|
|
|
I Toggle stats (shown until toggled again)
|
|
|
|
|
==== ==============================================
|
|
|
|
|
|
|
|
|
|
While the stats are visible on screen the following key bindings are active,
|
|
|
|
|
regardless of existing bindings. They allow you to switch between *pages* of
|
|
|
|
|
stats:
|
|
|
|
|
|
|
|
|
|
==== ==================
|
|
|
|
|
1 Show usual stats
|
2020-05-17 11:55:38 +00:00
|
|
|
2 Show frame timings (scroll)
|
2019-10-26 20:24:57 +00:00
|
|
|
3 Input cache stats
|
2021-07-16 08:17:50 +00:00
|
|
|
4 Active key bindings (scroll)
|
2021-07-16 07:33:46 +00:00
|
|
|
0 Internal stuff (scroll)
|
2020-04-10 22:20:02 +00:00
|
|
|
==== ==================
|
|
|
|
|
|
|
|
|
|
On pages which support scroll, these key bindings are also active:
|
|
|
|
|
|
|
|
|
|
==== ==================
|
|
|
|
|
UP Scroll one line up
|
|
|
|
|
DOWN Scroll one line down
|
2017-10-09 15:30:41 +00:00
|
|
|
==== ==================
|
|
|
|
|
|
|
|
|
|
Configuration
|
|
|
|
|
-------------
|
|
|
|
|
|
2017-12-13 17:37:42 +00:00
|
|
|
This script can be customized through a config file ``script-opts/stats.conf``
|
2017-10-09 15:30:41 +00:00
|
|
|
placed in mpv's user directory and through the ``--script-opts`` command-line
|
|
|
|
|
option. The configuration syntax is described in `ON SCREEN CONTROLLER`_.
|
|
|
|
|
|
|
|
|
|
Configurable Options
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
``key_page_1``
|
|
|
|
|
Default: 1
|
|
|
|
|
``key_page_2``
|
|
|
|
|
Default: 2
|
2019-10-26 20:24:57 +00:00
|
|
|
``key_page_3``
|
|
|
|
|
Default: 3
|
2021-07-16 08:17:50 +00:00
|
|
|
``key_page_4``
|
|
|
|
|
Default: 4
|
2021-07-16 07:33:46 +00:00
|
|
|
``key_page_0``
|
|
|
|
|
Default: 0
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Key bindings for page switching while stats are displayed.
|
|
|
|
|
|
2020-04-10 22:20:02 +00:00
|
|
|
``key_scroll_up``
|
|
|
|
|
Default: UP
|
|
|
|
|
``key_scroll_down``
|
|
|
|
|
Default: DOWN
|
|
|
|
|
``scroll_lines``
|
|
|
|
|
Default: 1
|
|
|
|
|
|
|
|
|
|
Scroll key bindings and number of lines to scroll on pages which support it.
|
|
|
|
|
|
2017-10-09 15:30:41 +00:00
|
|
|
``duration``
|
|
|
|
|
Default: 4
|
|
|
|
|
|
|
|
|
|
How long the stats are shown in seconds (oneshot).
|
|
|
|
|
|
|
|
|
|
``redraw_delay``
|
|
|
|
|
Default: 1
|
|
|
|
|
|
|
|
|
|
How long it takes to refresh the displayed stats in seconds (toggling).
|
|
|
|
|
|
|
|
|
|
``persistent_overlay``
|
2017-10-12 19:28:24 +00:00
|
|
|
Default: no
|
2017-10-09 15:30:41 +00:00
|
|
|
|
2017-10-12 19:28:24 +00:00
|
|
|
When `no`, other scripts printing text to the screen can overwrite the
|
|
|
|
|
displayed stats. When `yes`, displayed stats are persistently shown for the
|
2017-10-09 15:30:41 +00:00
|
|
|
respective duration. This can result in overlapping text when multiple
|
|
|
|
|
scripts decide to print text at the same time.
|
|
|
|
|
|
2023-08-28 21:39:34 +00:00
|
|
|
``term_width_limit``
|
|
|
|
|
Default: -1
|
|
|
|
|
|
|
|
|
|
Sets the terminal width.
|
|
|
|
|
A value of 0 means the width is infinite, -1 means it's automatic.
|
|
|
|
|
|
|
|
|
|
``term_height_limit``
|
|
|
|
|
Default: -1
|
|
|
|
|
|
|
|
|
|
Sets the terminal height.
|
|
|
|
|
A value of 0 means the height is infinite, -1 means it's automatic.
|
|
|
|
|
|
2017-10-09 15:30:41 +00:00
|
|
|
``plot_perfdata``
|
2017-10-12 19:28:24 +00:00
|
|
|
Default: yes
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Show graphs for performance data (page 2).
|
|
|
|
|
|
|
|
|
|
``plot_vsync_ratio``
|
2017-10-12 19:28:24 +00:00
|
|
|
Default: yes
|
2017-10-09 15:30:41 +00:00
|
|
|
``plot_vsync_jitter``
|
2017-10-12 19:28:24 +00:00
|
|
|
Default: yes
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Show graphs for vsync and jitter values (page 1). Only when toggled.
|
|
|
|
|
|
2023-08-30 13:09:51 +00:00
|
|
|
``plot_tonemapping_lut``
|
2023-10-22 04:13:52 +00:00
|
|
|
Default: no
|
2023-08-30 13:09:51 +00:00
|
|
|
|
|
|
|
|
Enable tone-mapping LUT visualization automatically. Only when toggled.
|
|
|
|
|
|
2017-10-09 15:30:41 +00:00
|
|
|
``flush_graph_data``
|
2017-10-12 19:28:24 +00:00
|
|
|
Default: yes
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Clear data buffers used for drawing graphs when toggling.
|
|
|
|
|
|
|
|
|
|
``font``
|
2023-07-09 09:05:23 +00:00
|
|
|
Default: sans-serif
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Font name. Should support as many font weights as possible for optimal
|
|
|
|
|
visual experience.
|
|
|
|
|
|
|
|
|
|
``font_mono``
|
2023-07-09 09:05:23 +00:00
|
|
|
Default: monospace
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
Font name for parts where monospaced characters are necessary to align
|
|
|
|
|
text. Currently, monospaced digits are sufficient.
|
|
|
|
|
|
|
|
|
|
``font_size``
|
|
|
|
|
Default: 8
|
|
|
|
|
|
|
|
|
|
Font size used to render text.
|
|
|
|
|
|
|
|
|
|
``font_color``
|
|
|
|
|
Default: FFFFFF
|
|
|
|
|
|
|
|
|
|
Font color.
|
|
|
|
|
|
|
|
|
|
``border_size``
|
|
|
|
|
Default: 0.8
|
|
|
|
|
|
|
|
|
|
Size of border drawn around the font.
|
|
|
|
|
|
|
|
|
|
``border_color``
|
|
|
|
|
Default: 262626
|
|
|
|
|
|
|
|
|
|
Color of drawn border.
|
|
|
|
|
|
|
|
|
|
``alpha``
|
|
|
|
|
Default: 11
|
|
|
|
|
|
|
|
|
|
Transparency for drawn text.
|
|
|
|
|
|
|
|
|
|
``plot_bg_border_color``
|
|
|
|
|
Default: 0000FF
|
|
|
|
|
|
|
|
|
|
Border color used for drawing graphs.
|
|
|
|
|
|
|
|
|
|
``plot_bg_color``
|
|
|
|
|
Default: 262626
|
|
|
|
|
|
|
|
|
|
Background color used for drawing graphs.
|
|
|
|
|
|
|
|
|
|
``plot_color``
|
|
|
|
|
Default: FFFFFF
|
|
|
|
|
|
|
|
|
|
Color used for drawing graphs.
|
|
|
|
|
|
|
|
|
|
Note: colors are given as hexadecimal values and use ASS tag order: BBGGRR
|
|
|
|
|
(blue green red).
|
|
|
|
|
|
|
|
|
|
Different key bindings
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2021-07-21 06:13:23 +00:00
|
|
|
Additional keys can be configured in ``input.conf`` to display the stats::
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
e script-binding stats/display-stats
|
|
|
|
|
E script-binding stats/display-stats-toggle
|
|
|
|
|
|
2021-07-21 06:13:23 +00:00
|
|
|
And to display a certain page directly::
|
2017-10-09 15:30:41 +00:00
|
|
|
|
|
|
|
|
i script-binding stats/display-page-1
|
|
|
|
|
e script-binding stats/display-page-2
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
|
2021-07-16 08:17:50 +00:00
|
|
|
Active key bindings page
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Lists the active key bindings and the commands they're bound to, excluding the
|
2021-07-22 19:00:44 +00:00
|
|
|
interactive keys of the stats script itself. See also ``--input-test`` for more
|
2021-07-16 08:17:50 +00:00
|
|
|
detailed view of each binding.
|
|
|
|
|
|
|
|
|
|
The keys are grouped automatically using a simple analysis of the command
|
|
|
|
|
string, and one should not expect documentation-level grouping accuracy,
|
|
|
|
|
however, it should still be reasonably useful.
|
|
|
|
|
|
stats.lua: page 4 (keys): support help-like terminal printout
While --input-test is useful, and so is page 4 of stats, until now
there was no way to simply print the list in a help-like fashion.
This commit adds such printout, invoked by the script opt
stats-bindlist=yes, which uses the existing page 4 code. This prints
the list on startup and quits immediately - like any help page.
It's awkward to invoke compared to other help pages, and it does
require the stats page to be enabled (it is by default), however
it is a script-generated output, and currently there's no other
method to print a help page generated by a script.
The printout itself is performed using lua's io.write. While reliable,
it's not the standard way for mpv to print to the terminal.
Other possible printout methods are mp.msg.info - which also prints
"[stats]" prefix on each line (ugly), or forcing term-osd and setting
an osd-message which mpv will then print at the terminal - however
that's printed to stderr, and could also be subject to timing concerns
since we quit right afterwards.
In the future we can consider changing/integrating the invocation so
that mpv itself could print a help page generated by a script, thus
solving both the awkward invocation and printout-method issues.
2021-07-16 09:06:20 +00:00
|
|
|
Using ``--idle --script-opts=stats-bindlist=yes`` will print the list to the
|
|
|
|
|
terminal and quit immediately. By default long lines are shortened to 79 chars,
|
|
|
|
|
and terminal escape sequences are enabled. A different length limit can be
|
|
|
|
|
set by changing ``yes`` to a number (at least 40), and escape sequences can be
|
|
|
|
|
disabled by adding ``-`` before the value, e.g. ``...=-yes`` or ``...=-120``.
|
|
|
|
|
|
2021-07-16 08:17:50 +00:00
|
|
|
Like with ``--input-test``, the list includes bindings from ``input.conf`` and
|
2021-08-09 20:57:04 +00:00
|
|
|
from user scripts. Use ``--no-config`` to list only built-in bindings.
|
2021-07-16 08:17:50 +00:00
|
|
|
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
Internal stuff page
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Most entries shown on this page have rather vague meaning. Likely none of this
|
|
|
|
|
is useful for you. Don't attempt to use it. Forget its existence.
|
|
|
|
|
|
|
|
|
|
Selecting this for the first time will start collecting some internal
|
|
|
|
|
performance data. That means performance will be slightly lower than normal for
|
|
|
|
|
the rest of the time the player is running (even if the stats page is closed).
|
2020-04-08 23:07:12 +00:00
|
|
|
Note that the stats page itself uses a lot of CPU and even GPU resources, and
|
|
|
|
|
may have a heavy impact on performance.
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
|
|
|
|
|
The displayed information is accumulated over the redraw delay (shown as
|
|
|
|
|
``poll-time`` field).
|
|
|
|
|
|
|
|
|
|
This adds entries for each Lua script. If there are too many scripts running,
|
2020-04-10 22:20:02 +00:00
|
|
|
parts of the list will simply be out of the screen, but it can be scrolled.
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
|
|
|
|
|
If the underlying platform does not support pthread per thread times, the
|
|
|
|
|
displayed times will be 0 or something random (I suspect that at time of this
|
|
|
|
|
writing, only Linux provides the correct via pthread APIs for per thread times).
|
|
|
|
|
|
|
|
|
|
Most entries are added lazily and only during data collection, which is why
|
|
|
|
|
entries may pop up randomly after some time. It's also why the memory usage
|
|
|
|
|
entries for scripts that have been inactive since the start of data collection
|
|
|
|
|
are missing.
|
|
|
|
|
|
|
|
|
|
Memory usage is approximate and does not reflect internal fragmentation.
|
|
|
|
|
|
js: report scripts CPU/memory usage statistics
This can be viewed at page 4 of the internal stats display (i or I).
CPU time report is the same as at lua.c, but untested - doesn't seem
to work on windows - also not for lua.
TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats.
This also almost doubles the memory usage by js scripts.
For memory reporting, we don't have enough info by default, because
even when using a custom allocator, mujs doesn't report the old size
(on free or realloc) because it doesn't track this value, and as
a result we can't track the overall size.
Our option are either to track the size of each allocation on our own,
or use talloc which tracks this value.
However, using talloc for mujs allocations adds a considerable
overhead, and almost doubles(!) the overall memory used, because each
individual allocation includes a considerable talloc header, and mujs
does many small allocations.
So our solution is that by default we behave like previously - not
using a custom allocator with mujs, and stats does not display memory
usage for js scripts.
However, if the env var MPV_LEAK_REPORT is set to 1, then we use
a custom allocator with talloc and track/report memory usage.
We can't switch allocator at runtime, so an mpv instance either tracks
or doesn't track js scripts memory usage, according to the env var.
(we could use a property and apply it whenever a new script starts,
so that it could change for newly launched scripts, but we don't).
2020-04-11 00:56:12 +00:00
|
|
|
JS scripts memory reporting is disabled by default because collecting the data
|
2023-10-25 23:17:25 +00:00
|
|
|
at the JS side has an overhead and will increase memory usage. It can be
|
|
|
|
|
enabled by setting the ``--js-memory-report`` option before starting mpv.
|
js: report scripts CPU/memory usage statistics
This can be viewed at page 4 of the internal stats display (i or I).
CPU time report is the same as at lua.c, but untested - doesn't seem
to work on windows - also not for lua.
TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats.
This also almost doubles the memory usage by js scripts.
For memory reporting, we don't have enough info by default, because
even when using a custom allocator, mujs doesn't report the old size
(on free or realloc) because it doesn't track this value, and as
a result we can't track the overall size.
Our option are either to track the size of each allocation on our own,
or use talloc which tracks this value.
However, using talloc for mujs allocations adds a considerable
overhead, and almost doubles(!) the overall memory used, because each
individual allocation includes a considerable talloc header, and mujs
does many small allocations.
So our solution is that by default we behave like previously - not
using a custom allocator with mujs, and stats does not display memory
usage for js scripts.
However, if the env var MPV_LEAK_REPORT is set to 1, then we use
a custom allocator with talloc and track/report memory usage.
We can't switch allocator at runtime, so an mpv instance either tracks
or doesn't track js scripts memory usage, according to the env var.
(we could use a property and apply it whenever a new script starts,
so that it could change for newly launched scripts, but we don't).
2020-04-11 00:56:12 +00:00
|
|
|
|
stats: some more performance graphs
Add an infrastructure for collecting performance-related data, use it in
some places. Add rendering of them to stats.lua.
There were two main goals: minimal impact on the normal code and normal
playback. So all these stats_* function calls either happen only during
initialization, or return immediately if no stats collection is going
on. That's why it does this lazily adding of stats entries etc. (a first
iteration made each stats entry an API thing, instead of just a single
stats_ctx, but I thought that was getting too intrusive in the "normal"
code, even if everything gets worse inside of stats.c).
You could get most of this information from various profilers (including
the extremely primitive --dump-stats thing in mpv), but this makes it
easier to see the most important information at once (at least in
theory), partially because we know best about the context of various
things.
Not very happy with this. It's all pretty primitive and dumb. At this
point I just wanted to get over with it, without necessarily having to
revisit it later, but with having my stupid statistics.
Somehow the code feels terrible. There are a lot of meh decisions in
there that could be better or worse (but mostly could be better), and it
just sucks but it's also trivial and uninteresting and does the job. I
guess I hate programming. It's so tedious and the result is always shit.
Anyway, enjoy.
2020-04-08 22:27:54 +00:00
|
|
|
If entries have ``/time`` and ``/cpu`` variants, the former gives the real time
|
|
|
|
|
(monotonic clock), while the latter the thread CPU time (only if the
|
|
|
|
|
corresponding pthread API works and is supported).
|
