* These are my notes on streaming

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

1 files changed, 102 insertions, 0 deletions

diff --git a/doc/HOWTO-STREAM b/doc/HOWTO-STREAM
new file mode 100644
index 0000000000..1a666fd405
--- /dev/null
+++ b/doc/HOWTO-STREAM
@@ -0,0 +1,102 @@
+The FFserver streaming HOWTO
+----------------------------
+
+Philip Gladstone <philip-ffserver@gladstonefamily.net>
+Last updated: May 8, 2002
+
+0. What is this HOWTO about?
+
+This covers only the streaming aspects of ffserver / ffmpeg. All questions about
+parameters for ffmpeg, codec questions, etc. are not covered here.
+
+You should also read the ffserver.txt file in this directory. It contains
+roughly the same information.
+
+1. What can this do?
+
+When properly configured and running, you can capture video and audio in real
+time from a suitable capture card, and stream it out over the Internet to
+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.
+
+2. What do I need?
+
+I use Linux on a 900MHz Duron with a cheapo Bt848 based TV capture card. I'm
+using stock linux 2.4.17 with the stock drivers. [Actually that isn't true,
+I needed some special drivers from my motherboard based sound card.]
+
+I understand that FreeBSD systems work just fine as well.
+
+3. How do I make it work?
+
+First, build the kit. It *really* helps to have installed LAME first. Then when
+you run the ffserver ./configure, make sure that you have the --enable-mp3lame
+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:
+
+./ffserver -f doc/ffserver.conf &
+./ffmpeg http://localhost:8090/feed1.ffm
+
+At this point you should be able to go to your windows machine and fire up
+Windows Media Player (WMP). Go to Open URL and enter 
+
+    http://<linuxbox>:8090/test.asf
+
+You should see (after a short delay) video and hear audio. 
+
+4. What happens next?
+
+You should edit the ffserver.conf file to suit your needs (in terms of 
+frame rates etc). Then install ffserver and ffmpeg, write a script to start
+them up, and off you go.
+
+5. Troubleshooting
+
+* I don't hear any audio, but video is fine
+
+Maybe you didn't install LAME, or get your ./configure statement right. Check
+the ffmpeg output to see if a line referring to mp3 is present. If not, then
+your configuration was incorrect. If it is, then maybe your wiring is not
+setup correctly. Maybe the sound card is not getting data from the right 
+input source. Maybe you have a really awful audio interface (like I do)
+that only captures in stereo and also requires that one channel be flipped. 
+If you are one of these people, then export 'AUDIO_FLIP_LEFT=1' before 
+starting ffmpeg.
+
+* The audio and video loose sync after a while.
+
+Yes, they do.
+
+* After a long while, the video update rate goes way down in WMP.
+
+Yes, it does. Who knows why?
+
+6. 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 fiddle with many of the codec choices and encoding parameters, and
+there are a bunch more parameters that you cannot control. Post a message
+to the mailing list if there are some 'must have' parameters. Look in the
+ffserver.conf for a list of the currently available controls.
+
+7. Tips
+
+* When you connect to a live stream, most players (WMP, RA etc) want to
+buffer a certain number of seconds of material so that they can display the
+signal continuously. However, ffserver (by default) starts sending data
+in real time. This means that there is a pause of a few seconds while the
+buffering is being done by the player. The good news is that this can be
+cured by adding a '?buffer=5' to the end of the URL. This says that the
+stream should start 5 seconds in the past -- and so the first 5 seconds 
+of the stream is sent as fast as the network will allow. It will then
+slow down to real time. This noticeably improves the startup experience.