[FFmpeg-devel] [PATCH] HLS problem

[aviad rozenhek]

On Wed, Dec 15, 2010 at 21:38, Reimar D?ffinger <Reimar.Doeffinger at gmx.de>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.
>
>
I'm pledging a 100$ for a fix to this issue.
any takers?