[FFmpeg-devel] [PATCH] HLS problem

[Michael Niedermayer]

On Wed, Jan 12, 2011 at 06:36:31PM +0100, Reimar D?ffinger wrote:
> On Wed, Jan 12, 2011 at 04:43:07PM +0100, Michael Niedermayer wrote:
> > On Wed, Dec 15, 2010 at 08:38:52PM +0100, Reimar D?ffinger wrote:
> > > On Wed, Dec 15, 2010 at 01:34:26PM +0200, aviad rozenhek wrote:
> > > > On Tue, Dec 14, 2010 at 12:44, aviad rozenhek <aviadr1 at gmail.com> wrote:
> > > > > On Thu, Dec 9, 2010 at 18:49, aviad rozenhek <aviadr1 at gmail.com> wrote:
> > > > >> On Wed, Dec 8, 2010 at 20:10, Reimar D?ffinger <Reimar.Doeffinger at gmx.de>wrote:
> > > > >>> On Wed, Dec 08, 2010 at 12:18:14PM +0200, Martin Storsj? wrote:
> > > > >>> > On Wed, 8 Dec 2010, aviad rozenhek wrote:
> > > > >>> >
> > > > >>> > > you are probably correct that the playback problems i'm seeing are
> > > > >>> due to
> > > > >>> > > buffering issues, but still the slew of aac decoding error logs is
> > > > >>> > > worrisome. do you think its a bug in the aac encoder, missing data,
> > > > >>> or
> > > > >>> > > what?!?
> > > > >>> > > my tests show that the aac error logs still happen when I let ffplay
> > > > >>> buffer
> > > > >>> > > for a long time before playing.
> > > > >>> >
> > > > >>> > Not sure what these come from. You could download all the mpegts
> > > > >>> segment
> > > > >>> > files from a playlist, concatenate them to a long .ts file, and play
> > > > >>> back
> > > > >>> > that, and you probably get the same errors. If you hand that file to
> > > > >>> > someone more knowledgeable on AAC and mpegts, they may be able to give
> > > > >>> a
> > > > >>> > better verdict on the issue.
> > > > >>>
> > > > >>> There is a roundup bug with patch for that.
> > > > >>> The issue is that some code uses url_read instead of url_read_complete,
> > > > >>> at least in some cases with http that means the code ends up using
> > > > >>> unintialized data and worse that uninitialized data will even appear
> > > > >>> in addition to valid data so not even the file offsets make any sense
> > > > >>> anymore (at least it looked like that to me, though the first part
> > > > >>> alone is bad enough).
> > > > >>>
> > > > >>>
> > > > what is the bug number? what's holding the commit?
> > > > We're pledging a 100$ bounty to fix this issue.
> > > 
> > > 
> > > 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?

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

There seems to be only one solution to NIH syndrom, ... a shooting squad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110112/d827f6d4/attachment.pgp>