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
|
2020-04-10 22:20:02 +00:00
|
|
|
4 Internal stuff (scroll)
|
|
|
|
==== ==================
|
|
|
|
|
|
|
|
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
|
|
|
==== ==================
|
|
|
|
|
|
|
|
Font
|
|
|
|
~~~~
|
|
|
|
|
|
|
|
For optimal visual experience, a font with support for many font weights and
|
|
|
|
monospaced digits is recommended. By default, the open source font
|
|
|
|
`Source Sans Pro <https://github.com/adobe-fonts/source-sans-pro>`_ is used.
|
|
|
|
|
|
|
|
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_oneshot``
|
|
|
|
Default: i
|
|
|
|
``key_toggle``
|
|
|
|
Default: I
|
|
|
|
|
|
|
|
Key bindings to display stats.
|
|
|
|
|
|
|
|
``key_page_1``
|
|
|
|
Default: 1
|
|
|
|
``key_page_2``
|
|
|
|
Default: 2
|
2019-10-26 20:24:57 +00:00
|
|
|
``key_page_3``
|
|
|
|
Default: 3
|
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
|
|
|
``key_page_4``
|
|
|
|
Default: 4
|
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.
|
|
|
|
|
|
|
|
``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.
|
|
|
|
|
|
|
|
``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``
|
|
|
|
Default: Source Sans Pro
|
|
|
|
|
|
|
|
Font name. Should support as many font weights as possible for optimal
|
|
|
|
visual experience.
|
|
|
|
|
|
|
|
``font_mono``
|
|
|
|
Default: Source Sans Pro
|
|
|
|
|
|
|
|
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
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
A different key binding can be defined with the aforementioned options
|
|
|
|
``key_oneshot`` and ``key_toggle`` but also with commands in ``input.conf``,
|
|
|
|
for example::
|
|
|
|
|
|
|
|
e script-binding stats/display-stats
|
|
|
|
E script-binding stats/display-stats-toggle
|
|
|
|
|
|
|
|
Using ``input.conf``, it is also possible to directly display a certain page::
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
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
|
|
|
|
at the JS side has an overhead. It can be enabled by exporting the env var
|
|
|
|
``MPV_LEAK_REPORT=1`` before starting mpv, and will increase JS memory usage.
|
|
|
|
|
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).
|