summaryrefslogtreecommitdiffstats
path: root/common/common.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-04-10 12:29:03 +0200
committerwm4 <wm4@nowhere>2020-04-10 12:37:12 +0200
commit40c8df8a542f62126c61a8fa5bf6518275ea9e05 (patch)
tree7476bfaf72985e97f4284bf5a54276729aa58b45 /common/common.c
parentc3f40e513b63bd484e431984135208106d13c2d3 (diff)
downloadmpv-40c8df8a542f62126c61a8fa5bf6518275ea9e05.tar.bz2
mpv-40c8df8a542f62126c61a8fa5bf6518275ea9e05.tar.xz
stream: actually drop unneeded buffer
The buffer can be larger than the normal size when "peeking" is used (such as done with some file formats, where a large number of bytes masy need to be "peeked" at the beginning, because FFmpeg). Once normal operation resumes, it's supposed to free this buffer again. Apparently this didn't happen as intended, because normal reading did have no way to discard back buffer before/while resizing the buffer. There's only a path for discarding the back buffer when actually reading. It seems like this unfortunately needs 2 code paths for discarding old data. Just put it into stream_resize_buffer(), where it's rather non-tricky (discarding can be done by adjusting the copy offset when moving data to the new allocation). The function now drops old data if it doesn't fit into the allocation. The caller must ensure that the new size is sufficient; the function signature changes only so the size of the implicitly guaranteed kept part can be checked with assert().
Diffstat (limited to 'common/common.c')
0 files changed, 0 insertions, 0 deletions