diff options
author | wm4 <wm4@nowhere> | 2019-01-05 08:52:41 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-09-19 20:37:04 +0200 |
commit | 390772b58f180c3e74f370bdfc7521de1d6822b4 (patch) | |
tree | 6212c77ae9e5aa60816501b2089ae4df3e210534 /VERSION | |
parent | ebf183eeec388d87a19415ee01970b21b6ef6832 (diff) | |
download | mpv-390772b58f180c3e74f370bdfc7521de1d6822b4.tar.bz2 mpv-390772b58f180c3e74f370bdfc7521de1d6822b4.tar.xz |
demux_timeline: report network speed of slave connections
demux_timeline doesn't do any transport accesses itself. The slave
demuxers do this (these will actually access the stream layer and
perform e.g. network accesses). As a consequence, demux_timeline always
reported 0 bytes read, and network speed display didn't work.
Fix this by awkwardly reporting the amount of read bytes upwards. This
is not very nice, and requires explicit calls whenever the slave "might"
have read data.
Due to the way the reporting is done, it only works if the slaves do not
run demuxer threads, which makes things even less nice. (Fortunately
they don't anyway, because it would be a waste of resources.) Some
identifiers contain the word "hack" as a warning.
Some of the stupidity comes from the fact that demux.c itself resets the
stats randomly in order to calculate the bytes_per_second value, which
is useless for a slave, but of course is still done, because demux.c
itself is not aware of whether it's on the slave or top-level layer.
Unfortunately, this must do.
In theory, the demuxer thread/cache layer should be separated from
demuxer implementations. This would get rid of all the awkwardness and
nonsense. For example, the only threading involved would be the caching
layer, completely separate from demuxers themselves. It'd be the only
thing calculates speed rates for the player frontend, too (instead of
doing it for each demuxer, even if unused).
Diffstat (limited to 'VERSION')
0 files changed, 0 insertions, 0 deletions