如何在保持低延迟的同时流式传输实时音频和视频答案

【问题标题】：How to stream live audio and video while keeping low latency如何在保持低延迟的同时流式传输实时音频和视频
【发布时间】：2011-09-30 17:43:25
【问题描述】：

我正在编写一个类似于 StreamMyGame 的程序，不同之处在于客户端是免费的，更重要的是，它是开源的，因此我可以将其移植到其他设备（在我的情况下是 OpenPandora），甚至可以制作 html5 或 flash客户。

因为该程序的目标是流式传输视频游戏，所以延迟应降至最低。

现在我可以以固定帧速率捕获 Direct 3D 9 游戏的视频，使用 libx264 对其进行编码并将其转储到磁盘，然后远程发送输入，但我无法通过网络。

我不想实现一种方法，只是发现它会引入几秒钟的延迟，我不在乎它是如何完成的，只要它完成了。

我能想到几种方法：

我目前的方式是，使用 libx264 编码视频，使用 lame 或 ac3 编码音频，并使用 live555 作为 RTSP 提要发送它们，尽管该库与 MSVC 不兼容，我仍在尝试了解它的功能.
让 ffmpeg 库完成所有繁重的工作，在其中进行编码和发送（我想我将不得不使用 ffserver 来了解如何做）
相同，但使用 libvlc，可能会损害过程中的编码可配置性。
在独立程序中使用多个管道（即：将数据管道传输到 x264.exe 或 ffmpeg.exe）
使用其他库，例如 pjsip 或 JRTPLIB，这可能会简化该过程。
艰难的方式，通过 UDP 通道发送视频和音频，并弄清楚如何在客户端同步所有内容（尽管使用 RTSP 的原因是为了避免这种情况）。
你的方式，如果我没想到的话。

第二个选项确实是最好的，因为它会减少库的数量（集成 swscale、libx264、音频编解码器和发送器库），简化开发并带来更多编解码器种类（CELT 看起来很有希望）但我担心关于延迟，因为它可能有更长的管道。

100 毫秒已经太多了，尤其是考虑到在通过宽带使用时可能会再增加 150 毫秒的延迟。

你们有没有使用这些库的经验，建议我切换到 ffmpeg，继续摔跤 live555 或做其他事情（即使我没有提到）？

【问题讨论】：

【解决方案1】：

我在使用 UDT4 库以低延迟流式传输大块数据方面取得了非常好的结果。但首先我建议检查 ffmpegs 网络功能，以便您在所有操作中都有一个原生解决方案。

【讨论】：

如果我也需要可靠的连接，那个库会很有趣，但我不需要。它只是视频，如果我跳过几个字节或整个帧，那么在最坏的情况下，直到下一个关键帧之前，该帧都会看起来失真或短序列。 ffserver 看起来可以满足要求，但源代码中的 cmets 表明，即使是开发人员也对自己的代码不是很有信心，这让我有些厌倦。您对后者有过延迟方面的经验吗？
UDT4 是一个有保证的交付库，用于可靠传输，不知道你从哪里得到的
对不起，如果我编辑太慢（我不小心按了 Enter）或不清楚。我不需要可靠性，这就是为什么原始 UDP 也能正常工作的原因。不过，如果我使用 UDP，我可能最终会使用它，因为我会欣赏数据包重新排序功能和使用的简单性。
在我的例子中，以 30fps 传输 1MByte 数据窗口的延迟在 1Gb LAN 中仅为 4ms 到 1ms。数据是预先订购的，因此您也没有任何订购问题。就这么简单可靠。