[Ffmpeg-devel] ffmpeg http still broke
Fri Jan 19 01:26:13 CET 2007
On Wed, Jan 17, 2007 at 07:26:04PM -0800, C.Ren Boca wrote:
> Not any more.
> Here is the fix:
> in libavformat http.c:
> 41 #define BUFFER_SIZE 1024
> change to:
> 41 #define BUFFER_SIZE 4096 (at least).
> I do not know if this will work with ubiquity, but it seems to work as
> Here is the explanation:
> When ffserver starts, and a .ffm file is specified in the conf file, like
> /tmp/feed1.ffm, it writes out that file as 4096 bytes. This file contains the
> stream parameters that ffmpeg tries to get via HTTP Get. That file will eventually get larger as a stream is fed to it by ffmpeg, and is used for time-shifting, aka seeking.
> ffmpeg apparently needs these parameters to operate, and if it can't
> get them, it exits with:
> Could not read stream parameters from 'http://localhost:8090/feed1.ffm'
> The .ffm file size is limited by:
> in the conf file, (unlimited if set to 0).
> When I delete the .ffm file, and start ffserver again, that file size is
> always initialized as 4096 bytes. It has parameters from the conf file,
> (I presume) plus null padding,
> If I get that file from ffserver with wget, before sending a stream to it,
> I always get 4112 bytes. (Why 16 bytes extra, I do not know.)
> But the first 4096 bytes of the file I wget always match the .ffm file that
> ffserver creates.
> sum /tmp/feed1.ffm
> wget http://localhost:8090/feed1.ffm;
> dd if=feed1.ffm ibs=1024 count=4 | sum
> I do not know why ffmpeg worked before when the http input buffer was 1024 bytes, but it may have to do with HTTP/1.1 vs HTTP/1.0.
> However, I think it is a sensible fix. If ffserver writes out stream
> parameters as a 4096 byte buffer (as the .ffm file), then it seems that
> ffmpeg should get all those data before proceeding.
> It seems better that it should get them all at once and handle it, as
> opposed to only getting 1024 bytes at a time, having to do it 4 times,
> then moving on.
ffmpeg must work even if the protocol provides only 1 byte at a time
so the question is is the 1024 buffer causing http.c to fail internally?
like some of the http headers dont fit into this or is it just that
http_read() returns less then ffm/ffmpeg/ffserver would like, in the later
case this bug is not in http.c
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel