GMFBridge DirectShow 过滤器 SetLiveTiming 效果

Question

我正在使用出色的 GMFBridge directshow family of filters 效果很好，让我可以关闭视频记录图并打开一个新图，而不会丢失数据。

我的原始源图是从标准视频和音频输入中捕获实时视频。

在名为 SetLiveTiming() 的 GMFBridgeController 过滤器上有一个未记录的方法。根据名称，我认为如果我们像我的情况一样从 Live 图表（而不是从文件）中捕获，则应将其设置为 true。我将此值设置为 true，一切都按预期工作

相同的捕获硬件允许我捕获直播电视信号（在我的例子中是 ATSC），因此我使用 BDA 架构过滤器创建了一个新版本的图表，用于调整目的。一旦数据从 MPEG 解复用器流出，图形的其余部分实际上与我的原始图形相同。

但是，这次我的复用图（在桥的另一边）没有工作。数据从 BridgeSource 过滤器（视频和音频）流出并到达 MP4 多路复用器过滤器，但是 没有数据从多路复用器输出流向 FileWriter 过滤器。

几个小时后，我将问题追溯到 SetLiveTiming() 设置。我将其关闭 ~~，一切开始按预期工作。~~ 并且多路复用器过滤器开始生成输出文件，但是，音频未与视频同步。

谁能告诉我 SetLiveTiming() 设置的真正目的，也许，为什么一个图形在启用该设置的情况下工作，而另一个却失败了？

更新

我设法编译了 GMFBridge 项目，~~似乎由于时间戳计算为负，过滤器正在丢弃每个接收到的样本。然而，我对启用过滤器日志后看到的结果感到非常困惑。~~

更新 2： 丢弃的样本是通过我启动辅助（多路复用器）图的方式引入的。我使用 SampleGrabber（因此在流线程内）作为触发点检查了一个示例，并使用 Task.Run() .NET 调用来实例化多路复用器图。这不知何故弄乱了时钟，我在未来结束了一个 'reference start point' - 当桥试图通过减去参考起点来修复时间戳时，它产生了一个负时间戳 - 一旦我更正了这个并从中生成了图表应用程序线程（通过发布图形事件），问题已解决。

不幸的是，我的多路复用视频（无论 SetLiveTiming() 设置如何）仍然不同步。

我读到 GMFBridge filter can have trouble when the InfTee filter is being used，但是，我认为我的图表不应该有这个问题，因为没有 InfTee 过滤器的实例直接连接到桥接接收器。

这是我当前的源图：

                                                                   -->[TIF]
                                                                  |
 [NetworkProvider]-->[DigitalTuner]-->[DigitalCapture]-->[demux]--|-->[Mpeg Tables]
                                                                  |
                                                                  |-->[lavAudioDec]-->[tee]-->[audioConvert]-->[sampleGrabber]-->[NULL]
                                                                  |                        |
                                                                  |                        |
                                                                  |                         ->[aacEncoder]----------------
                                                                  |                                                       |--->[*Bridge Sink*]
                                                                   -->[VideoDecoder]-->[sampleGrabber]-->[x264Enc]--------

这是我的复用器图：

                      video  
 ...  |bridge source|-------->[MP4 muxer]--->[fileWriter]
             |                     ^
             |        audio        |
              ---------------------

图中的所有样本抓取器都是只读的。 如果我在没有桥接的情况下多路输出文件（通过将多路复用器放在捕获图上），输出文件保持同步， （这不是真的，输出-of-sync 问题是由 H264 编码器中的延迟设置引入的） 但是我无法避免在释放当前捕获图和运行新捕获图之间损失几秒钟（使用更新的文件名）

更新 3：

几天前我无意中引入了不同步问题，当时我关闭了 x264vfw 编码器中的 "Zero-latency" 设置。我没有注意到这个设置也使我已经工作的图表不同步，我在责怪桥接过滤器。

总而言之，我把事情搞砸了：

从应用程序以外的线程启动多路复用器图线程（处理图形事件循环的线程）。
上游过滤器中的延迟开关可能会延迟混合器无法跟上的事情太多了。

Answer 1

作者评论：

// using this option, you can share a common clock 
// and avoid any time mapping (essential if audio is in mux graph)
[id(13), helpstring("Live Timing option")]
HRESULT SetLiveTiming([in] BOOL bIsLiveTiming);

该方法启用了一种处理实时数据的特殊操作模式。在这种模式下，采样时间在图形之间转换为相对于各自的时钟开始时间。否则，默认模式是期望随着图形更改将时间戳重置为零。

GMFBridge DirectShow 过滤器 SetLiveTiming 效果

GMFBridge DirectShow filter SetLiveTiming effect

directshow