[Ffmpeg-devel] ffmpeg http still broke

[Baptiste Coudurier]

Michael Niedermayer wrote:
> Hi
> 
> 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
>> before.
>>
>> 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:
>> FileMaxSize
>>
>> 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.
>>
>> ie:
>> sum /tmp/feed1.ffm 
>> 58460
>>
>> wget http://localhost:8090/feed1.ffm;
>> dd if=feed1.ffm ibs=1024 count=4 | sum
>> 58460
>>
>> 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