mirror of
https://github.com/mpv-player/mpv.git
synced 2024-09-20 12:02:23 +02:00
5c0a626dee
Until now, the following could happen: if you set a 1GB forward cache, and a 1GB backward cache, and you opened a 2GB file, it would prune away the data cached at the start as playback progressed past the 50% mark. With this commit, nothing gets pruned, because the total memory usage will still be 2GB, which equals the total allowed memory usage of 1GB + 1GB. There are no explicit buffers (every packet is malloc'ed and put into a linked list), so it all comes down to buffer size computations. Both reader and prune code use these sizes to decide whether a new packet should be read / an old packet discarded. So just add the remaining free "space" from the forward buffer to the available backward buffer. Still respect if the back buffer is set to 0 (e.g. unseekable cache where it doesn't make sense to keep old packets). We need to make sure that the forward buffer can always append, as long as the forward buffer doesn't exceed the set size, even if the back buffer "borrows" free space from it. For this reason, always keep 1 byte free, which is enough to allow it to read a new packet. Also, it's now necessary to call pruning when adding a packet, to get back "borrowed" space that may need to be free'd up after a packet has been added. I refrained from doing the same for forward caching (making forward cache use unused backward cache). This would work, but has a disadvantage. Assume playback starts paused. Demuxing will stop once the total allowed low total cache size is reached. When unpausing, the forward buffer will slowly move to the back buffer. That alone will not change the total buffer size, so demuxing remains stopped. Playback would need to pass over data of the size of the back buffer until demuxing resume; consider this unacceptable. Live playback would break (or rather, would not resume in unintuitive ways), even normal streaming may break if the server invalidates the URL due to inactivity. As an alternative implementation, you could prune the back buffer immediately, so the forward buffer can grow, but then the back buffer would never grow. Also makes no sense. As far as the user interface is concerned, the idea is that the limits on their own aren't really meaningful, the purpose is merely to vaguely restrict the cache memory usage. There could be just a single option to set the total allowed memory usage, but the separate backward cache controls the default ratio of backward/forward cache sizes. From that perspective, it doesn't matter if the backward cache uses more of the total buffer than assigned, if the forward buffer is complete. |
||
|---|---|---|
| .. | ||
| cache.c | ||
| cache.h | ||
| codec_tags.c | ||
| codec_tags.h | ||
| cue.c | ||
| cue.h | ||
| demux_cue.c | ||
| demux_edl.c | ||
| demux_lavf.c | ||
| demux_libarchive.c | ||
| demux_mf.c | ||
| demux_mkv_timeline.c | ||
| demux_mkv.c | ||
| demux_null.c | ||
| demux_playlist.c | ||
| demux_raw.c | ||
| demux_timeline.c | ||
| demux.c | ||
| demux.h | ||
| ebml.c | ||
| ebml.h | ||
| matroska.h | ||
| packet.c | ||
| packet.h | ||
| stheader.h | ||
| timeline.c | ||
| timeline.h | ||