[FFmpeg-devel] [PATCH] avio_read data loss with multiple calls to fill_buffer

[Michael Niedermayer]

On Thu, May 18, 2017 at 01:12:49PM -0700, Rob Meyers wrote:
> avio_read may make multiple calls to fill_buffer to accumulate bytes
> to fulfill a request. fill_buffer will overwrite previously read data
> if it is not prepped. Added a call to 'ffio_ensure_seekback' to adjust
> the s->buffer to fill_buffer's liking. This isn't necessary for the
> very first call to fill_buffer, thus the "size1 != size" check.
> ---
>  libavformat/aviobuf.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 0a7c39eacd..8e9594cab8 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -648,6 +648,11 @@ int avio_read(AVIOContext *s, unsigned char *buf, int size)
>                      s->buf_end = s->buffer/* + len*/;
>                  }
>              } else {
> +                if (size1 != size)
> +                    /* this call will ensure fill_buffer will not overwrite previously
> +                    read data. */
> +                    ffio_ensure_seekback(s, size1);

ffio_ensure_seekback() should be called when theres a potential
seek back in the following code.

There is no seekback in avio_read(), avio_read only moves forward.
Some callers may do a avio_read() and or other function calls and
then seek back. A caller might do 3 avio_read() and seek back over all

ffio_ensure_seekback() generally should be called by the code that
later initiates teh seek back

ffio_ensure_seekback() is not free it should only be used when it is
needed.



[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170519/20392e48/attachment.sig>