Live Sources

A live source, also called a push source, receives media 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 live-source filter should implement the IAMPushSource interface on its output pin. The Filter Graph Manager uses this interface to address two problems that can arise when a live source is rendered.

Latency

A filter's latency is the amount of time it takes the filter to process a sample. For live sources, the latency is determined by the size of the buffer used to hold samples. Suppose that the filter graph renders a video source with a latency of 33 milliseconds (ms), and an audio source with a latency of 500 ms. Each video frame arrives at the video renderer about 470 ms before the matching audio sample reaches the audio renderer. Unless the graph compensates for the difference, the audio and video will not be synchronized.

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 the IAMPushSource interface. For every filter that supports IAMPushSource, the graph calls IAMLatency::GetLatency to retrieve the filter's expected latency, and from these values determines the maximum expected latency. The graph then calls IAMPushSource::SetStreamOffset to give each source filter a stream offset, which that filter adds to the time stamps that it generates.

Rate Matching

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. If the renderer runs faster than the source, there will be gaps in the data. If the renderer runs slower than the source, samples will "bunch up," and at some point data will need to be dropped. Typically a live source cannot control its production rate, so instead the renderer matches clock rates with the source.

To perform rate matching, a renderer filter must set its clock according to another clock. The choice of clocks depends on how the source filter generates time stamps.

• If the source filter generates time stamps from a reference clock, and the renderer can access the same clock, then the renderer sets its clock to the reference clock. In this case, the source filter must not be using the renderer's own clock as the reference clock. Otherwise, the renderer will be matching rates with itself, possibly causing its clock to drift.
• If the source filter generates time stamps from a private clock—that is, a clock that the renderer cannot access—the renderer adjusts its clock rate based on the time stamps on incoming samples.
• If the source filter is not generating time stamps at all, the renderer calculates the source filter's delivery rate based on the number of bytes delivered and the bytes per second declared in the format block.

The renderer calls IAMPushSource::GetPushSourceFlags on the source filter to determine how the source filter sets its time stamps. Currently, only the audio renderer performs rate matching, because glitches in audio playback are more noticeable than glitches in video.