Changes between Version 67 and Version 68 of StreamingGuide


Ignore:
Timestamp:
Mar 8, 2014, 5:19:24 AM (5 years ago)
Author:
Timothy_Gu
Comment:

Fix some of the crap

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v67 v68  
    1111The 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
    13 Also avoid the -sameq flag, which means "same quantizer" not same quality, and probably should be avoided.
    14 
    1513== Setting ==
    1614
     
    1917{{{
    2018$ 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
     21with his custom FFmpeg preset (libx264-my_ffpreset.ffpreset):
     22{{{
    2323coder=1
    2424flags2=+wpred+dct8x8
     
    3838
    3939{{{
    40 ffmpeg -f dshow -i video="Virtual-Camera" -vcodec libx264 -tune zerolatency
    41 -b 900k -f mpegts udp://10.1.0.102:1234
     40ffmpeg -f dshow -i video="Virtual-Camera" -vcodec libx264 -tune zerolatency -b 900k -f mpegts udp://10.1.0.102:1234
    4241}}}
    4342
    4443And here is what another person [http://web.archiveorange.com/archive/v/DUtyPSinPqSIxjhedGQd did]:
    4544{{{
    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
     45ffmpeg -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
    5048}}}
    5149
    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].
     50NB that they also (for directshow devices) had to adjust the rtbufsize in that example.
     51
     52You can see a description of what some of these means, (for example bufsize, bitrate settings) in the [[x264EncodingGuide]].
    5553
    5654Here 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:
     
    106104[http://stackoverflow.com/a/12085571/32453 Here] is a list of some other ideas to try (using VBR may help, etc.)
    107105
    108 == Cpu 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
     108In 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.
    111109
    112110Basically, the easiest way to save cpu is to decrease the input frame rate/size, or decrease the output frame rate/size.
     
    156154See [[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.
    157155
    158 == Transcoding/repeating ==
    159 
    160 Ffmpeg can also receive from "a source" (for instance live or udp) and then transcode and re-broadcast the stream.
     156== Transcoding / repeating ==
     157
     158FFmpeg can also receive from "a source" (for instance live or UDP) and then transcode and re-broadcast the stream.
    161159
    162160One mailing list user wrote this, quote:
     
    207205If 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:
    208206
    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{{{
     208ffmpeg -i INPUT -acodec libmp3lame -ar 11025 --f rtp rtp://host:port
     209}}}
     210where 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).
    211211
    212212or
    213213
    214    ffmpeg -i INPUT -f mpegts udp://host:port
     214{{{
     215ffmpeg -i INPUT -f mpegts udp://host:port
     216}}}
    215217
    216218If 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).
    217219
    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
     220Another 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
     222One option to use TCP is like this:
     223
     224{{{
     225ffmpeg -i INPUT -f mpegts tcp://host:port
     226}}}
    223227
    224228which 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:
    225229
    226   ffmpeg -i tcp://local_hostname:port?listen
     230{{{
     231ffmpeg -i tcp://local_hostname:port?listen
     232}}}
    227233
    228234(basically, one side needs to specify "listen" and the other needs to not to).
    229235
    230236To use with mplayer as a receiver it would be like
    231   ffmpeg -i ... -f mpegts "tcp://127.0.0.1:2000"
     237
     238{{{
     239ffmpeg -i ... -f mpegts "tcp://127.0.0.1:2000"
     240}}}
     241
    232242and on the mplayer side
    233   mplayer ... ffmpeg://tcp://127.0.0.1:2000?listen
     243
     244{{{
     245mplayer ... ffmpeg://tcp://127.0.0.1:2000?listen
     246}}}
    234247
    235248(start mplayer first)
    236249
    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]
     250Another option is to use RTP (which by default uses UDP) but by specifying it use TCP:
     251
     252{{{
     253ffmpeg -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].
    240257
    241258Then you may receive it like this (ffplay or ffmpeg):
    242259
    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{{{
     261ffplay -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}}}
    244264
    245265ffmpeg also has a "listen" option for rtmp so it may be able to receive a "straight" rtmp streams from a single client that way.
     
    255275server:
    256276
     277{{{
    257278ffmpeg -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}}}
    258280
    259281client:
    260282
    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{{{
     284mplayer -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}}}
    262287
    263288== External links ==
    264289
    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]