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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070119/5a121b04/attachment.pgp>
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