On Sun, Sep 20, 2020 at 10:52:52AM +0200, Marton Balint wrote: > Signed-off-by: Marton Balint <[email protected]> > --- > libavformat/aviobuf.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c > index 9675425349..aa1d6c0830 100644 > --- a/libavformat/aviobuf.c > +++ b/libavformat/aviobuf.c > @@ -999,9 +999,12 @@ int ffio_ensure_seekback(AVIOContext *s, int64_t > buf_size) > int filled = s->buf_end - s->buffer; > ptrdiff_t checksum_ptr_offset = s->checksum_ptr ? s->checksum_ptr - > s->buffer : -1; > > - buf_size += s->buf_ptr - s->buffer + max_buffer_size; > + if (buf_size <= s->buf_end - s->buf_ptr) > + return 0; > + > + 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);
Not acceptable change. Your code does this to chained ogg files: XXX 10 XXX 65307 XXX 65307 102031 106287 110527 114745 119319 [...] It continues allocating excessive small extra chunks of bytes for no apparent reason in each and every call which slowly and gradually increases memory usage, but every call causes unnecessary memcpy calls thus causing almost exponential slowdown of file processing. Lines with XXX, means that allocation and memcpy was not needed. I can also post behavior of my solution, which work just fine, and I yet need to find scenario when it does not work. > > -- > 2.26.2 > > _______________________________________________ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
