[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