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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4