Reimar Döffinger <[email protected]> added the comment:
On Mon, Oct 25, 2010 at 05:36:15PM +0000, Shawn Lewis wrote:
> in doing this, i think the root of the problem "may
> be" (and i say that because I am not familiar with
> AAC compression), that the AAC decoder may require
> look-ahead, or "complete frames", and when it doesnt
> have a complete frame, it causes the whole thing to
> barf.
You are looking at the completely wrong place.
As long as you are not switching to an unreliable
transport like UDP, if the chosen protocol makes any
difference in the produced output that is a bug
in the protocol. Looking anywhere outside that just
makes no sense.
Please try below patch (note that I have some doubts
that the HTTP part handles incomplete reads correctly,
so similar changes may be necessary in http.c, but I
did not see any obvious bugs at least).
Index: libavformat/aviobuf.c
===================================================================
--- libavformat/aviobuf.c (revision 25558)
+++ 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);
________________________________________________
FFmpeg issue tracker <[email protected]>
<https://roundup.ffmpeg.org/issue2282>
________________________________________________
