流式传输 RTP/RTSP：同步/时间戳问题答案

【问题标题】：Streaming RTP/RTSP: sync/timestamp problems流式传输 RTP/RTSP：同步/时间戳问题
【发布时间】：2012-07-09 14:57:00
【问题描述】：

我在通过 RTSP 传输 H.264 视频时遇到了一些问题。目标是将摄像机图像实时流式传输到 RTSP 客户端（理想情况下最终是浏览器插件）。到目前为止，这一直运行良好，除了一个问题：视频在启动时会滞后，每隔几秒就会卡顿，并且有大约 4 秒的延迟。这很糟糕。

我们的设置是使用 x264（零延迟和超快）进行编码，并使用 ffmpeg 0.6.5 中的 libavformat 打包到 RTSP/RTP 中。为了进行测试，我在连接到 RTSP 服务器时使用带有 gst-launch 的 GStreamer 管道接收流。但是，当直接从另一个 GStreamer 实例仅使用 RTP 进行流式传输时，我已经能够重现相同的问题。

发送机：

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=10.89.6.3

收货机：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink

您也可以在同一台机器上同时运行它们，只需将发送方的主机更改为 127.0.0.1。在接收端，您应该会注意到视频卡顿且通常效果不佳，以及控制台上的反复警告：

WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2875): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0:
There may be a timestamping problem, or this computer is too slow.

我在互联网上看到的一个普遍建议的“修复”是将sync=false 与 xvimagesink 一起使用：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink sync=false

即使使用我们的相机软件进行测试，视频也会以接近零的延迟播放。这对于测试很有用，但对于部署不是很有用，因为它不适用于 Totem、VLC 或它们的浏览器插件嵌入。

我想尝试从源头解决问题；我怀疑 x264 或 RTP 有效负载上的 H.264 流上缺少某种时间戳信息。有什么方法可以修改 source gst 管道，以便我不需要在接收器上使用sync=false？

如果这不可能，我如何告诉客户端（通过 SDP 或其他方式）不应该同步流？最终，我们使用某种 VLC 插件将其嵌入到浏览器中，因此可以在那里工作的解决方案会更好。

【问题讨论】：

标签： video streaming h.264 gstreamer rtp

【解决方案1】：

正如 root.ctrlc 所发布的，您可以使用 sync=FALSE。但是，您可能会注意到发送方的 CPU 使用率大幅增加。原因是 sync=FALSE 告诉接收器在收到缓冲区后立即推出缓冲区。水槽驱动整个管道。因此，sync=FALSE 会导致管道对视频进行编码并尽快推送到 UDP；它将使用 100% 的 CPU。

您需要的是 gstrtpjitterbuffer。它还负责处理此处损坏的时间戳。

发件人示例：

gst-launch-0.10 -v videotestsrc ! videorate ! video/x-raw-yuv, framerate=30/1 ! ffmpegcolorspace ! x264enc ! rtph264pay ! udpsink port=50000 host=<sender IP>

接收器示例：

gst-launch-0.10 udpsrc port=50000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000 , encoding-name=(string)H264 , payload=(int)96" ! gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! "video/x-raw-yuv, width=320, height=240" ! xvimagesink

【讨论】：

+1 但是当我们使用 gst-launch-0.10 -v gstrtpbin name=rtpbin latency=40 udpsrc caps=".." port=50000 时，您如何使用gstrtpjitterbuffer，您可以在使用 gstrtpbin 时分享接收器部分吗？
gsrtpbin 已经包含一个 gstrtpjitterbuffer。至于命令行，我会尽量回复你。目前我无法尝试，因为我没有在这里安装 GStreamer 0.10。（顺便说一句，您真的应该迁移到 1.0 ，强烈推荐这样做。）
@dv_ 感谢您指向gstrtpjitterbuffer 以及对sink=false 的解释。您能否解释一下管道是如何驱动的（sync=true 时）？
为什么这里的时间戳被破坏了？

【解决方案2】：

您可以将“sync=false”添加到源 gst 管道。在 Ubuntu 12.04 上，这似乎消除了滞后和错误消息。

这是我在源代码上使用的命令：

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 sync=false

这是我在接收器上使用的：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink

不幸的是，我不知道为什么会这样，甚至不知道“sync=false”属性属于哪个组件（在源管道上）。

【讨论】：

谢谢.. 同样的问题，但我在接收方给出了“sync=false”，它对我有用。

【解决方案3】：

我不知道这是真的，但是当我在没有将电池充电器连接到笔记本电脑的情况下运行我的管道时，它曾经给我同样的警告，当我插入电源时，相信我工作。我认为这可能是因为旧的 CMOS 电池无法正常工作。因为它负责时钟生成。

【讨论】：

在这种情况下，我怀疑您的笔记本电脑有一个电源配置选项，可以在使用电池运行时降低最大可用 CPU 功率。当你用充电器运行时，你得到 100% 的 CPU，当你用电池运行时，你得到的更少。因此“或者这台电脑太慢了”。