| Message ID | 20200929211021.25030-3-cus@passwd.hu |
|---|---|
| State | Accepted |
| Commit | a3943c48472ebbef62034c4449462b5126c07007 |
| Headers | show |
| Series | [FFmpeg-devel,1/9] avformat/aviobuf: write data into the IO buffer till the very end of the buffer | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index d94be478ac..aa1d6c0830 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -1002,9 +1002,9 @@ int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size) if (buf_size <= s->buf_end - s->buf_ptr) return 0; - buf_size += s->buf_ptr - s->buffer + max_buffer_size; + buf_size += s->buf_ptr - s->buffer + max_buffer_size - 1; - if (buf_size < filled || s->seekable || !s->read_packet) + if (buf_size <= s->buffer_size || s->seekable || !s->read_packet) return 0; av_assert0(!s->write_flag);
The new buf_size was detemined too conservatively, maybe because of the off-by-one issue which was fixed recently in fill_buffer. We can safely substract 1 more from the new buffer size, because max_buffer_size space must only be guaranteed when we are reading the last byte of the requested window. Comparing the new buf_size against filled did not make a lot of sense, what makes sense is that we want to reallocate the buffer if the new buf_size is bigger than the old, therefore the change in the check. Signed-off-by: Marton Balint <cus@passwd.hu> --- libavformat/aviobuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)