[FFmpeg-devel] [PATCH] HLS problem

Michael Niedermayer michaelni
Wed Jan 12 16:43:07 CET 2011


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

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/54edc0ae/attachment.pgp>



More information about the ffmpeg-devel mailing list