[FFmpeg-devel] [PATCH] HLS problem

Reimar Döffinger Reimar.Doeffinger
Wed Jan 12 19:22:48 CET 2011


On Wed, Jan 12, 2011 at 06:57:07PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 12, 2011 at 06:36:31PM +0100, Reimar D?ffinger wrote:
> > > > Issue 2282.
> > > > Patch is this
> > > > Index: libavformat/aviobuf.c
> > > > ===================================================================
> > > > --- libavformat/aviobuf.c       (revision 25928)
> > > > +++ libavformat/aviobuf.c       (working copy)
> > > > @@ -603,7 +603,7 @@
> > > >  
> > > >      if (init_put_byte(*s, buffer, buffer_size,
> > > >                        (h->flags & URL_WRONLY || h->flags & URL_RDWR), h,
> > > > -                      url_read, url_write, url_seek) < 0) {
> > > > +                      url_read_complete, url_write, url_seek) < 0) {
> > > >          av_free(buffer);
> > > >          av_freep(s);
> > > >          return AVERROR(EIO);
> > > > 
> > > > 
> > > > Needs someone to review and/or test it properly.
> > > 
> > > This patch is wrong, it would cause network streams to block and increase
> > > latency unreasonable
> > 
> > Uh, none of the ByeIOContext functions I saw handle incomplete reads
> > even remotely sanely, so your argument is it increases latency instead
> > of not playing at all?
> 
> 10+ second latency for real time communication is like not working, and with
> low bitrate audio codecs you will see more latency.
> That latency would be like in interplanetar communication ...
> 
> About ByteIOContext, which part does not handle incomplete reads?

Hm, looks like I vastly overestimated the issue, in which case I agree
above patch is not acceptable.
I haven't tested it, but I suspect that get_buffer and fill_buffer both
need to handle EAGAIN.
I don't fully understand that though, since that really should lead to EOF instead
of constant decode errors...



More information about the ffmpeg-devel mailing list