[Ffmpeg-devel] ffmpeg http still broke
Thu Jan 18 04:26:04 CET 2007
Not any more.
Here is the fix:
in libavformat http.c:
41 #define BUFFER_SIZE 1024
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
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.
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
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