Changes between Version 57 and Version 58 of StreamingGuide
- Oct 21, 2013, 10:41:54 PM (3 years ago)
v57 v58 2 2 [[PageOutline(2, Contents)]] 3 3 4 FFmpeg can basically stream through one of two ways: It either streams to a some "other server", which re streams for it, or it can stream via UDP/TCP directly to some destination receiver, or alternatively directly to a multicast destination. 4 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/TCP directly to some destination receiver, or alternatively directly to a multicast destination. 5 5 6 6 Servers which can receive from FFmpeg (to restream) include [[Streaming media with ffserver|ffserver]] (linux only, though with cygwin it might work on windows), 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] or [https://en.wikipedia.org/wiki/List_of_streaming_media_systems#Servers various others]. 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). … … 9 9 == The -re flag == 10 10 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 want to play a video file, but at realtime, then use this. My guess is you typically don't want to use this flag when streaming from a live device. 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 want. 12 12 13 13 Also avoid the -sameq flag, which means "same quantizer" not same quality, and probably should be avoided. … … 84 84 You might get less latency by using one of the "point to point" protocols described in this document, at well. You'd lose the benefit of having a server, of course. 85 85 86 NB that if you are sending to UDP or what not, that a client may have to wait until the next i-frame to be able to start receiving the stream, so the GOP setting (- i) i-frame interval will have an effect on how quickly they can connect. Setting it to a lower number means it will use more bandwidth, but clients will be able to connectmore quickly (the default for x264 is 250--so for 30 fps that means an i-frame only once every 10 seconds or so). So it's a tradeoff if you adjust it. This does not affect actual latency (just connection time) since the client can still display frames very quickly after and once it has received its first i-frame. 86 NB that if you are sending to UDP or what not, that a client may have to wait until the next i-frame to be able to start receiving the stream, so the GOP setting (-. 87 87 88 88 Note also that using dshow's "rtbufsize" has the unfortunate side effect of allowing frames to "buffer" while it is waiting on encoding of previous frames, or waiting for them to be sent on the wire. This means that if you use a higher value at all, it can cause/introduce added latency if it ever gets used (but if used, can be helpful for other aspects, like transmitting more frames overall).