Updated to reflect the current state of ffserver (as I understand it).

Originally committed as revision 1266 to svn://svn.ffmpeg.org/ffmpeg/trunk

1 files changed, 14 insertions, 10 deletions

diff --git a/doc/ffserver-doc.texi b/doc/ffserver-doc.texi
index 051038ed87..ff37d3b1c4 100644
--- a/doc/ffserver-doc.texi
+++ b/doc/ffserver-doc.texi
@@ -33,6 +33,9 @@ either Windows Media Player or RealAudio player (with some restrictions).
 It can also stream from files, though that is currently broken. Very often, a
 web server can be used to serve up the files just as well.
 
+It can stream prerecorded video from .ffm files, though it is somewhat tricky
+to make it work correctly.
+
 @section What do I need?
 
 I use Linux on a 900MHz Duron with a cheapo Bt848 based TV capture card. I'm
@@ -50,7 +53,8 @@ flag turned on.
 LAME is important as it allows streaming of audio to Windows Media Player. Don't
 ask why the other audio types do not work.
 
-As a simple test, just run the following two command lines:
+As a simple test, just run the following two command lines (assuming that you
+have a V4L video capture card):
 
 @example
 ./ffserver -f doc/ffserver.conf &
@@ -67,7 +71,7 @@ Windows Media Player (WMP). Go to Open URL and enter
 You should see (after a short delay) video and hear audio. 
 
 WARNING: trying to stream test1.mpg doesn't work with WMP as it tries to
-transfer the entire file before starting to play.
+transfer the entire file before starting to play. The same is true of avi files.
 
 @section What happens next?
 
@@ -106,10 +110,11 @@ I suspect that the new one is not available unless you have installed WMP 7].
 
 @section What else can it do?
 
-There seems to be a bunch of code that allows you to replay previous
-video. I've never tried it, so it probably doesn't work properly. YMMV.
-In fact, in order to get some level of stability, ffserver now deletes
-all the previously sent video whenever it restarts.
+You can replay video from .ffm files that was recorded earlier.
+However, there are a number of caveats which include the fact that the 
+ffserver parameters must match the original parameters used to record the
+file. If not, then ffserver deletes the file before recording into it. (Now I write
+this, this seems broken).
 
 You can fiddle with many of the codec choices and encoding parameters, and
 there are a bunch more parameters that you cannot control. Post a message
@@ -153,15 +158,14 @@ means that the timestamp in the encoded data stream gets behind real time.
 This means that if you say 'preroll 10', then when the stream gets 10
 or more seconds behind, there is no preroll left.
 
-Fixing this requires a require in the internals in how timestampts are 
+Fixing this requires a change in the internals in how timestamps are 
 handled.
 
 @section Does the @code{?date=} stuff work.
 
 Yes (subject to the caution above). Also note that whenever you start
-ffserver, it deletes the ffm file, thus wiping out what you had recorded
-before. This behaviour is a temporary fix to various crashes. The aim is
-to fix it so that the old data is saved if possible.
+ffserver, it deletes the ffm file (if any parameters have changed), thus wiping out what you had recorded
+before. 
 
 The format of the @code{?date=xxxxxx} is fairly flexible. You should use one
 of the following formats (the 'T' is literal):