Submitting a patch to fix a bug in ffmpeg found when reading data from a
named pipe. In our test, a pipe sending twelve bytes in two 6 byte messages
results in the first 10 bytes being lost. We found the problem was
introduced with this commit (2ca48e466675a8a3630061cd2c15325eab8eda97) on
June 30,
Attaching the output of "git diff -p".
On Fri, May 12, 2017 at 11:50 AM Michael Niedermayer
wrote:
> On Fri, May 12, 2017 at 06:31:19PM +0000, Rob Meyers wrote:
> > Submitting a patch to fix a bug in ffmpeg found when reading data from a
> > named pipe. In our test, a
---
libavformat/aviobuf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 0a7c39eacd..4e04cb79e0 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -519,9 +519,7 @@ void avio_write_marker(AVIOContext *s, int6
hat this bug is
triggered.
On Mon, May 15, 2017 at 10:49 AM Hendrik Leppkes
wrote:
> On Mon, May 15, 2017 at 6:47 PM, Rob Meyers
> wrote:
> > ---
> > libavformat/aviobuf.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
>
> Commit messages t
No problem. I'll resubmit the patch request.
On Mon, May 15, 2017 at 9:47 PM wm4 wrote:
> On Mon, 15 May 2017 17:55:28 +0000
> Rob Meyers wrote:
>
> > Of course.
> >
> > We noticed when reading data from a named pipe the first 10 bytes would
> get
> &g
We noticed when reading data from a named pipe the first 10 bytes
would get dropped. I traced this to the affected code in
fill_buffer(). The assignment of "dst" was always set to the beginning
of the buffer, and if it hadn't been consumed yet the data would be
overwritten. We could reproduce this
buffer is in AVIOContext. The problem with the original code was that
max_buffer_size is added to the request, to see if it's larger than another
value that is also max_buffer_size. Like, "if (A + B) < B".
On Tue, May 16, 2017 at 9:06 AM Michael Niedermayer
wrote:
> On Mon,
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 fi
ccumulated data,
so avoid reallocating the buffer the first time through.
On Thu, May 18, 2017 at 3:53 PM Michael Niedermayer
wrote:
> 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 fulfi
I can confirm the current source tree has resolved our issue.
On Fri, May 19, 2017 at 12:16 PM Michael Niedermayer
wrote:
> On Fri, May 19, 2017 at 08:28:23PM +0200, Michael Niedermayer wrote:
> > hi
> >
> > On Thu, May 18, 2017 at 10:58:39PM +, Rob Meyers wrote:
10 matches
Mail list logo
