Changes between Version 20 and Version 21 of StreamingGuide


Ignore:
Timestamp:
08/14/2012 07:16:34 PM (9 months ago)
Author:
rogerdpack
Comment:

minor textual cleanup, more tweaking of cpu usage

Legend:

Unmodified
Added
Removed
Modified

  • StreamingGuide

    v20 v21  
    1 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 directly to some destination host, or possibly multicast destination. 
    2 Servers which can receive from FFmpeg (to restream) include [http://ffmpeg.org/ffserver.html ffserver] (linux only, though cygwin 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, then redistribute it, acting as a server. Since FFmpeg is sometimes more efficient than VLC, at doing the raw encoding, this can be a useful option compared to doing it all in VLC. 
     1FFmpeg 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 directly to some destination host, or alternatively directly to a multicast destination. 
     2Servers which can receive from FFmpeg (to restream) include [http://ffmpeg.org/ffserver.html 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. 
    33 
    44How to stream with several different simultaneous bitrates is described [http://sonnati.wordpress.com/2011/08/30/ffmpeg-%E2%80%93-the-swiss-army-knife-of-internet-streaming-%E2%80%93-part-iv/ here]. 
    … …  
    66NB 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 has poor quality scaling).  Don't use ffplay as your baseline for determining quality. 
    77 
    8 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]. 
     8Also 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. 
    99 
    1010The 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 this flag when streaming from a live device. 
    … …  
    4747NB that they also had to adjust the rtbufsize in that example.  I'm also not entirely sure which presets are "best" or what the available options are.  Also note that newer version of FFmpeg may need a different syntax for specifying preset/tune. 
    4848 
    49 == Latency/cpu-usage == 
     49== Latency == 
    5050 
    51 You can decrease latency by specify that I-frames come "more frequently" (or always, in the case of x264's zerolatency), though this can increase frame size/decrease quality, see [http://mewiki.project357.com/wiki/X264_Encoding_Suggestions here] for some alternatives.  To decrease cpu usage required to stream, you could (if capturing from live source) instruct the live source to feed a "smaller stream" (ex: webcam stream 640x480 instead of 1024x1280), or you could set a lower "output quality" setting, or specify a lower output bitrate.  Or try a different output codec, or specify new parameters (for instance, different profile for libx264).  Also specifying $ -threads 0 (the default) instructs the encoder to use all available cpu cores, which can speed up processing.  You could also resize your input first, before transcoding it, so it's not as large.  Applying a smoothing filter like hqdn3d before encoding might help it compress better. 
     51You can decrease latency by specify that I-frames come "more frequently" (or basically always, in the case of [[x264EncodingGuide|x264]]'s zerolatency setting), though this can increase frame size and decrease quality, see [http://mewiki.project357.com/wiki/X264_Encoding_Suggestions here] for some background. 
    5252 
    53 You can of course, also set a lower frame rate to decrease cpu usage. 
     53== Cpu usage/File size == 
    5454 
    55 You could set a "maximum bit rate" or a lower "q rating" (quality level).  If you're able to capture with a pixel format that matches your output format, that might help, since it avoids a conversion.  Using 64-bit instead of 32-bit executables (for those that have a choice) can result in a slight speedup. 
     55In general, the more cpu you use to compress, the better the output image will be, or the smaller of a file the output will be. 
    5656 
    57 In general the more cpu you use to compress, the better the output image will be, or the large of an image you can handle. 
     57Basically, the easiest way to save cpu is to decrease the input frame rate/size, or decrease the output frame rate/size. 
    5858 
    59 And also basically, you can either decrease the input frame rate/size, or decrease the output frame rate/size, to save cpu. 
     59Also you could (if capturing from live source), instruct the live source to feed a "smaller stream" (ex: webcam stream 640x480 instead of 1024x1280), or you could set a lower output "output quality" setting (q level), or specify a lower output desired bitrate (see [[x264EncodingGuide]] for a background).  Or try a different output codec, or specify new parameters to your codec (for instance, a different profile or preset for [[x264EncodingGuide|libx264]]).  Specifying $ -threads 0 instructs the encoder to use all available cpu cores, which is the default.  You could also resize the input first, before transcoding it, so it's not as large.  Applying a smoothing filter like hqdn3d before encoding might help it compress better, yielding smaller files. 
    6060 
    61 Sometimes you can change the "pixel formats" somehow, like using rgb16 instead of rgb24, to save space (or yuv420 instead of yuv444 or the like, since 420 stores less information it can compress better). 
     61You can also set a lower output frame rate to of course decrease cpu usage.   
     62 
     63If 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. 
     64 
     65Sometimes 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). 
    6266 
    6367== Streaming a simple RTP audio stream from FFmpeg ==