[FFmpeg-devel] [PATCH] HLS problem (original) (raw)

aviad rozenhek aviadr1
Fri Jan 14 18:43:29 CET 2011

On Fri, Jan 14, 2011 at 11:26, Martin Storsj? 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 (initputbyte(*s, buffer, buffersize, > > (h->flags & URLWRONLY || h->flags & URLRDWR), h, > > - urlread, urlwrite, urlseek) < 0) {_ _> > + urlreadcomplete, urlwrite, urlseek) < 0) {_ _> > avfree(buffer); > > avfreep(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.

More information about the ffmpeg-devel mailing list