Changes between Version 69 and Version 70 of StreamingGuide
- Timestamp:
- Mar 21, 2014, 10:48:58 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
StreamingGuide
v69 v70 86 86 You can also (if capturing from a live source) increase frame rate to decrease latency (which affects throughput and also i-frame frequency, of course). This obvious sends packets more frequently, so (with 5 fps, you introduce at least a 0.2s latency, with 10 fps 0.1s latency) but it also helps clients to fill their internal buffers, etc. more quickly. 87 87 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).88 Note also that using dshow's "rtbufsize" has the unfortunate side effect of sometimes allowing frames to "buffer" while it is waiting on encoding of previous frames, or waiting for them to be sent over 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 consistently etc. so YMMV). Almost certainly if you set a very large value for this, and then see the "buffer XX% full! dropping!" message, you are introducing latency. 89 89 90 90 There is also apparently an option -fflags nobuffer which might possibly help, usually for receiving streams [http://ffmpeg.org/ffmpeg.html#Format-AVOptions reduce latency].
