Changes between Version 69 and Version 70 of StreamingGuide


Ignore:
Timestamp:
Mar 22, 2014, 12:48:58 AM (5 years ago)
Author:
rogerdpack
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v69 v70  
    8686You 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.
    8787
    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).
     88Note 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.
    8989
    9090There is also apparently an option -fflags nobuffer which might possibly help, usually for receiving streams [http://ffmpeg.org/ffmpeg.html#Format-AVOptions reduce latency].