[Ffmpeg-devel] ffmpeg http still broke
Thu Mar 1 17:46:49 CET 2007
Michael Niedermayer wrote:
> 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
Should be fixed in svn.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel