Changes between Version 23 and Version 24 of DirectShow


Ignore:
Timestamp:
Mar 26, 2014, 12:47:47 AM (5 years ago)
Author:
rogerdpack
Comment:

mention audio_buffer_size usefulness.

Legend:

Unmodified
Added
Removed
Modified
  • DirectShow

    v23 v24  
    7474See 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.
    7575
    76 == Buffering ==
     76== Buffering/Latency ==
    7777
    78 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.
     78By 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.
    7979
    8080See [[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.
     81
     82There is also an option audio_buffer_size.
     83Basically 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.
    8184
    8285== !TroubleShooting ==