0

I have a DirectShow push source filter and a DirectShow simple audio mixer filter both written in Delphi 6 with the help of the DSPACK component library. In my app, I build a filter graph manually and for the pin connections I use IFilterGraph.ConnectDirect() to avoid any interference from DirectShow's "intelligent connection" technology. I am using both of those filters as private/unregistered filters internal to my program.

The graph I build has a capture filter and my push source audio filter sharing the head position of the graph. Their output pins are connected to my simple audio mixer, the latter supporting multiple input connections. The mixer forces all connections to its input and output pins to be the exact same media format type that is preset in its constructor. In this case the format setting I'm using is WAV format with a sample rate of 8000, 16 bits per sample, and one channel. Note, I am using DecideBufferSize() to set all filters to a buffer size of 50 milliseconds. This results in buffers being delivered that are 400 bytes (200 samples) large.

The capture filter is an external COM object that I find using the DirectShow API. Currently I am assigning my VOIP phone as the device (Moniker). For some strange reason my push source filter is pumping out buffers at a rate of exactly 7 times that of the capture filter. In other words, my mixer filter is getting 7 buffers from my push source filter for each buffer it receives from the capture filter. I know this because I debug print a line every time the mixer filter gets a buffer and I identify the filter that is the source of the buffer.

I don't know how the capture filter is forming its timestamps since it is external code, but I would expect its the usual scheme. My push source filter starts at zero and with each FillBuffer() call increments the timestamp in DirectShow reference time format by the amount of time the buffer represents.

Here are my questions:

1) Should the timestamps even matter if I am building the graph manually? Does DirectShow get in-between the filters and can somehow affect the timing of pin writes (Receive calls) even if you build the graph completely manually?

2) What common mistake could cause a filter to push out buffers too fast, despite a homogeneous media format all around the graph?

RRUZ
  • 134,889
  • 20
  • 356
  • 483
Robert Oschler
  • 14,153
  • 18
  • 94
  • 227

1 Answers1

3

In DirectShow source/push fitlers are normally either live or non-live. Both inject data into pipeline, and the important difference is that a live filter streams data as soon as possible, as soon as it generates, receives from outside of pipeline (such as from network) etc.

A non-live filter pushes as much data as it can. A fitler that plays 5 minutes long MP3 file? It is prepared to inject all five minutes at once. It is a task of a renderer filter to block streaming when no more buffers available and to honor presentation time. So when source filter loads 100% of buffers, it just cannot push anything any more until buffers are released by playback.

The important part of this behavior is to timestamp media samples correctly. If one fails to time stamp, the renderer would not be able to present data on time, and could be showing/playing media too slow, or too fast.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • Thanks @Roman R. So perhaps my push source filter logic for generating buffers is wrong? My push source filter is essentially an "input jack" for custom audio from other "live" streaming sources that I need to push into the DirectShow stream, like from a Skype call for example. When there is no audio data needing to be pushed, I return a buffer of empty data. Should I return S_FALSE when I am out of data and awaiting new data instead of empty buffers? If so, that still leaves the exact 7 to 1 ratio of buffers as a curious symptom of my filter graph, what would cause that? – Robert Oschler Nov 19 '11 at 07:46
  • Forgot to ask. Should I offset my timestamps to the system clock? Or is it enough to start from 0 when streaming starts and just keep incrementing from there reliably? I would think that renderers must do some kind of relative timestamp calculatings on a per-stream asis, but perhaps it doesn't work that way and I do need to work off the system clock? – Robert Oschler Nov 19 '11 at 07:58
  • 1
    You start from zero, which corresponds to reference clock time at the moment of running the graph. Renderers are converting relative stream time to time compatible with reference clock time. – Roman R. Nov 19 '11 at 08:20
  • Thanks. Any comment about my comment about returning S_FALSE from my push source filter when I get a FillBuffer() call and I don't have any data to "push" (instead of returning a buffer full of zeroes)? – Robert Oschler Nov 19 '11 at 15:02
  • 1
    If you step out from `FillBuffer` with debugger you will see that `S_FALSE` is nothing but end of stream. Return it once and the whole streaming will stop with sending `EOS` notification. – Roman R. Nov 19 '11 at 15:25
  • Yes, true. Then should I return a zero length buffer instead with S_OK until I have new data? I don't think blocking inside of FillBuffer() is a good idea until I get new data for my push source filter, or is it? Or how about sending a custom AM_STREAM_CONTROL notification? – Robert Oschler Nov 19 '11 at 15:29
  • 1
    It is, you are expected to block since returning from `FillBuffer` is an indication of new buffer availability or end of stream. You can unblock to send notification also, or you can also send it on another thread. – Roman R. Nov 19 '11 at 15:43
  • Ok, will do. I do have another strategy I'm considering and would like you to comment on it if you don't mind: http://stackoverflow.com/questions/8198768/are-there-any-modern-windows-pcs-that-dont-have-at-least-one-directshow-capture – Robert Oschler Nov 20 '11 at 04:35