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

Question

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

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

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

Answer 1

您在搜索中遇到的部分问题是，您还没有真正定义您尝试解决的问题。 ＆＃34;视频流应用＆＃34;还不够......有什么限制？一些有助于缩小适当解决方案的问题：

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

  

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

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

媒体捕获

正如我在上面暗示的那样，你如何做到这一点取决于你所处的平台。这实际上是变化最大的地方。如果您使用的是Windows，那就是DirectShow。 OSX和Linux有自己的捕获框架。另外请记住，您也需要音频流，这在视频捕获中并不一定要处理。如果您是基于网络的，则需要getUserMedia。

编解码器

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

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

视频编解码器还利用了我们如何看待事物的本质。我们的眼睛对亮度的变化比对颜色的变化更敏感。因此，编解码器在帧中的亮度差异上比在色差中花费更多的带宽。还有一些狡猾的技巧，用于平滑和增加视觉噪音，使​​事物看起来更正常而不是块状。

还需要音频编解码器。虽然CD质量的立体声未压缩音频流可能只占用1.4mbit，但这在互联网方面带来了很多带宽。很多流视频网站使用的带宽比整个视频少。与视频编解码器非常相似的音频编解码器在我们如何看待节省带宽方面使用了一些技巧。 （有关更详细的说明，请阅读有关MP3如何工作的帖子：https://sound.stackexchange.com/a/25946/7209）

容器

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

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

服务器

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

客户

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

  

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

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

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

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

• 不要发明自己的编解码器。 （我们今天拥有的编解码器非常好。他们花了大量的投资和数十年的学术研究才能到达目的地。）
• 不要发明自己的流媒体协议。 （你必须努力让它在所有玩家中被采用。我们已经有大量的流媒体协议可供选择。使用已有的协议。）

  

我应该研究套接字..我应该研究更多关于如何实现UDT或TCP协议......还是那两个组合？

了解网络基础知识总是有帮助的。是的，了解UD P 和TCP肯定会对您有所帮助，但由于您并未发明自己的流媒体协议，因此您无论如何都不会在它们之间进行选择。

我希望这有助于您入门。简而言之，了解这里的所有图层。完成后，您将知道接下来要做什么，以及Google要做什么。