Changes between Version 66 and Version 67 of StreamingGuide


Ignore:
Timestamp:
Jan 15, 2014, 6:36:30 PM (6 years ago)
Author:
rogerdpack
Comment:

mplayer needs a patch, man!

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v66 v67  
    8484You might get less latency by using one of the "point to point" protocols described in this document, at well. You'd lose the benefit of having a server, of course.
    8585
    86 NB that if you are sending to UDP or what not, that a client may have to wait until the next i-frame to be able to start receiving the stream, so the GOP setting (-g) i-frame interval will have an effect on how quickly they can connect.  Setting it to a lower number means it will use more bandwidth, but clients will be able to connectmore quickly (the default for x264 is 250--so for 30 fps that means an i-frame only once every 10 seconds or so).  So it's a tradeoff if you adjust it.  This does not affect actual latency (just connection time) since the client can still display frames very quickly after and once it has received its first i-frame.  Also if you're using a lossy transport, like UDP, then an i-frame represents "the next change it will have to repair the stream" if there are problems from packet loss.
     86NB that a client when it initially starts up may have to wait until the next i-frame to be able to start receiving the stream (ex: if receiving UDP), so the GOP setting (-g) i-frame interval will have an effect on how quickly they can start streaming (i.e. they must receive an i-frame before they start).  Setting it to a lower number means it will use more bandwidth, but clients will be able to connect more quickly (the default for x264 is 250--so for 30 fps that means an i-frame only once every 10 seconds or so).  So it's a tradeoff if you adjust it.  This does not affect actual latency (just connection time) since the client can still display frames very quickly after and once it has received its first i-frame.  Also if you're using a lossy transport, like UDP, then an i-frame represents "the next change it will have to repair the stream" if there are problems from packet loss.
    8787
    8888You can also (if capturing from a live source) increase frame rate to decrease latency (which affects throughput and also i-frame frequency, of course).  This obvious sends packets more frequently, so (with 5 fps, you introduce at least a 0.2s latency, with 10 fps 0.1s latency) but it also helps clients to fill their internal buffers, etc. more quickly.
     
    9999
    100100Using 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).
     101
     102See also "Point to point streaming" section esp. if you use UDP etc.
    101103
    102104=== See also ===
     
    197199== Troubleshooting Streaming ==
    198200
    199 If you get a "black/blank" screen back from your server, try sending it yuv422p or yuv420p type input.  Some servers get confused if you send them yuv444 input (which is the default for libx264).
    200 
     201If you get a "black/blank" screen in the client, try sending it yuv422p or yuv420p type input.  Some servers get confused if you send them yuv444 input (which is the default for libx264).
    201202
    202203NB that when you are testing your stream settings, you may want to test them with both VLC and [http://ffmpeg.org/ffplay.html FFplay], as FFplay sometimes introduces its own artifacts when it is scaled (FFplay uses poor quality default scaling, which can be inaccurate).  Don't use ffplay as your baseline for determining quality. 
     
    213214   ffmpeg -i INPUT -f mpegts udp://host:port
    214215
    215 If you run into packet loss (since UDP is not guaranteed delivery, this might occur) first make sure your FFmpeg is compiled with pthreads support enabled (if it is, then it uses a separate thread to receive from the UDP port, which can cause less packet loss).  You can tell that it is by specifying a url like udp://host:post?fifo_size=10000 (if it accepts fifo_size, then you're good to go).  Similarly, for mplayer, you can use mplayer ffmpeg://udp://host:port?fifo_size=XXX for possibly better results on the receiving end.  Alternatively, increase your buffer size, like mplayer ffmpeg://udp://host:port?buffer_size=10000000 (the default is system dependent and typically far too low for any reasonable buffering.  On linux though you can only set it to like 200K max anyway, so make sure this works: ffmpeg://udp://host:port?buffer_size=10000000?fifo_size=100000 (the fifo_size should not emit a warning, and implies that you have a secondary thread that collects incoming packets for you if there is no warning).
     216If you run into packet loss (green frames, tearing/shearing--since UDP is not guaranteed delivery, this might occur) first make sure your FFmpeg is compiled with pthreads support enabled (if it is, then it uses a separate thread to receive from the UDP port, which can cause less packet loss).  You can tell that it is by specifying a url like udp://host:post?fifo_size=10000 (if it accepts fifo_size, then you're good to go).  Similarly, for mplayer, you can use mplayer ffmpeg://udp://host:port?fifo_size=XXX for possibly better results on the receiving end (mplayer needs a patch first, email rogerdpack@gmail.com for it).  Alternatively, increase your buffer size, like mplayer ffmpeg://udp://host:port?buffer_size=10000000 (the default is system dependent and typically far too low for any reasonable buffering.  On linux though you can only set it to like 200K max anyway, so make sure this works: ffmpeg://udp://host:port?buffer_size=10000000?fifo_size=100000 (the fifo_size should not emit a warning, and implies that you have a secondary thread that collects incoming packets for you if there is no warning).
    216217
    217218Another option is to use some transmission type that uses TCP for your transport. (The rtmp protocol, popular in streaming to servers, uses TCP probably for this reason--you just can't use that for point to point streaming).