[Ffmpeg-devel] ffmpeg http still broke

C.Ren Boca crboca32
Thu Jan 18 04:26:04 CET 2007


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.

Since this does not change the program logic but only a parameter, 
it seems reasonable, and only uses up 3072 bytes more memory.
(Unless it gets lost somewhere).

It may be possible that the conf file will contain more than 4096 bytes
worth of parameters, and these will get truncated when written out.

But, I think that the input buffer created in http.c, that is used by
ffmpeg, should at least match the set of data put out by ffserver.

I think this is a solid enough fix. I will test it plenty more of course.

Finally, since I am not up to speed on svn, and submitting
patches, if the committee approves, would someone else put this one
in?

Thanks.
P.


 
---------------------------------
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.



More information about the ffmpeg-devel mailing list