我正在开发一个源过滤器，通过DirectShow图表提供我们软件捕获的视频/音频。我让视频工作相对轻松，但我现在试图添加音频输出引脚被证明是一个相当大的挑战。我遇到的具体问题是：音频渲染器是否会在播放声音时修改实际参考时钟？
我看到非常生涩的视频播放。下面是一个日志文件的大块，它看起来像偶尔参考时钟只是“停止”而系统时间一直在滴答作响。这有意义吗？
我应该提到的一件事是音频样本是u-Law 8 kHz 8-bit，每个数据包正好是120 ms。这就是复杂性：当我们从网络接收音频数据时，它没有时间信息，因此我们的软件会在收到数据包时分配一个采样时间戳。视频样本由原始源标记，因此它们是准确的。如果我忽略音频采样时间并简单地分配120 ms的采样时间戳，视频将平滑播放。问题是我还没有完全理解参考时钟和音频/视频渲染器之间的完整关系，真正让我感到困惑的是我们有另一个类似的源滤波器，它可以播放相同的数据而不会抖动视频（它没有记录，我没有机会添加任何内容以查看在这种情况下是否也修改了参考时钟。）
这是日志的一部分：
Sys Clock (delta) StreamTime (delta) Drift between clocks:
------------------------------------------------------------------
15:54:40.755 (0.005) 1.838 (0.005) 0.000
15:54:40.761 (0.006) 1.844 (0.006) 0.000
15:54:40.889 (0.128) 1.972 (0.128) 0.000
15:54:40.894 (0.005) 1.977 (0.005) 0.000
15:54:40.899 (0.005) 1.982 (0.005) 0.000
15:54:40.903 (0.004) 1.986 (0.004) 0.000
15:54:40.931 (0.028) 2.014 (0.028) 0.000
15:54:40.936 (0.005) 2.019 (0.005) 0.000
15:54:41.019 (0.083) 2.080 (0.061) 0.022
15:54:41.175 (0.156) 2.080 (0.000) 0.178
15:54:41.181 (0.006) 2.080 (0.000) 0.184
15:54:41.190 (0.009) 2.080 (0.000) 0.193
15:54:41.197 (0.007) 2.080 (0.000) 0.200
15:54:41.202 (0.005) 2.080 (0.000) 0.205
15:54:41.210 (0.008) 2.080 (0.000) 0.213
15:54:41.216 (0.006) 2.080 (0.000) 0.219
15:54:41.220 (0.004) 2.080 (0.000) 0.223
15:54:41.313 (0.093) 2.080 (0.000) 0.316
15:54:41.317 (0.004) 2.080 (0.000) 0.320
15:54:41.408 (0.091) 2.116 (0.036) 0.375
15:54:41.412 (0.004) 2.120 (0.004) 0.375
15:54:41.432 (0.020) 2.140 (0.020) 0.375
15:54:41.436 (0.004) 2.144 (0.004) 0.375
15:54:41.439 (0.003) 2.147 (0.003) 0.375
答案 0 :(得分：0)
当声卡在图表中时，通常选择它作为参考时钟。其他过滤器（包括视频渲染器）使用它来确定何时显示样本。并行使用系统时钟不是一个好主意;你应该使用相同的参考时钟来同步。
如果您知道音频样本的实际长度，并且您确定不会丢失任何音频样本（例如，您使用TCP而不是UDP），那么只需分配连续的120 ms时间间隔就是一个很好的解决方案。当样本从网络到达时从系统时钟中获取时间戳是一个坏主意，因为它会引入由网络行为引起的随机时移 - 你永远不知道网络数据包需要多长时间。
如果您有两个过滤器并希望了解其时间差异，则可以安装GraphEditPlus，在过滤器之前/之后插入样本抓取器，右键单击它并选择“观看抓取的样本”。它将显示所有时间戳和其他信息。此外，您可以右键单击图形窗口并选择“查看事件日志”。它也可以提供帮助。
答案 1 :(得分：0)
要了解图形中的哪个时钟用作参考时钟并查看此时钟相对于本地CPU时钟的漂移（通过QueryPerformanceCounter），请查看DirectShow过滤器 ShowClk.ax