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

Question

所以现在有一段时间我正在考虑创建某种类型的视频流应用程序(客户端和服务器)。进行一些小的搜索后，我总会获得用于流媒体的应用程序，而不是如何编写一个。

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

所以我应该从哪里开始...我应该研究套接字吗..我应该更多地研究如何实现UDT或TCP协议(protocol)...或者两者结合吗？

Answer 1

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

播放器是否需要基于网络？

来源是否需要基于网络？

还需要其他哪些平台支持？

您有什么样的延迟要求？ (视频 session 风格，质量不太重要，但低延迟非常重要……或更传统的流媒体，您可以选择质量而不在乎延迟。)

源流和正在播放的流之间的比率是多少？每个视频流有很多观看者，还是有很少的观看者有很多视频流？

您的整个操作需要达到哪种规模？

I know that it should be something like... capture data, pack , send to server and then the server will broadcast to anyone connected...right?

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

媒体捕捉

正如我在上面暗示的那样，您如何执行此操作取决于您所使用的平台。实际上，这是变化最大的地方。如果您使用的是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)，在这种格式中，音频和视频编解码器的选择受到限制，但可以实现更好的播放器兼容性。

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

服务器

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

客户群

客户端需要连接到服务器，对流进行多路分解，对音频和视频流进行解码，然后进行回放。这是上面列出的整个过程，但是相反。

So where should i start...

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

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

您可能不应该做的一些事情(除非您确实想要这样做):

不要发明自己的编解码器。 (我们今天拥有的编解码器非常好。他们花费了大量的时间和数十年的学术研究才能达到目标。)

不要发明自己的流协议(protocol)。 (您必须努力使它在所有播放器中得到采用。我们已经有大量的流协议(protocol)可供选择。使用已经存在的流协议(protocol)。)

should i study about sockets..should i study more about how to implement UDT or TCP protocol...or those two combined??

了解网络的基础知识总是有帮助的。是的，了解UD P 和TCP无疑会为您提供帮助，但是由于您不是在发明自己的流协议(protocol)，因此无论如何您都无法在它们之间进行选择。

希望这可以帮助您入门。简而言之，请了解此处的所有层。完成此操作后，您将知道下一步该做什么以及对Google做什么。