1

我编写了一个实时推送过滤器，它获取包含 h.264 视频和 aac 音频的 mpeg-ts 流。我设置了一个 directshow 管道并配置了输出引脚。我可以渲染 h.264 流，但我在渲染中得到了伪像，从这个屏幕截图中可以看出，当使用 videotestsrc 和“ball”模式从 gstreamer 流式传输时。这此屏幕截图应仅包含黑色背景上的一个白点。另外两个是动画播放时出现的“剩菜”。

如果我流式传输 MPEG-2 并相应地更改管道，则该模式将无错误地呈现。我尝试使用msdn 上描述的设置来配置 pin，两者都使用 H264 和 AVC1 显式提供序列头等。我仍然得到同样的文物。

一件有趣的事情是，伪影大多以与 I-Frame 到达相同的频率出现，如果我们只发送 I-Frame (key-int-max=1)，伪影就会完全消失。

此外，当 I 帧间隔为 60 时，即每 2 秒，错误似乎出现在图像的上半部分。当我们每隔一帧更改为一个 I-Frame (key-int-max=2) 时，伪影仅出现在图像顶部的窄条中。

以下 gstreamer 管道生成了视频流：

videotestsrc live-source=true pattern=ball ! video/x-raw-yuv,format=(fourcc)I420,width=1366,height=768,framerate=30/1 ! timeoverlay halign=left valign=bottom shaded-background=true ! x264enc bitrate=4096 tune=zerolatency ! h264parse ! queue ! mux. audiotestsrc wave=ticks volume=0.2 ! voaacenc ! mux. mpegtsmux name=mux ! udpsink host=<ip> port=<port>

这是管道的样子： 管道

本例中的配置是majortype = MEDIATYPE_Video，subtype = MEDIASUBTYPE_H264，formattype = FORMAT_MPEG2Video。没有专门提供序列头等。

所以问题是，这些类型的工件是一些常见配置问题的症状吗？

4

2 回答 2

1

您正在丢失传输中的数据，这可能会导致错误。问题是I图片的比特率高于P图片。如果您有 cbr n/w，那么您可能会看到这个问题。

为什么工件会以这种方式出现：

现在，如果您的视频只有 1 个白球，其余的背景为黑色，则当您丢失帧时，参考图片会丢失并且会出现乱码，因为解码器可能只是尝试使用最后一个有效帧中的帧来显示。由于您的最后一个有效帧是全黑的屏幕其余部分看起来不错，while 球所在的部分仍然显示错误。

用不同的模式替换这个模式，你会更清楚地看到我的意思。

只有 I 图片没有任何参考图片的问题，因此您将获得干净的输出。

检查传输是否正常的一种方法是将您的输出转储到一个文件中，然后在另一端用一个文件读取它。如果一切正常，您就知道您的传输正在丢失数据。

此外，由于您在底部有时钟，因此如果帧丢失，您应该会看到时钟也会跳动。

于 2013-05-08T09:53:32.520 回答
0

事实证明，MPEG-2 Demultiplexer 并不是为处理 H.264 内容而设计的。这就是为什么会出现这些效果。

于 2013-05-10T06:33:07.670 回答