什么可能导致 DirectShow 推送源过滤器推送数据的速度比预期更快？
我有一个 DirectShow 推送源过滤器和一个 DirectShow 简单音频混合器过滤器，两者都是在 DSPACK 组件库的帮助下用 Delphi 6 编写的。在我的应用程序中，我手动构建过滤器图，对于引脚连接，我使用 IFilterGraph.ConnectDirect() 以避免 DirectShow 的“智能连接”技术的任何干扰。我将这两个过滤器用作我的程序内部的私有/未注册过滤器。
我构建的图表有一个捕获过滤器和我的推送源音频过滤器共享图表的头部位置。它们的输出引脚连接到我的简单音频混音器，后者支持多个输入连接。混频器强制其输入和输出引脚的所有连接与其构造函数中预设的媒体格式类型完全相同。在本例中，我使用的格式设置是 WAV 格式，采样率为 8000、每个样本 16 位和一个通道。请注意，我使用 DecideBufferSize() 将所有过滤器的缓冲区大小设置为 50 毫秒。这导致交付的缓冲区大小为 400 字节（200 个样本）。
捕获过滤器是我使用 DirectShow API 找到的外部 COM 对象。目前我正在将我的 VOIP 电话指定为设备 (Moniker)。由于某些奇怪的原因，我的推送源过滤器以恰好是捕获过滤器的 7 倍的速率泵出缓冲区。换句话说，对于从捕获过滤器接收的每个缓冲区，我的混合器过滤器从我的推送源过滤器获取 7 个缓冲区。我知道这一点是因为每次混合器过滤器获取缓冲区时我都会调试打印一行，并且我识别出作为缓冲区来源的过滤器。
我不知道捕获过滤器如何形成其时间戳，因为它是外部代码，但我希望它是通常的方案。我的推送源过滤器从零开始，每次调用 FillBuffer() 时都会按缓冲区表示的时间量递增 DirectShow 参考时间格式中的时间戳。
这是我的问题：
1）如果我手动构建图表，时间戳是否重要？即使您完全手动构建图形，DirectShow 是否会介于过滤器之间并以某种方式影响引脚写入（接收调用）的时间？
2）什么常见错误可能会导致过滤器过快地推出缓冲区，尽管图表中的媒体格式都是同质的？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 DirectShow 中，源/推送过滤器通常要么是实时的，要么是非实时的。两者都将数据注入到管道中，重要的区别在于实时过滤器会在数据生成后尽快流式传输数据、从管道外部（例如从网络）接收数据等。
非实时过滤器会推送尽可能多的数据尽其所能。播放 5 分钟长 MP3 文件的播放器？它准备一次注射全部五分钟。渲染器过滤器的任务是在没有更多可用缓冲区时阻止流传输并尊重呈现时间。因此，当源过滤器加载 100% 的缓冲区时，它就无法再推送任何内容，直到播放释放缓冲区为止。
此行为的重要部分是正确地为媒体样本添加时间戳。如果未能添加时间戳，渲染器将无法按时呈现数据，并且可能会显示/播放媒体太慢或太快。
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.