|Microsoft DirectX 9.0|
A live source, also called a push source, receives data in real time. Examples include video capture and network broadcasts. In general, a live source cannot control the rate at which data arrives.
A filter is considered to be a live source if either of the following are true:
If a live source filter provides a clock, the Filter Graph Manager will prefer that clock when it chooses the graph reference clock. See Reference Clocks for more information.
Live sources can be synchronized through the IAMPushSource interface. The Filter Graph Manager does not synchronize live sources unless the application enables synchronization by calling the IAMGraphStreams::SyncUsingStreamOffset method. If synchronization is enabled, the Filter Graph Manager queries each source filter for IAMPushSource. If the filter supports IAMPushSource, the Filter Graph Manager calls IAMLatency::GetLatency to retrieve the filter's expected latency. (The IAMPushSource interface inherits IAMLatency.) From the combined latency values, the Filter Graph Manager determines the maximum expected latency in the graph. It then calls IAMPushSource::SetStreamOffset to give each source filter a stream offset, which that filter adds to the time stamps that it generates.
This method is intended primarily for live preview. However, note that a preview pin on a live capture device (such as a camera) does not set time stamps on the samples it delivers. Therefore, to use this method with a live capture device, you must preview from the capture pin. For more information, see DirectShow Video Capture Filters.
Currently the IAMPushSource interface is supported by the VFW Capture filter and the Audio Capture filter.
If a renderer filter schedules samples using one reference clock, but the source filter produces them using a different clock, glitches can occur in playback. The renderer might run faster than the source, causing gaps in the data. Or it might run slower than the source, causing samples to "bunch up," until at some point the graph will drop samples. Typically, a live source cannot control its production rate, so instead the renderer should match rates with the source.
Currently, only the audio renderer performs rate matching, because glitches in audio playback are more noticeable than glitches in video. To perform rate-matching, the audio renderer must select something against which it will match rates. It uses the following algorithm:
The reason for the last case is the following: If the audio renderer is the reference clock, and the source filter is using the same clock to generate time stamps, then the audio renderer cannot match rates against the time stamps. If it did, in effect it would be trying to match rates with itself, which could cause the clock to drift. Therefore, in this case the renderer matches the rate of incoming audio data.