DirectShow Encoding 丢帧补偿答案

【问题标题】：DirectShow Encoding dropped frames compensationDirectShow Encoding 丢帧补偿
【发布时间】：2015-10-17 07:16:13
【问题描述】：

我目前在 GraphEdit 中有一个 DirectShow 图表，如下所示：

      Source(USB WebCam) -> Encoder -> Mux -> File Writer

但是，如果源在录制过程中丢帧，编码器将不会补偿该损失。这意味着如果我录制了 30 秒的视频，并丢掉了 20% 的帧（例如），则生成的视频将以 24 秒的视频结束。

这意味着视频中的所有内容都将被加速 1.2 倍，这是绝对不可接受的，我已经使用 VLC Player 和 WMP 重播了视频 - 结果相同。就好像图中的编码器（？）或其他一些过滤器不关心丢失的帧。

我用来重现此问题的编码器是 WMV9 和第三方 H264 过滤器。

即使在录制过程中 CPU 使用率非常高，我确实需要能够处理和补偿丢帧，这样视频的时间线才不会突然停止有意义。是否有一个过滤器可以处理这个问题，还是我需要在图表中自己做一些事情？这里到底发生了什么？

非常感谢。

编辑： 我尝试使用Asf Writer 过滤器和音频源构建一个更简单的图表，如附图所示。但是，由于我的捕获源（相机）丢失帧，最终视频最终会出现很大的同步问题，这意味着音频长度比视频长得多并且不同步（而不是补偿）我本来希望看到视频捕捉到直到音频。

【问题讨论】：

【解决方案1】：

如果您最终得到一个持续时间较短的文件（按丢弃帧的长度），则问题可能是管道中的一个过滤器存在错误。

可能导致此行为的潜在问题分为两类：

多路复用器会忽略丢帧并收缩结果文件
多路复用器上游的过滤器之一是从帧中删除时间戳，这使得无法“看到”丢弃的帧并且过滤器退回（一些多路复用器会因错误而中止）以假设连续视频序列
- 如果您使用网络摄像头的预览输出而不是捕获输出，也可能会出现此问题

【讨论】：

你好 Roman，我已经用编辑更新了我的问题 - 你能看一下吗？在这样的基本场景中，视频和音频怎么会不同步？即使我丢帧，它是否应该用黑帧（或类似的）补偿丢失的帧，以使视频和音频保持相同的长度并且不会不同步？我究竟做错了什么？ 编辑：应该注意的是，我的结束图不会包含音频源，这只是为了测试丢帧。
我怀疑您的视频源提供的帧没有时间戳，或者时间戳不正确。您可以使用 GraphStudioNext 的内置分析器过滤器来检查帧附加了哪些时间，帧是否被连续标记或是否有关于跳过的信息。
我已经附加了分析器过滤器，据我所知，信息看起来是正确的。我真的不知道我的下一步是什么，我附上了分析器信息的 sn-p 以便您查看。 Attached Picture
快照看起来像“无滴”连续馈送，速度约为 57 毫秒/帧。当出现帧丢失时，您应该会看到时间戳中的间隙。你看到了吗？
第五列“帧开始时间”应该有一个匹配的时间戳间隔。它没有它并显示连续进给。看起来像源过滤器（或任何时间戳帧）错误。这与您描述的持续时间缩短并且生成的文件没有丢帧痕迹的症状相匹配。如果问题早在源过滤器中就发生了，那么显然没有其他过滤器可以修复或补偿该问题。看来你要自己动手了。