Changes between Version 57 and Version 58 of StreamingGuide


Ignore:
Timestamp:
Oct 21, 2013, 10:41:54 PM (3 years ago)
Author:
rogerdpack
Comment:

more notes on i-frames, plus fix setting

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v57 v58  
    22[[PageOutline(2, Contents)]] 
    33 
    4 FFmpeg can basically stream through one of two ways:  It either streams to a some "other server", which restreams for it, or it can stream via UDP/TCP directly to some destination receiver, or alternatively directly to a multicast destination. 
     4FFmpeg can basically stream through one of two ways:  It either streams to a some "other server", which re-streams for it, or it can stream via UDP/TCP directly to some destination receiver, or alternatively directly to a multicast destination. 
    55 
    66Servers which can receive from FFmpeg (to restream) include [[Streaming media with ffserver|ffserver]] (linux only, though with cygwin it might work on windows), or [http://en.wikipedia.org/wiki/Wowza_Media_Server Wowza Media Server], or [http://en.wikipedia.org/wiki/Adobe_Flash_Media_Server Flash Media Server] or [https://en.wikipedia.org/wiki/List_of_streaming_media_systems#Servers various others]. Even [http://en.wikipedia.org/wiki/VLC_media_player VLC] can pick up the stream from ffmpeg, then redistribute it, acting as a server.  Since FFmpeg is at times more efficient than VLC at doing the raw encoding, this can be a useful option compared to doing both transcoding and streaming in VLC. Nginx also has an rtmp redistribution plugin, as does [http://h264.code-shop.com/trac/wiki apache etc.] and there is probably more out there for apache, etc..  You can also live stream to online redistribution servers like own3d.tv or justin.tv (for instance streaming your desktop).  Also any [http://www.flashrealtime.com/list-of-available-rtmp-servers/ rtmp server] will most likely work to receive streams from FFmpeg (these typically require you to setup a running instance on a server). 
     
    99== The -re flag == 
    1010 
    11 The FFmpeg's "-re" flag means to "Read input at native frame rate. Mainly used to simulate a grab device." i.e. if you want to play a video file, but at realtime, then use this. My guess is you typically don't want to use this flag when streaming from a live device. 
     11The FFmpeg's "-re" flag means to "Read input at native frame rate. Mainly used to simulate a grab device." i.e. if you wanted to stream a video file, then you would want to use this, otherwise it might stream it too fast (it attempts to stream at line speed by default). My guess is you typically don't want to use this flag when streaming from a live device, ever. 
    1212 
    1313Also avoid the -sameq flag, which means "same quantizer" not same quality, and probably should be avoided. 
     
    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 (-i) 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. 
     86NB 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. 
    8787 
    8888Note also that using dshow's "rtbufsize" has the unfortunate side effect of allowing frames to "buffer" while it is waiting on encoding of previous frames, or waiting for them to be sent on the wire.  This means that if you use a higher value at all, it can cause/introduce added latency if it ever gets used (but if used, can be helpful for other aspects, like transmitting more frames overall).