Changes between Version 64 and Version 65 of StreamingGuide

Timestamp:

Jan 7, 2014, 9:00:32 PM (13 years ago)

Author:

Roger Pack

Comment:

ok ffmpeg -f sdl doesn't realy work all the time even...

StreamingGuide

@@ -94 +94 @@
 === Testing latency ===
 
-By default, ffplay (as a receiver for testing latency) introduces a small latency of its own, so if you use it for testing (see troubleshooting section) it may not reflect latency accurately.  NB that ffplay also has somewhat poor video output, though, so don't base quality levels on that.  Also some settings mentioned above like "probesize" might help it start more quickly.
-
-Also useful is mplayer with its -benchmark for testing latency (-noaudio and/or -nocache *might* be useful, though I haven't found -nocache to provide any latency benefit). 
-
-Using the SDL out option while using FFmpeg to receive the stream might also help to view frames with less client side latency: "ffmpeg ... -f sdl -"  (this works especially well with -fflags nobuffer, though in my tests is still barely slower than using mplayer).
+By default, ffplay (as a receiver for testing latency) introduces significant latency of its own, so if you use it for testing (see troubleshooting section) it may not reflect latency accurately. FFplay introduces some video artifacts, also, see notes for it in "troubleshooting streaming" section  Also some settings mentioned above like "probesize" might help it start more quickly.
+
+Useful is mplayer with its -benchmark for testing latency (-noaudio and/or -nocache *might* be useful, though I haven't found -nocache to provide any latency benefit it might work for you). 
+
+Using the SDL out option while using FFmpeg to receive the stream might also help to view frames with less client side latency: "ffmpeg ... -f sdl <input_here> "window title""  (this works especially well with -fflags nobuffer, though in my tests is still barely more latency than using mplayer -benchmark at best).  This doesn't have a "drop frames if you run out of cpu" option so it can get quite far behind at times (introduce more latency variably).
 
 === See also ===
@@ -116 +116 @@
 If you're able to live capture in a pixel format that matches your output format (ex: yuv420p output from a webcam, instead of mjpeg), that might help with cpu usage, since it avoids an extra conversion.  Using 64-bit instead of 32-bit executables (for those that have that choice) can result in a slight speedup.  If you're able to use -vcodec copy that, of course, uses the least cpu of all options since it just sends the frames verbatim to the output.
 
-Sometimes you can change the "pixel formats" somehow, like using rgb16 instead of rgb24, to save time/space (or yuv420 instead of yuv444 or the like, since 420 stores less information it may compress better).
+Sometimes you can change the "pixel formats" somehow, like using rgb16 instead of rgb24, to save time/space (or yuv420 instead of yuv444 or the like, since 420 stores less information it may compress better and use less bandwidth).  This may not affect latency.
 
 == Streaming a simple RTP audio stream from FFmpeg ==
@@ -127 +127 @@
 }}}
 
-To play the stream with ffplay, run the command:
+To play the stream with ffplay (which has some caveats, see above), run the command:
 {{{
 ffplay rtp://127.0.0.1:1234