Changes between Version 67 and Version 68 of StreamingGuide
- Timestamp:
- Mar 8, 2014, 3:19:24 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
StreamingGuide
v67 v68 11 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 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. 12 12 13 Also avoid the -sameq flag, which means "same quantizer" not same quality, and probably should be avoided.14 15 13 == Setting == 16 14 … … 19 17 {{{ 20 18 $ ffmpeg -y -loglevel warning -f dshow -i video="screen-capture-recorder" -vf crop=690:388:136:0 -r 30 -s 962x388 -threads 2 -vcodec libx264 -vpre baseline -vpre my_ffpreset -f flv rtmp:///live/myStream.sdp 21 22 Here is my FFmpeg preset (libx264-my_ffpreset.ffpreset): 19 }}} 20 21 with his custom FFmpeg preset (libx264-my_ffpreset.ffpreset): 22 {{{ 23 23 coder=1 24 24 flags2=+wpred+dct8x8 … … 38 38 39 39 {{{ 40 ffmpeg -f dshow -i video="Virtual-Camera" -vcodec libx264 -tune zerolatency 41 -b 900k -f mpegts udp://10.1.0.102:1234 40 ffmpeg -f dshow -i video="Virtual-Camera" -vcodec libx264 -tune zerolatency -b 900k -f mpegts udp://10.1.0.102:1234 42 41 }}} 43 42 44 43 And here is what another person [http://web.archiveorange.com/archive/v/DUtyPSinPqSIxjhedGQd did]: 45 44 {{{ 46 ffmpeg -f dshow -i video="screen-capture-recorder":audio="Stereo Mix (IDT High 47 Definition" -vcodec libx264 -preset ultrafast -tune zerolatency -r 10 48 -async 1 -acodec libmp3lame -ab 24k -ar 22050 -bsf:v h264_mp4toannexb 49 -maxrate 750k -bufsize 3000k -f mpegts udp://192.168.5.215:48550 45 ffmpeg -f dshow -i video="screen-capture-recorder":audio="Stereo Mix (IDT High Definition" \ 46 -vcodec libx264 -preset ultrafast -tune zerolatency -r 10 -async 1 -acodec libmp3lame -ab 24k -ar 22050 -bsf:v h264_mp4toannexb \ 47 -maxrate 750k -bufsize 3000k -f mpegts udp://192.168.5.215:48550 50 48 }}} 51 49 52 NB that they also (for directshow devices) had to adjust the rtbufsize in that example. Also note that newer version of FFmpeg may need a different syntax for specifying preset/tune.53 54 You can see a description of what some of these means, (for example bufsize, bitrate settings) in the [ x264EncodingGuide].50 NB that they also (for directshow devices) had to adjust the rtbufsize in that example. 51 52 You can see a description of what some of these means, (for example bufsize, bitrate settings) in the [[x264EncodingGuide]]. 55 53 56 54 Here is how you stream to twitch.tv or similar services (rtmp protocol), using ffmpeg 1.0 or ffmpeg-git (tested on 2012-11-12), this is also for pulseaudio users: … … 106 104 [http://stackoverflow.com/a/12085571/32453 Here] is a list of some other ideas to try (using VBR may help, etc.) 107 105 108 == C pu usage/File size ==109 110 In 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.106 == CPU usage / File size == 107 108 In 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 for the same quality. 111 109 112 110 Basically, the easiest way to save cpu is to decrease the input frame rate/size, or decrease the output frame rate/size. … … 156 154 See [[Creating multiple outputs]]. Basically, you may only be able to accept from a webcam or some other source from at most one process, in this case you'll need to "split" your output if you want to save it and stream it simultaneously. Streaming and saving simultaneously (and only encoding once) can also save cpu. 157 155 158 == Transcoding /repeating ==159 160 F fmpeg can also receive from "a source" (for instance live or udp) and then transcode and re-broadcast the stream.156 == Transcoding / repeating == 157 158 FFmpeg can also receive from "a source" (for instance live or UDP) and then transcode and re-broadcast the stream. 161 159 162 160 One mailing list user wrote this, quote: … … 207 205 If you want to stream "from one computer to another", you could start up a server on one, and then stream from FFmpeg to that server, then have the client connect to that server (server could either be on client or server side computers). Or you could do a point to point type stream, like: 208 206 209 ffmpeg -i INPUT -acodec libmp3lame -ar 11025 --f rtp rtp://host:port 210 where host is the receiving IP. Then receive the stream using VLC or ffmpeg from that port (since rtp uses UDP, the receiver can start up any time). 207 {{{ 208 ffmpeg -i INPUT -acodec libmp3lame -ar 11025 --f rtp rtp://host:port 209 }}} 210 where host is the receiving IP. Then receive the stream using VLC or ffmpeg from that port (since rtp uses UDP, the receiver can start up any time). 211 211 212 212 or 213 213 214 ffmpeg -i INPUT -f mpegts udp://host:port 214 {{{ 215 ffmpeg -i INPUT -f mpegts udp://host:port 216 }}} 215 217 216 218 If 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). 217 219 218 Another 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). 219 220 One option to use tcp is like this: 221 222 ffmpeg -i INPUT -f mpegts tcp://host:port 220 Another 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). 221 222 One option to use TCP is like this: 223 224 {{{ 225 ffmpeg -i INPUT -f mpegts tcp://host:port 226 }}} 223 227 224 228 which I would guess will try and (as a client) establish a connection do that host on that port (assuming it has a server waiting for the incoming connection). You could receive it like this: 225 229 226 ffmpeg -i tcp://local_hostname:port?listen 230 {{{ 231 ffmpeg -i tcp://local_hostname:port?listen 232 }}} 227 233 228 234 (basically, one side needs to specify "listen" and the other needs to not to). 229 235 230 236 To use with mplayer as a receiver it would be like 231 ffmpeg -i ... -f mpegts "tcp://127.0.0.1:2000" 237 238 {{{ 239 ffmpeg -i ... -f mpegts "tcp://127.0.0.1:2000" 240 }}} 241 232 242 and on the mplayer side 233 mplayer ... ffmpeg://tcp://127.0.0.1:2000?listen 243 244 {{{ 245 mplayer ... ffmpeg://tcp://127.0.0.1:2000?listen 246 }}} 234 247 235 248 (start mplayer first) 236 249 237 Another option is to use rtp (which by default uses udp) but by specifying it use tcp: 238 239 ffmpeg -i input -f rtsp -rtsp_transport tcp rtsp://localhost:8888/live.sdp [http://ffmpeg.org/ffmpeg.html#rtsp lists the option] 250 Another option is to use RTP (which by default uses UDP) but by specifying it use TCP: 251 252 {{{ 253 ffmpeg -i input -f rtsp -rtsp_transport tcp rtsp://localhost:8888/live.sdp 254 }}} 255 256 (For meanings of options see [http://ffmpeg.org/ffmpeg-protocols.html#rtsp official documentation]. 240 257 241 258 Then you may receive it like this (ffplay or ffmpeg): 242 259 243 ffplay -rtsp_flags listen rtsp://localhost:8888/live.sdp?tcp # ending ?tcp may not be needed -- you will need to start the server up first, before the sending client 260 {{{ 261 ffplay -rtsp_flags listen rtsp://localhost:8888/live.sdp?tcp 262 # ending "?tcp" may not be needed -- you will need to start the server up first, before the sending client 263 }}} 244 264 245 265 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. … … 255 275 server: 256 276 277 {{{ 257 278 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 279 }}} 258 280 259 281 client: 260 282 261 mplayer -demuxer +mpegts -framedrop -benchmark ffmpeg://udp://236.0.0.1:2000?fifo_size=100000&buffer_size=10000000 (see note above about linux needing fifo_size as well as buffer_size). 283 {{{ 284 mplayer -demuxer +mpegts -framedrop -benchmark ffmpeg://udp://236.0.0.1:2000?fifo_size=100000&buffer_size=10000000 285 # (see note above about linux needing fifo_size as well as buffer_size). 286 }}} 262 287 263 288 == External links == 264 289 265 This [http://sonnati.wordpress.com/2011/08/30/ffmpeg-–-the-swiss-army-knife-of-internet-streaming-–-part-iv/ tutorial] is on FFmpeg streaming. 290 * [http://sonnati.wordpress.com/2011/08/30/ffmpeg-–-the-swiss-army-knife-of-internet-streaming-–-part-iv/ Fabio Sonnati's tutorial on streaming with FFmpeg]
