我正在尝试通过hlssink使用GStreamer-1.0从我的OSX应用程序中流式传输OpenGL帧缓冲区。我的管道是appsrc->decodebin->videoconvert->x264enc->mpegtsmux->hlssink。问题是，提要看起来像这样，并且至少有10秒的延迟。
如果你看到这张图片，这是我的桌面的一个 Package 图像。我刚刚开始学习GStreamer，对编码/复用部分还没有太多的了解。我注意到的另一件事是，即使没有编码和复用部分i.e.,appsrc->videoconvert->osxsink，提要也是这样显示的。
可能是什么问题？我如何从帧缓冲区获得清晰的提要？
我该如何处理这个问题，以便实时或至少最小的延迟？
我应该使用tcpserversink而不是hlssink来减少延迟吗？
我正在将GStreamer与我的OSX应用程序集成，它为appsrc生成源缓冲区。我的最终目标是通过http / tcp流传输实时提要。
我在这个工作了两个星期，现在，有一个公平的机会，我已经错过了一些非常基本的东西，所以请随时评论你的意见。请让我知道，如果有人需要更多的信息或源代码。
编辑：
这是我为appsrc设置的上限。
caps = gst_caps_new_simple ("video/x-raw",
"width", G_TYPE_INT, 1280,
"height", G_TYPE_INT, 800,
"format", G_TYPE_STRING, "RGB16", NULL);输入的数据类型是来自帧缓冲区的原始数据。这是一个Mac的屏幕投射应用程序。
如果我做实时屏幕投射，hlssink是正确的选择吗？我应该尝试tcpserversink吗？
2条答案
按热度按时间iecba09b1#
对于延迟，请考虑使用
x264enc元素的tune=zerolatency选项。对于appsrc，我们需要知道你将什么样的数据输入到管道中，你在那里设置了什么上限，很可能你没有将它们设置为相互匹配，这样gstreamer就会误解数据表示。
dz6r00yl2#
为了改善延迟，存在多种改进途径。
1.流媒体技术
1.编码技术
流媒体技术
每种方法都有其优缺点，因此您需要针对应用程序进行优化。
如果你使用hls或dash，预计会有10-30秒的延迟。这是因为这是为体育等不需要很低延迟的直播应用而设计的。它的工作原理是将视频流重新编码成小块（比如10秒），然后通过http传输它们。这使得倒带效率高得多。如果你在服务器端减少你的块长度，在客户端减少抖动块，这将改善延迟。但不是亚秒。较新的技术，如分段的hls/dash可以做得更好，但不是所有的客户端都会支持它们。
如果你使用rtmp，这将大大改善hls/dash的延迟。但是你需要打开自定义端口（1935）。而且这是一个老技术，所以新的客户端可能会放弃对它的支持。
Webrtc是一项出色的亚秒级延迟新技术。如果你想做1：n流媒体或者在你的流媒体上添加自定义数据，它有很多优势。html5本身就支持它，所以这也是一个优点。缺点是它相对复杂，需要更多的开发工作。
编码
其他延迟来自编码。这实际上是一个时间、计算能力和网络带宽的优化问题。试图减少一个将增加另一个。
大多数编码器允许低延迟选项，但会牺牲带宽。更复杂的编码（例如使用h265而不是h264）将需要更高的计算能力来保持相同的延迟，但提高带宽。您需要根据您的最终应用进行优化。