Changes between Version 83 and Version 84 of StreamingGuide
- Timestamp:
- Nov 15, 2020, 12:37:11 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
StreamingGuide
v83 v84 23 23 -vcodec libx264 -preset ultrafast -tune zerolatency -r 10 -async 1 -acodec libmp3lame -ab 24k -ar 22050 -bsf:v h264_mp4toannexb \ 24 24 -maxrate 750k -bufsize 3000k -f mpegts udp://192.168.5.215:48550 25 }}} 25 }}} 26 26 27 27 NB that they also (for directshow devices) had to adjust the rtbufsize in that example. … … 104 104 (the sync part tells it to try and stay realtime). 105 105 106 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 it might work for you). 106 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 it might work for you). 107 107 108 108 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 <input_here> "window title"" (this works especially well with -fflags nobuffer, though in my tests is still barely more latency than using mplayer -benchmark always). 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). … … 124 124 Also 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 [[Encode/H.264]] for a background). Or try a different output codec, or specify new parameters to your codec (for instance, a different profile or preset for [[Encode/H.264|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. 125 125 126 You can also set a lower output frame rate to of course decrease cpu usage. 126 You can also set a lower output frame rate to of course decrease cpu usage. 127 127 128 128 If 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. … … 156 156 == HTTP Live Streaming and Streaming with multiple bitrates == 157 157 158 FFmpeg supports splitting files (using "-f segment" for the output, see [http://ffmpeg.org/ffmpeg.html#segment_002c-stream_005fsegment_002c-ssegment segment muxer]) into time based chunks, useful for [http://en.wikipedia.org/wiki/HTTP_Live_Streaming HTTP live streaming] style file output. 158 FFmpeg supports splitting files (using "-f segment" for the output, see [http://ffmpeg.org/ffmpeg.html#segment_002c-stream_005fsegment_002c-ssegment segment muxer]) into time based chunks, useful for [http://en.wikipedia.org/wiki/HTTP_Live_Streaming HTTP live streaming] style file output. 159 159 160 160 How 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]. … … 175 175 176 176 The command line I use to pull the stream from port 5000, transcode it, and push it is: 177 ffmpeg -i 'udp://localhost:5000?fifo_size=1000000&overrun_nonfatal=1' -crf 30 -preset ultrafast -acodec aac - strict experimental -ar 44100 -ac 2 -b:a 96k -vcodec libx264 -r 25 -b:v 500k -f flv 'rtmp://<wowza server IP>/live/cam0'177 ffmpeg -i 'udp://localhost:5000?fifo_size=1000000&overrun_nonfatal=1' -crf 30 -preset ultrafast -acodec aac -ar 44100 -ac 2 -b:a 96k -vcodec libx264 -r 25 -b:v 500k -f flv 'rtmp://<wowza server IP>/live/cam0' 178 178 179 179 -i 'udp://localhost:5000?fifo_size=1000000&overrun_nonfatal=1' tells ffmpeg where to pull the input stream from. The parts after the ? are probably not needed most of the time, but I did need it after all. … … 183 183 -preset ultrafast as the name implies provides for the fastest possible encoding. If some tradeoff between quality and encode speed, go for the speed. This might be needed if you are going to be transcoding multiple streams on one machine. 184 184 185 -acodec aac sets the audio codec (internal AAC encoder) 186 187 -strict experimental allows use of some experimental codecs (the internal AAC encoder is experimental) 185 -acodec aac sets the audio codec (internal AAC encoder) 188 186 189 187 -ar 44100 set the audio sample rate … … 279 277 ffmpeg also has a "listen" option for rtmp so it may be able to receive a "straight" rtmp streams from a single client that way. 280 278 281 With tcp based streams you can probably use any formatting/muxer, but with udp 279 With tcp based streams you can probably use any formatting/muxer, but with udp you need to be careful and use a muxer that supports 'connecting anytime' like mpegts. 282 280 283 281 If you are forced to use udp (for instance you need to broadcast to a multicast port for whatever reason) then you may be able to avoid the packet loss by (sending less data or sending the same frames over and over again so they have a higher chance of being received). … … 290 288 291 289 {{{ 292 ffmpeg -f dshow 290 ffmpeg -f dshow -framerate 20 -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts udp://236.0.0.1:2000 293 291 }}} 294 292
