问题描述
我在通过RTSP流式传输H.264视频时遇到了一些麻烦.目标是将摄像机图像实时流式传输到RTSP客户端(最理想的情况是最后一个浏览器插件).到目前为止，除了一个问题外，它一直运行良好:视频将在启动时滞后，每隔几秒钟便会停顿，并有约4秒钟的延迟.不好.
I'm having some trouble streaming H.264 video over RTSP. The goal is to live-stream a camera image to an RTSP client (ideally a browser plugin in the end). This has been working pretty well so far, except for one problem: the video will lag on startup, stutter every few seconds, and has a ~4-second delay. This is bad.
我们的设置是使用x264编码(具有零延迟和超快)，并使用来自ffmpeg 0.6.5的libavformat打包到RTSP/RTP中.为了进行测试，当连接到RTSP服务器时，我将使用带有gst-launch的GStreamer管道接收流. 但是，当我直接从另一个仅带有RTP的GStreamer实例进行流传输时，我已经能够重现相同的问题.
Our setup is to encode with x264 (w/ zerolatency & ultrafast) and packed into RTSP/RTP with libavformat from ffmpeg 0.6.5. For testing, I'm receiving the stream with a GStreamer pipeline with gst-launch when connecting to an RTSP server. However, I've been able to reproduce the same issue when streaming straight from another GStreamer instance with just 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.在接收端，您应该注意到视频出现卡顿现象且通常效果不佳，以及控制台上的重复警告:
You can also run these both on the same machine, just change the host to 127.0.0.1 on the sender. On the receiving end, you should notice stuttering and generally poor-performing video, along with repeated warnings on the console:
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一起使用:
One commonly-suggested "fix" that I've seen all over the Internet is to use sync=false with xvimagesink:
gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink sync=false
然后，即使使用我们的相机软件进行测试，视频也会以接近零的延迟播放.这对于测试很有用，但对部署不是很有用，因为它不适用于Totem，VLC或它们的浏览器插件嵌入.
The video will then play back with near-zero latency, even when tested with our camera software. This is useful for testing, but is not very useful for deployment, as it won't work with Totem, VLC, or their browser plugin embeds.
我想从源头上解决问题；我怀疑x264或RTP有效负载上的H.264流中缺少某种时间戳信息.有什么方法可以修改 source gst管道，以使我不需要不需要在接收器上使用sync=false?
I'd like to try to solve the issue at the source; I'm suspicious that there's some sort of timestamp info missing on the H.264 stream by x264 or perhaps on the RTP payloads. Is there any way to modify the source gst pipeline so that I do not need to use sync=false on the receiver?
如果这不可能，我如何(通过SDP或其他方式)告诉客户端流不应该同步?最终，我们将使用各种VLC插件将其嵌入到浏览器中，因此可以在其中使用的解决方案会更好.
If that's not possible, how can I tell clients (via SDP or otherwise) that the stream should not be synchronized? Ultimately, we'd embed this in the browser using a VLC plugin of sorts, so a solution that would work there would be even better.
推荐答案
您可以在源gst管道中添加"sync = false".在Ubuntu 12.04上，这似乎消除了滞后和错误消息.
You can add "sync=false" to the source gst pipeline. On Ubuntu 12.04 that seems to remove the lag and error messages.
这是我在源代码上使用的命令:
Here's the command I used on the source:
gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 sync=false
这是我在接收器上使用的:
and here's what I used on the receiver:
gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink
不幸的是，我不知道它为什么起作用，甚至不知道"sync = false"属性属于哪个组件(在源管道上).
Unfortunately, I have no idea why that works or even which component the "sync=false" property belongs to (on the source pipeline).
这篇关于流式RTP/RTSP:同步/时间戳问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！