Changes between Version 49 and Version 50 of StreamingGuide


Ignore:
Timestamp:
11/07/2012 09:26:22 PM (7 months ago)
Author:
rogerdpack
Comment:

hopefully better troubleshooting/latency

Legend:

Unmodified
Added
Removed
Modified

  • StreamingGuide

    v49 v50  
    66Servers which can receive from FFmpeg (to restream) include [[Streaming media with ffserver|ffserver]] (linux only, though with cygwin it might work), 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]. 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). 
    77 
    8 NB that when you are testing your streams, 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 (it uses poor quality scaling, which can be inaccurate).  Don't use ffplay as your baseline for determining quality. 
    9  
    10 Also note that encoding it to the x264 "baseline" is basically for older iOS devices or the like, see [http://sonnati.wordpress.com/2011/08/30/ffmpeg-%E2%80%93-the-swiss-army-knife-of-internet-streaming-%E2%80%93-part-iv/ here].  Some people argue that just using mpeg4video codec is better than x264 baseline (where possible) since it is a simpler codec.  See the codec section in this page. 
    118 
    129== The -re flag == 
    … …  
    7774There is also an option -fflags nobuffer which is said to [http://ffmpeg.org/ffmpeg.html#Format-AVOptions reduce latency]. 
    7875 
     76Also note that by default, ffplay introduces a latency of its own, so if you use it for testing (see troubleshooting section) it may need some of these parameters, as well.  Also useful is mplayer with its -nocache for testing latency. 
     77 
    7978== Cpu usage/File size == 
    8079 
    … …  
    109108== Codecs == 
    110109 
    111 The most popular streaming codec is probably [http://www.videolan.org/developers/x264.html libx264], though if you're streaming to a device which requires a "crippled" baseline h264 implementation, some have argued that the mp4 video codec is [http://forums.macrumors.com/showthread.php?t=398016 better].  You can also use mpeg2video, or really any other video codec you want, typically, as long as your receiver can decode it, and it suits your needs. 
    112  
    113 mpeg4 (the video codec) sometimes comes "within a few percentage" of the compression of x264, but using much less cpu to do the encoding.  See http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=631&hilit=mpeg4+libx264+cores&start=10#p2163 for some graphs (which may be slightly outdated).  Basically in that particular test it was 54 fps to 58 fps (libx264 faster), and libx264 file was 5.1MB and mpeg4 was 6MB, but mpeg4 used only half as much cpu for its computation, so take it with a grain of salt. 
     110The most popular streaming codec is probably [http://www.videolan.org/developers/x264.html libx264], though if you're streaming to a device which requires a "crippled" baseline h264 implementation, you can use the x264 "baseline" profile.  Some have have argued that the mp4 video codec is [http://forums.macrumors.com/showthread.php?t=398016 better] than x264 baseline, because it encodes about as well with less cpu.  You may be able to use other codecs, like mpeg2video, or really any other video codec you want, typically, as long as your receiver can decode it, if it suits your needs. 
     111 
     112Also note that encoding it to the x264 "baseline" is basically a "compatibility mode" for older iOS devices or the like, see [http://sonnati.wordpress.com/2011/08/30/ffmpeg-%E2%80%93-the-swiss-army-knife-of-internet-streaming-%E2%80%93-part-iv/ here].  
     113 
     114The mpeg4 video codec sometimes also comes "within a few percentage" of the compression of x264 "normal settings", but uses much less cpu to do the encoding.  See http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=631&hilit=mpeg4+libx264+cores&start=10#p2163 for some graphs (which may be slightly outdated).  Basically in that particular test it was 54 fps to 58 fps (libx264 faster), and libx264 file was 5.1MB and mpeg4 was 6MB, but mpeg4 used only half as much cpu for its computation, so take it with a grain of salt. 
    114115 
    115116== HTTP Live Streaming and Streaming with multiple bitrates == 
    … …  
    168169== Troubleshooting Streaming == 
    169170 
    170 If you get a "black/blank" screen 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). 
     171If 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). 
     172 
     173 
     174NB 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.   
    171175 
    172176== Point to point streaming ==