寻找最快的视频编码器，将网络摄像头流式传输到 ipad

Posted 2023-03-13

【中文标题】寻找最快的视频编码器，将网络摄像头流式传输到 ipad

【英文标题】：Look for fastest video encoder with least lag to stream webcam streaming to ipad

【发布时间】：2012-08-14 18:23:21

【问题描述】：

我正在寻找编码网络摄像头流的最快方法，该流将在 html5 视频标签中可见。我正在使用 Pandaboard：http://www.digikey.com/product-highlights/us/en/texas-instruments-pandaboard/686#tabs-2 作为硬件。可以使用gstreamer、cvlc、ffmpeg。我将使用它来驱动机器人，因此视频流中需要的延迟最少。质量不一定很好，也不需要音频。此外，这仅适用于一个客户端，因此带宽不是问题。迄今为止最好的解决方案是使用带有 mpjpeg 的 ffmpeg 给我大约 1 秒的延迟。有更好的吗？

【问题讨论】：

ffmpeg.org/trac/ffmpeg/wiki/StreamingGuide#Latency 列出了一些 ffmpeg 延迟的提示/线索

【参考方案1】：

我已经被问过很多次了，所以我会尝试笼统地回答这个问题，而不仅仅是针对 mjpeg。在系统中获得非常低的延迟需要一些系统工程工作以及对组件的理解。

我能想到的一些简单的***调整是：

确保编解码器配置为最低延迟。编解码器（尤其是嵌入式系统编解码器）将具有低延迟配置。启用它。如果您使用的是 H.264，它是最有用的。大多数人没有意识到按照标准要求，H.264 解码器需要在显示帧之前对其进行缓冲。 Qcif 最多 16 帧，720p 最多 5 帧。第一帧的输出有很多延迟。如果您不使用 H.264，请确保您没有启用 B 图片。这增加了获取第一张图片的延迟。

由于您使用的是mjpeg，我认为这对您不太适用。

编码器也会有速率控制延迟。 （称为初始化延迟或 vbv buf 大小）。将其设置为提供可接受质量的最小值。这也将减少延迟。将其视为编码器和解码器之间的比特流缓冲区。如果您使用的是 x264，那将是 vbv 缓冲区大小。

一些简单的其他配置：使用尽可能少的 I 图片（大内期）。 我的图片很大，增加了通过网络发送的延迟。这在端到端延迟在 1 秒或更长范围内的系统中可能不是很明显，但是当您设计需要 100 毫秒或更短的端到端延迟的系统时，这和其他几个方面都会发挥作用。还要确保您使用的是低延迟音频编解码器 aac-lc（而不是 heaac）。

在您的情况下，为了降低延迟，我建议远离 mjpeg 并至少使用没有 B 图片的 mpeg4（简单配置文件）或最好是 H.264 基线配置文件（x264 提供零延迟选项）。您将获得较低延迟的简单原因是您将获得较低的比特率后编码以发送数据并且您可以进入全帧率。如果你必须坚持使用 mjpeg，那么在没有来自编解码器和使用开源组件的系统的更高级功能支持的情况下，你可以获得的结果接近。

另一方面是将内容传输到显示单元。如果您可以使用 udp，与 tcp 相比，它将大大减少延迟，尽管根据网络条件有时可能会丢失。您提到了 html5 视频。我很好奇您是如何对 html5 视频标签进行实时流式传输的。

还有其他方面可以调整，我会放在高级类别中，需要系统工程师尝试各种事情

操作系统中的网络缓冲是什么？出于性能原因，操作系统还会在发送数据之前对其进行缓冲。调整它以获得性能和速度之间的良好平衡。

您使用的是 CR 还是 VBR 编码？虽然 CBR 非常适合低抖动，但如果编解码器提供，您也可以使用 capped vbr。

您的解码器可以开始解码部分帧吗？因此，您不必担心在将数据提供给解码器之前对其进行分帧。尽快将数据推送到解码器。

你能做字段编码吗？将第一张图片输出之前的帧编码时间减半。

只要切片可立即通过网络发送，您是否可以使用回调进行切片编码？

使用了我在上述所有方法中工作过的低于 100 毫秒的延迟系统。有些功能可能在开源组件中不可用，但如果您真的需要它并且有热情，您可以继续实施它们。

编辑： 我意识到你不能为 ipad 流媒体解决方案做很多上述事情，并且由于 hls 也有限制，你可以实现的延迟。但我希望它能在您需要任何低延迟系统的其他情况下证明是有用的。

【讨论】：

如果您使用 HLS，请为传输流创建 1 秒的块。不管以上几点，我认为你不能低于这个值，因为 ipad 在开始播放内容之前会等待 1 秒。如果不是 HLS，我很好奇你是怎么玩的。

AAC-LC seems 100+ ms slower than AAC-LD (20+ ms latency), and AAC-LD is slower than Opus (<20 ms)

【参考方案2】：

我们遇到了类似的问题，在我们的案例中，需要对外部事件进行计时并将它们与视频流同步。我们尝试了多种解决方案，但此处描述的解决方案解决了问题并且延迟极低：

Github Link

它使用gstreamer 转码为 mjpeg，然后将其发送到小型 python 流服务器。这样做的好处是它使用标签而不是它可以被大多数现代浏览器查看，包括 iPhone。

如果你想要

另一个看起来很有前途的解决方案，gst-streaming-server。我们根本找不到足够的文档来使它值得追求。如果有人可以询问有关如何使用它的 *** 问题，我将不胜感激！

【讨论】：

感谢为我更改 Github 链接的人，不胜感激！

你考虑过WebRTC吗？