视频流应用程序从哪里开始

Question

所以现在有一段时间我正在考虑创建某种视频流应用程序（客户端和服务器）。做一些小搜索我总是得到流应用程序，而不是如何编写代码。

我知道它应该是……捕获数据，打包，发送到服务器，然后服务器将广播给任何连接的人……对吗？

那么我应该从哪里开始...我应该研究套接字..我应该研究更多关于如何实现 UDT 或 TCP 协议...或者这两者结合？？

Answer 1

您在搜索中遇到的部分问题是您没有真正定义要解决的问题。 “视频流应用”还不够……有什么限制？一些有助于缩小适当解决方案的问题：

• 播放器是否需要基于网络？
• 来源是否需要基于网络？
• 还有哪些平台需要支持？
• 您有什么样的延迟要求？ （视频会议风格，质量不太重要，但低延迟非常重要......或者更传统的流媒体，您选择质量并且不太关心延迟。）
• 源流与播放流之间的比例是多少？每个流有很多观看者，还是有很多流但观看者很少？
• 您的整个运营需要达到什么样的规模？

我知道它应该是……捕获数据，打包，发送到服务器，然后服务器将广播给任何连接的人……对吗？

关闭。让我们分解一下。所有视频流都将包含一些捕获元素、编解码器、容器或传输、要分发的服务器以及连接到服务器并反转整个过程的客户端。

媒体捕捉

正如我在上面所暗示的，您如何执行此操作取决于您所在的平台。这实际上是事情变化最大的地方。如果您使用的是 Windows，则可以使用 DirectShow。 OSX 和 Linux 有自己的捕获框架。另请记住，您还需要音频流，这不一定在视频捕获中处理。如果您是基于网络的，则需要 getUserMedia。

编解码器

发送原始的未压缩帧会非常低效。如果没有编解码器，我们所知道的视频流将是不可能的。每个编解码器的工作方式略有不同，但有很多常用技术。

在基本层面上，如果您可以想象幻灯片上的帧，那么每一帧与下一帧并没有太大区别。对于给定的镜头，可能会发生运动，但帧中的大部分内容保持非常相似。我们可以通过仅发送更改的内容来节省大量带宽。 （实际上，由于我们捕获的世界的模拟性质，每一帧总是有点不同，但是编解码器可以在几乎完全相同的事物上花费很少的带宽，而不是完全不同的事物。）当我们去一个不同的镜头时，编解码器看到整个帧是不同的并发送一个完整的帧。可以独立的帧是“I 帧”。每隔几秒，I 帧也会定期插入流中。大多数视频播放器只会寻找 I 帧，因为任何不是 I 帧的东西都需要解码它之前的所有帧，直到前面的 I 帧。如果您曾经试图击中电影中的某个确切位置，但玩家在几秒钟内将您放在附近的某个位置，这就是发生这种情况的原因。此外，如果某些帧被损坏，则流将在下一个 I 帧上自行纠正。 （曾经看过一段视频，其中很大一部分在几秒钟内变绿，但后来又好了？这就是原因。）

视频编解码器还利用我们看待事物的方式来发挥自己的优势。我们的眼睛对亮度变化比对颜色变化更敏感。因此，编解码器在帧中的亮度差异上花费的带宽比在颜色差异上花费的带宽更多。还有一些巧妙的技巧可以平滑和添加视觉噪音，使​​事物看起来更正常而不是块状。

还需要音频编解码器。虽然 CD 质量的立体声未压缩音频流可能只占用 1.4 兆位，但在互联网方面这是一个很大的带宽。许多流媒体视频网站对整个视频使用的带宽都比这少。音频编解码器，就像视频编解码器一样，使用一些技巧来节省带宽。 （有关更详细的解释，请在此处阅读我关于 MP3 工作原理的帖子：https://sound.stackexchange.com/a/25946/7209）

容器

下一步是以容器格式将编码的音频和视频流混合在一起。如果您正在录制到磁盘，您可能会选择像 MKV 这样的东西，它支持音频、视频、字幕等，所有这些都在同一个文件中。 WebM 基本上是 MKV 的有限版本，但设计为易于浏览器支持。或者您可能会选择一种不太复杂的格式，例如 MP4，您在音频和视频编解码器的选择上受到限制，但获得更好的播放器兼容性。

由于您是实时流式传输，因此流式传输协议和容器之间的界限通常会有些模糊。 HLS 将要求您制作一堆独立的视频文件，但您的复用器和编解码器需要知道如何以可以再次组合在一起的方式分割这些文件。我认为 RTMP 从 FLV 中汲取灵感，但在与客户端的交换中也有一些关于流的信息。 （如果您使用 RTMP，您可能会在其他地方读到它……我不太了解 RTMP。）

服务器

这里有很多选择。在 WebRTC 的情况下，“服务器”实际上可能是执行所有编码的 Web 浏览器，而不是因为它可以点对点运行。或者，您可能有一个运行 RTMP 的专用流服务器，或一个用于分发 HLS 块的普通 HTTP Web 服务器。同样，您选择什么取决于您的要求。

客户

客户端需要连接到服务器，解复用流，解码音频和视频流，然后播放它们。就是上面列出的整个过程，但是反过来。

那么我应该从哪里开始...

首先弄清楚确切地你想做什么。如果您不知道自己想做什么，请尝试使用 WebRTC。浏览器完成所有工作，并且在大多数情况下只需要很少的服务器资源。这将允许您在几个客户端之间实时流式传输。

要获得更高级的知识，请开始尝试您已有的现成产品。 FFmpeg 是一个很棒的工具，您绝对应该知道如何使用它，它可以嵌入到您的解决方案中。

一些你可能不应该做的事情（除非你真的想做）：

• 不要发明自己的编解码器。 （我们今天拥有的编解码器非常好。他们花费了大量的投资和数十年的学术研究来达到现在的水平。）
• 不要发明自己的流协议。 （您必须努力让所有播放器都采用它。我们已经有大量流媒体协议可供选择。使用已有的协议。）

我应该学习sockets..我应该学习更多关于如何实现UDT或TCP协议......或者这两者结合吗？？

了解网络基础知识对您总是有帮助的。是的，了解 UDP 和 TCP 肯定会对您有所帮助，但由于您没有发明自己的流协议，因此您甚至无法在它们之间做出选择。

我希望这可以帮助您入门。简而言之，了解这里的所有层。完成此操作后，您就会知道下一步该做什么，以及谷歌要做什么。