[FFmpeg-devel] [PATCH] HLS problem

[aviad rozenhek]

On Fri, Jan 14, 2011 at 11:26, Martin Storsj? <martin at martin.st> wrote:

> On Wed, 12 Jan 2011, aviad rozenhek wrote:
>
> > On Wed, Dec 15, 2010 at 21:38, Reimar D?ffinger <
> Reimar.Doeffinger at gmx.de>wrote:
> >
> > > 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?
>
> Which was the exact issue that you wanted fixed? These error messages,
> right?
>
> [aac @ 030aeeb0] channel element 3.15 is not allocated
> [aac @ 030aeeb0] Input buffer exhausted before END element found
>
> Despite these, it does seem to play back quite fine for me, but I do hear
> a small audio glitch at the segment boundaries.
>
> Did you test the patch above, which Reimar suggested, did it make any
> difference to you? Since to me, it doesn't affect the playback of the
> sample stream you sent at all.
>
> I did take a closer look on the stream, and it seems that the issue is
> that the mpegts stream is cut into segments in arbitrary positions. Our
> applehttp demuxer demuxes each file individually, and due to that, it will
> return incomplete packets at the end of each segment (leading to these
> errors), if the segment files are cut in this way.
>
> Initially, I tried to implement Apple HTTP live streaming as an
> urlprotocol, which returns a concatenated stream of all the segment files
> in the playlist. Ronald preferred doing it as a demuxer, which does have a
> few other advantages, but this is one of the disadvantages.
>
> I still kept the original approach in a branch, which I rebased onto the
> latest master. You can test the attached patch and see if it works better
> for you in that way. When using that approach, preprend applehttp:// to
> the normal http:// url to the m3u8 file, so you'd get e.g.
> applehttp://http://71.170.161.23:8080/downloads/ch5/03.m3u8. (For some
> reason, this seems to be able to avoid buffer underruns better than the
> current demuxer approach.)
>
> // Martin
>
Many thanks,
yes the 100$ is for fixing various error messages and decoding errors along
with the audible glitches.
additionally, I noticed that there's a problem with the timestamps not being
strictly monotonically increasing
[which might be explained by the problems with the demuxer approach]

IMHO iphone considers the file to be one big stream and does not suffer from
these problem
and since iphone is the major consumer of HLS that makes it [defacto]
correct in my book.

unfortunately it might take me a week or more before I can test the patch,
but it sounds very promising

best,
A.