Changes between Version 23 and Version 24 of DirectShow

Timestamp:

Mar 25, 2014, 10:47:47 PM (12 years ago)

Author:

Roger Pack

Comment:

mention audio_buffer_size usefulness.

DirectShow

@@ -74 +74 @@
 See the [http://ffmpeg.org/ffmpeg-devices.html#dshow FFmpeg dshow input device documentation] for a list of more dshow options you can specify. For instance you can decrease latency on audio devices, or specify a video by "index" if two have the same name, etc.
 
-== Buffering ==
+== Buffering/Latency ==
 
-By default FFmpeg captures frames from the input, and then does whatever you told it to do, for instance, re-encoding them and saving them to an output file.  By default if it receives a frame "too early" (while the previous frame isn't finished yet), it will discard that frame, so that it can keep up the the real time input.  You can adjust this by setting the `-rtbufsize` parameter, though note that if your encoding process can't keep up, eventually you'll still start losing frames just the same (and using it at all can introduce a bit of latency).  It may be helpful to still specify some buffer, however, otherwise frames may be needlessly dropped.
+By default FFmpeg captures frames from the input, and then does whatever you told it to do, for instance, re-encoding them and saving them to an output file.  By default if it receives a video frame "too early" (while the previous frame isn't finished yet), it will discard that frame, so that it can keep up the the real time input.  You can adjust this by setting the `-rtbufsize` parameter, though note that if your encoding process can't keep up, eventually you'll still start losing frames just the same (and using it at all can introduce a bit of latency).  It may be helpful to still specify some size of buffer, however, otherwise frames may be needlessly dropped possibly.
 
 See [[StreamingGuide]] for some tips on tweaking encoding (sections latency and cpu usage).  For instance, you could save it to a very fast codec, then re-encode it later.
+
+There is also an option audio_buffer_size.
+Basically if you're capturing from a live mic, the default behavior for this hardware device is to "buffer" 500ms (or 1000ms) worth of data, before it starts sending it down the pipeline.  This can introduce startup latency, so setting this to 50ms (msdn suggests 80ms) may be a better idea here.  The timestamps on the data will be right, it will just have added (unneeded) latency if you don't specify this.
 
 == !TroubleShooting ==