Changes between Version 64 and Version 65 of StreamingGuide


Ignore:
Timestamp:
Jan 7, 2014, 11:00:32 PM (6 years ago)
Author:
rogerdpack
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v64 v65  
    9494=== Testing latency ===
    9595
    96 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.
    97 
    98 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).
    99 
    100 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).
     96By 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.
     97
     98Useful 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).
     99
     100Using 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).
    101101
    102102=== See also ===
     
    116116If 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.
    117117
    118 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).
     118Sometimes 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.
    119119
    120120== Streaming a simple RTP audio stream from FFmpeg ==
     
    127127}}}
    128128
    129 To play the stream with ffplay, run the command:
     129To play the stream with ffplay (which has some caveats, see above), run the command:
    130130{{{
    131131ffplay rtp://127.0.0.1:1234