On Mon, Mar 20, 2017 at 1:35 PM, Michael Niedermayer <mich...@niedermayer.cc > wrote:
> On Mon, Mar 20, 2017 at 10:21:08AM -0700, Fredrik Hubinette wrote: > > In some cases (when parsing OGG) non-fatal errors can happen, which > > will cause s->error to be set. In most cases, this is not a problem > beucase > > s->error is not checked unless an actual error has occurred. However, > > when avio_read() fails to read more bytes, it checks s->error to decide > if > > it just reached the end of the file, or an error occurred. Since > s->error is > > not modified if no error occurred, this is not reliable unless we first > > clear > > s->error before reading. > > > > --- > > libavformat/aviobuf.c | 2 ++ > > > > 2 files changed, 7 insertions(+) > > how can the issue you describe be reproduced > > I don't currently have a simple repro. I discovered it while trying to add some buffering between the demuxer and decoder in chrome. One of our tests fails, and when looked into it, I discovered that s->error was already 5 (EIO) when entering avio_read. I have not yet tracked down where the EIO came from originally. also thats not a valid git patc > Ops, I had a chrome patch and I removed the chrome-specific parts, but I must have messed it up. I will make a better patch. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who are best at talking, realize last or never when they are wrong. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
