diff options
author | wm4 <wm4@nowhere> | 2020-04-10 00:50:23 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-04-10 00:52:41 +0200 |
commit | 437a46d443eac95ceeff174ce3d5b4bdd42f1834 (patch) | |
tree | 8d4d59f34dade2f4ed9d0e5fed34112f0971a13f /TOOLS/mpv-osd-symbols.sfdir/uniE106.glyph | |
parent | c3b2e7ec07241a531e0ff376c19a0b6b50547224 (diff) | |
download | mpv-437a46d443eac95ceeff174ce3d5b4bdd42f1834.tar.bz2 mpv-437a46d443eac95ceeff174ce3d5b4bdd42f1834.tar.xz |
filter: reduce redundant re-iterations
When the player core requests new frames from the filter, this is called
external/recursive filtering, which acts slightly differently from when
filters request new data internally. Mainly this is so the external user
doesn't have to call mp_filter_graph_run() just to get a frame. This
causes a number of complications, and the short version is that until
now, mp_filter_graph_run() has unnecessarily returned true in the
current common case, which made the playloop run too often for no
reason.
The problem is that when a mp_pin is read externally, updating the same
mp_pin during recursive filtering flagged external_pending when the
result was written, which made mp_filter_graph_run() return true, which
made the playloop call mp_filter_graph_run() again. This is redundant
because the caller is obviously checking the new state of the mp_pin
immediately.
The only situation in which external_pending really must be set is if
_another_ pin is changed. In theory, we could also unset it if the set
of "external" pins that are not in a signaled state becomes empty, but
we don't track that in a convenient way.
This commit removes the redundant signaling, and avoids running the
playloop an additional time for each video and audio frame (as it
actually was planned from the beginning, but duh).
Diffstat (limited to 'TOOLS/mpv-osd-symbols.sfdir/uniE106.glyph')
0 files changed, 0 insertions, 0 deletions