在第一批早期采用者尝试我们的新视频会议（最多100人！）的过程中，我们继续谈论使用浏览器进行语音和视频传输的有趣事物。 我们还将讨论视频会议，但是稍后-当大量用户聚集并且收集了有趣的统计数据时。 现在，我为我们翻译并改编了博士的故事。 Alex讨论了低延迟传输视频时不同协议的位置。 这个故事本质上是对另一篇文章的回应，作者和这个故事一起指出了他在研讨会上的同事所犯的错误和不准确之处。
网络数据：单独报警，单独录像
在现代系统中，如果您在浏览器中看到视频，则视频流和警报很可能由不同的服务器处理。 如果视频中一切都清楚了，那么“警报服务器”将提供两件事：“发现”和“握手”。 首先是“发现”，它是数据传输方法的选择：IP地址，中间服务器（如有必要）。 “握手”-有关视频和声音传输参与者之间的谈判：编解码器，分辨率，帧速率，质量。 有趣的是，在古老的Flash中，信令和媒体传输没有像VoxIP或WebRTC那样分开，而是由一种协议提供的：RTMP。
信令协议和信令传输之间的区别
信令协议定义了浏览器和视频传输中的其他参与者在发现和握手时将使用的语言。 它可以是在VoIP或WebRTC中用于发现的SIP，并且具有握手的提供/应答。 很久以前，Flash使用
RTMP / AMF 。 如果需要，对于WebRTC，您可以不使用SIP，而可以使用不寻常的JSEP。
来自同一堆栈但更低的信令传输协议：这是物理传输信令协议数据包的方式。 传统上，对于Flash + SIP，使用TCP或UDP，但是现在在WebRTC + SIP包中，越来越多地找到WebSocket。 WebSockets传输协议在无法使用“纯” TCP和UDP套接字的浏览器中占据TCP位。
现在，通常使用“在Web套接字之上的SIP”，“在Web套接字之上的JSEP”，过时的“在TCP / UDP之上的SIP”或古老的“ RTMP的一部分”这样的短语来描述完整的信令栈。
程序员英语能力：媒体编解码器
大多数视频流协议都与一个或多个编解码器绑定。 从摄像机接收的视频将逐帧处理。 网络问题，例如带宽减少，数据包丢失或它们之间的延迟，可以通过每个帧的编解码器设置解决。 为了及时了解网络问题，我们使用传输协议机制（RTP / RTCP）和带宽估计机制（REMB，Transport-CC，TIMBR）。 Flash视频的基本问题之一是RTMP不能执行任何操作，因此当通道带宽下降时，视频只是停止播放。
另一种英国主义：媒体流协议
确定如何将视频流分成由传输协议通过网络发送的小数据包。 通常，流协议仍然提供处理网络问题的机制：数据包丢失和延迟。 抖动缓冲区，重传（RTC），冗余（RED）和前向纠错（FEC）。
媒体传输协议
从摄像机接收的视频被分成小包后，必须通过网络传输。 为此使用的传输协议类似于信令协议，但是由于“有效负载”完全不同，因此某些协议要好于其他协议。 例如，TCP提供了数据包的可达性，但它并没有为堆栈增加价值，因为流协议中已经存在类似的机制（RTX / RED / FEC）。 但是，重新发送到TCP的延迟是UDP所没有的明显缺陷。 但是，有一种做法可以将UDP阻止为“ torrent协议”。
协议和网络端口的选择以前是由“硬编码”决定的，但是现在我们在WebRTC中使用诸如ICE的协议，该协议使您可以就每个特定连接的端口和传输达成一致。 在不久的将来，有可能使用QUIC协议（与UDP向后兼容），该协议已被IETF积极讨论，并且在速度和可靠性方面优于TCP和UDP。 最后，我们可以提到媒体流协议，例如MPEG-DASH和HLS，它们使用HTTP作为传输方式，并将受益于HTTP / 2.0的引入。
媒体传输安全
一些引擎在通过网络传输期间保护数据：媒体流本身或传输层的数据包。 该过程包括非常加密密钥的传输，为此使用了单独的协议：VoIP中的SDES和WebRTC中的DTLS。 后者具有优点，因为除了数据之外，它还保护加密密钥的传输。
这一切令我困扰
一些开发人员，例如
本文的作者，将纯WebSocket和QUIC协议与WebRTC，Flash或HLS置于同一级别。 对我来说，这样的分组看起来很奇怪，因为最后三个协议是有关流媒体的故事。 在使用WebSocket或QUIC之前，会进行编码和打包。 Google的参考WebRTC实现（libwebrtc / chrome）和Microsoft的ORTC使用QUIC作为传输协议。
同样令人惊讶的是，没有提到将HTTP / 2.0作为对基于HTTP的协议（例如HLS和MPEG-DASH）的优化。 提到的CMAF仅仅是HLS和MPEG-DASH的文件格式，而根本不是它们的替代格式。
最后，SRT只是一种传输协议。 与基于HLS和MPEG-DASH文件的芯片相比，他当然增加了许多芯片，但是所有这些芯片已经处于不同的堆栈级别，并在RTMP或WebRTC中实现。 SRT还共享媒体流和统计信息的编码，这不允许编解码器将此信息保持为尽可能彼此接近。 这样的决定可能会不利地影响使传输的视频适应不断变化的网络带宽的能力。
基于文件的协议（例如HLS）对多个流进行编码，然后选择所需的流以适应通道宽度。 WebRTC允许您实时调整每个帧的编码：这比在HLS中选择另一个流要快得多，后者需要对已发送的数据进行多达10秒的计数。