分类: 协议

  • OpenVidu:快速集成视频通话的利器

    在当今数字化时代,实时视频通话已经成为许多应用的核心功能之一。无论是远程医疗、在线教育、客户服务,还是虚拟会议,视频通话的需求都在不断增加。今天,我要向大家介绍的是一款强大的开源平台——OpenVidu,它能帮助开发者快速且低成本地将视频通话功能集成到他们的应用中。

    什么是 OpenVidu?

    OpenVidu 是一个旨在简化视频通话集成的开源平台。它提供了一整套技术栈,方便开发者快速将实时通讯功能添加到他们的应用中。无论你是开发网页应用还是移动应用,OpenVidu 都能满足你的需求。

    主要特性

    1. WebRTC 视频会议:支持一对一、一对多以及多对多的各种组合,几乎可以实现你能想到的任何场景。
    2. 开源:OpenVidu 是一个开源项目,使用 Apache License v2 许可证,完全免费。
    3. 多平台兼容:支持 Chrome、Firefox、Safari、Opera、Edge、Android、iOS 以及桌面应用,所有这些平台都能相互兼容。
    4. 易于使用:提供即用型组件,只需简单地粘贴代码即可快速实现视频通话。如果你需要更多的自定义,OpenVidu 的 API 也是非常简单且强大的。
    5. 易于部署:支持在最流行的云服务提供商上进行快速部署,或是通过 Docker 进行本地部署,过程非常简便。

    快速入门

    开始使用 OpenVidu 非常简单。你可以参考 OpenVidu 文档 中的“Getting started”部分,了解如何安装和配置 OpenVidu。以下是一些关键步骤:

    1. 安装 OpenVidu Server:你可以选择在 AWS 上一键部署 OpenVidu,也可以使用 Docker 在本地部署。
    2. 集成前端和后端:OpenVidu 提供了多种前端技术的示例,如 JavaScript、Angular、React、Vue.js 等。后端技术则包括 Java、Node.js 以及 REST API,方便你选择适合的技术栈。

    开发你的视频应用

    OpenVidu 提供了丰富的教程和示例,帮助你快速上手。以下是一些推荐的步骤:

    1. 学习基础知识:文档中提供了“Hello World”示例,帮助你快速了解基本的 API 调用和使用方法。
    2. 探索高级功能:你可以查看“Advanced features”部分,了解如何实现录制视频、屏幕共享、音视频滤镜等高级功能。
    3. 使用现成组件:如果你希望快速实现某些功能,可以使用 OpenVidu 提供的即用型组件,如自定义 UI、自定义工具栏等。

    安全性和隐私保护

    OpenVidu 非常重视用户的隐私和安全。它通过 WebRTC 加密、服务器 API 和客户端基于角色的系统,确保所有通话内容都是完全私密的。此外,OpenVidu 还允许你限制客户端的能力,通过预定义角色来决定用户是否可以订阅、发布或管理视频流。

    适用场景

    OpenVidu 的应用场景非常广泛,包括但不限于以下几种:

    • 客户服务:集成一对一视频通话中心,提供面对面的客户服务。
    • 远程医疗:医生可以通过视频通话直接与患者进行交流,确保私密和安全。
    • 在线教育:教师可以通过视频通话向学生讲解课程,支持多名学生同时在线。
    • 会议服务:支持演讲者实时应用音视频滤镜,提高会议质量。
    • 安防系统:接收来自安防摄像头的视频流,实现监控功能。

    结语

    无论你是想开发一个简单的视频聊天应用,还是一个复杂的视频会议系统,OpenVidu 都能提供强大的支持。它不仅简化了开发过程,还提供了丰富的功能和高水平的安全性,是你开发视频通话应用的不二选择。

    更多详细信息和教程,请访问 OpenVidu 文档


    参考文献:

  • Adobe RTMP 规范:实时消息传递协议详解

    Adobe 的实时消息传递协议(RTMP),是一种应用层协议,旨在通过适当的传输协议(如 TCP)多路复用和打包多媒体传输流(如音频、视频和交互内容)。以下是对 RTMP 规范的详细解析。

    文档概述

    文件状态

    本文档是 2012 年 12 月 21 日发布的 “Adobe 的实时消息传递协议” 规范的机器可读版本。自 2012 年 PDF 版本以来,规范内容并未发生实质性变化,仅在格式和文字编辑上有所调整。

    引言

    RTMP 提供了在可靠的流传输(如 TCP)上的双向消息多路复用服务,旨在携带视频、音频和数据消息的并行流,并附带相关的时间信息。实现通常会为不同类别的消息分配不同的优先级,这会影响在传输容量受限时消息入队到底层流传输的顺序。

    术语

    • MUST: 必须
    • REQUIRED: 必需
    • SHALL: 应该
    • SHOULD: 建议
    • MAY: 可以

    贡献者

    • Rajesh Mallipeddi:原 Adobe Systems 编辑,提供了大部分原始文本。
    • Mohit Srivastava:Adobe Systems 贡献者。

    定义

    • Payload: 包含在数据包中的数据,如音频样本或压缩视频数据。
    • Packet: 由固定头和负载数据组成的数据包。
    • Port: 传输协议用来区分主机内多个目的地的抽象。
    • Transport address: 用于识别传输层端点的网络地址和端口的组合。

    字节顺序、对齐和时间格式

    • 所有整数字段按网络字节顺序(大端序)传输。
    • 时间戳以毫秒为单位,相对于一个未指定的纪元。

    RTMP 块流

    消息格式

    消息格式应包含以下必要字段:

    • Timestamp: 消息的时间戳(4 字节)。
    • Length: 消息负载的长度(3 字节)。
    • Type ID: 消息类型 ID(1 字节)。
    • Message Stream ID: 消息流 ID(4 字节,小端序)。

    握手

    RTMP 连接从握手开始,客户端和服务器各发送相同的三个块(C0、C1、C2 和 S0、S1、S2)。

    块化

    在握手后,连接多路复用一个或多个块流。每个块流携带一种类型的消息。每个块都有唯一的块流 ID。块的传输顺序必须完整发送。接收端根据块流 ID 重新组装消息。

    块格式

    每个块由一个头和数据组成。头有三个部分:

    • Basic Header: 编码块流 ID 和块类型(1-3 字节)。
    • Message Header: 编码关于消息的信息(0、3、7 或 11 字节)。
    • Extended Timestamp: 编码完整的 32 位时间戳(0 或 4 字节)。

    RTMP 消息格式

    消息头

    消息头包含以下字段:

    • Message Type: 消息类型(1 字节)。
    • Length: 负载大小(3 字节)。
    • Timestamp: 消息的时间戳(4 字节)。
    • Message Stream ID: 消息流 ID(3 字节)。

    用户控制消息

    RTMP 使用消息类型 ID 4 进行用户控制消息。这些消息包含 RTMP 流层使用的信息。

    RTMP 消息类型

    命令消息

    携带客户端和服务器之间的 AMF 编码命令。命令消息有两个类型值:20 表示 AMF0 编码,17 表示 AMF3 编码。

    数据消息

    用于发送元数据或用户数据。类型值为 18(AMF0)和 15(AMF3)。

    共享对象消息

    用于管理多个客户端和服务器之间的分布式数据。类型值为 19(AMF0)和 16(AMF3)。

    音频消息

    用于发送音频数据,类型值为 8。

    视频消息

    用于发送视频数据,类型值为 9。

    聚合消息

    包含一系列RTMP 子消息的单一消息。类型值为 22。

    消息交换示例

    发布录制视频

    此示例说明发布者如何发布流并将视频流发送到服务器。其他客户端可以订阅此发布的流并播放视频。

    +--------------------+                     +-----------+
    |  Publisher Client  |        |            |   Server  |
    +----------+---------+        |            +-----+-----+
              |           Handshaking Done           |
              |                  |                  |
              |                  |                  |
    ---+---- |----- Command Message(connect) ----->|
       |     |                                     |
       |     |<----- Window Acknowledge Size ------|
    Connect |     |                                     |
       |     |<------ Set Peer BandWidth ----------|
       |     |                                     |
       |     |------ Window Acknowledge Size ----->|
       |     |                                     |
       |     |<----- User Control(StreamBegin) ----|
       |     |                                     |
    ---+---- |<-------- Command Message -----------|
              |   (_result- connect response)       |
              |                                     |
    ---+---- |--- Command Message(createStream) -->|
    Create |     |                                     |
    Stream |     |                                     |
    ---+---- |<------- Command Message ------------|
              | (_result- createStream response)    |
              |                                     |
    ---+---- |---- Command Message(publish) ------>|
       |     |                                     |
       |     |<----- User Control(StreamBegin) ----|
       |     |                                     |
       |     |---- Data Message (Metadata) ------->|
    Publishing|     |                                     |
    Content   |     |------------ Audio Data ------------>|
       |     |                                     |
       |     |------------ SetChunkSize ---------->|
       |     |                                     |
       |     |<--------- Command Message ----------|
       |     |      (_result- publish result)      |
       |     |                                     |
       |     |------------- Video Data ----------->|
       |     |                  |                  |
       |     |                  |                  |
              |    Until the stream is complete     |
              |                  |                  |

    广播共享对象消息

    此示例说明在创建和更改共享对象期间交换的消息。它还说明了共享对象消息广播的过程。

    +----------+                       +----------+
    |  Client  |           |           |  Server  |
    +-----+----+           |           +-----+----+
           |   Handshaking and Application    |
           |          connect done            |
           |                |                 |
           |                |                 |
           |                |                 |
           |                |                 |
    Create and ---+---- |---- Shared Object Event(Use)---->|
    connect       |     |                                  |
    Shared Object |     |                                  |
    ---+---- |<---- Shared Object Event --------|
           |       (UseSuccess,Clear)         |
           |                                  |
    ---+---- |------ Shared Object Event ------>|
    Shared object |     |         (RequestChange)          |
    Set Property  |     |                                  |
    ---+---- |<------ Shared Object Event ------|
           |            (Success)             |
           |                                  |
    ---+---- |------- Shared Object Event ----->|
    Shared object|     |           (SendMessage)          |
    Message      |     |                                  |
    Broadcast ---+---- |<------- Shared Object Event -----|
           |           (SendMessage)          |
                              |                 |
                              |                 |

    从录制流发布元数据

    此示例描述了发布元数据的消息交换。

    +------------------+                       +---------+
    | Publisher Client |         |             |   FMS   |
    +---------+--------+         |             +----+----+
           |     Handshaking and Application     |
           |            connect done             |
           |                  |                  |
           |                  |                  |
    ---+--- |-- Command Messsage (createStream) ->|
    Create |    |                                     |
    Stream |    |                                     |
    ---+--- |<-------- Command Message -----------|
           |   (_result - command response)      |
           |                                     |
    ---+--- |---- Command Message (publish) ----->|
    Publishing |    |                                     |
    metadata |    |<----- UserControl (StreamBegin) ----|
    from file |    |                                     |
              |    |---- Data Message (Metadata) ------->|
           |                                     |

    参考文献

    • RFC0791: Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.
    • RFC0793: Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.
    • RFC1982: Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, August 199
  • RTMP协议(Real-Time Messaging Protocol)

    RTMP协议(Real-Time Messaging Protocol)是一种用于在互联网上流式传输音频、视频和数据的通信协议[1]。最初由Macromedia开发为Flash Player和Flash Communication Server之间的流媒体传输的专有协议,后来被Adobe(收购了Macromedia)发布了该协议的不完整版本供公众使用[1]

    RTMP协议有多个变种:

    • RTMP:在Transmission Control Protocol(TCP)之上工作的“纯”协议,默认使用1935端口号。
    • RTMPS:在Transport Layer Security(TLS/SSL)连接上的RTMP。
    • RTMPE:使用Adobe自己的安全机制对RTMP进行加密。虽然实现的细节是专有的,但该机制使用行业标准的加密原语[1]
    • RTMPT:封装在HTTP请求中以穿越防火墙。RTMPT通常使用TCP端口80和443上的明文请求来绕过大多数企业流量过滤。封装的会话可以在内部携带纯RTMP、RTMPS或RTMPE数据包[1]
    • RTMFP:在User Datagram Protocol(UDP)上的RTMP,取代了RTMP Chunk Stream。Secure Real-Time Media Flow Protocol套件由Adobe Systems开发,使终端用户能够直接连接和通信(P2P)[1]

    RTMP的基本操作是基于TCP的,它维持持久连接并允许低延迟通信。为了平稳地传输流并尽可能多地传输信息,它将流分割成片段,并且片段的大小在客户端和服务器之间动态协商。有时,片段的大小保持不变;音频数据的默认片段大小为64字节,视频数据和大多数其他数据类型的默认片段大小为128字节。来自不同流的片段可以交错和多路复用到单个连接上。由于较长的数据块,该协议每个片段仅携带一个字节的头部,因此开销非常小。然而,在实践中,通常不会交错单个片段。相反,交错和多路复用是在数据包级别上完成的,以确保每个通道满足其带宽、延迟和其他服务质量要求。以这种方式交错的数据包被视为不可分割的,不会在片段级别上交错[1]

    RTMP定义了几个虚拟通道,可以在这些通道上发送和接收数据包,并且这些通道彼此独立运行。例如,有一个用于处理RPC请求和响应的通道,一个用于视频流数据的通道,一个用于音频流数据的通道,一个用于带外控制消息(片段大小协商等)的通道等。在典型的RTMP会话期间,多个通道可能同时处于活动状态。当对RTMP数据进行编码时,会生成一个数据包头部。数据包头部指定了要发送的通道的ID、生成时间戳(如果需要)以及数据包有效载荷的大小。然后,在将其发送到连接上之前,将其实际有效载荷内容(媒体数据)根据当前协商的片段大小进行分段。数据包头部本身永远不会被分段,其大小不计入数据包的第一个片段中的数据。换句话说,只有实际的数据包有效载荷(媒体数据)会被分段[1]

    在更高的层次上,RTMP封装了MP3或AAC音频和FLV1视频多媒体流,并可以使用Action Message Format进行远程过程调用(RPC)。所需的任何RPC服务都是异步进行的,使用单个客户端/服务器请求/响应模型,因此不需要实时通信[2]

    RTMP会话可以使用以下两种方法进行加密:

    • 使用行业标准的TLS/SSL机制。底层的RTMP会话只是包装在正常的TLS/SSL会话中。
    • 使用RTMPE,在RTMP会话中包装一个轻量级的加密层。

    在RTMP Tunneled(RTMPT)中,RTMP数据通过HTTP进行封装和交换,客户端(媒体播放器)的消息被发送到服务器上的80端口(HTTP的默认端口)[1]。RTMPT中的消息由于HTTP头部的原因比等效的非隧道化RTMP消息要大,但在客户端位于阻止非HTTP和非HTTPS出站流量的防火墙后,RTMPT可能有助于使用RTMP的场景,否则将无法使用非隧道化的RTMP。

    RTMP协议的数据包结构如下:

    • 数据包通过TCP连接发送,首先在客户端和服务器之间建立连接。
    • 数据包包含一个头部和一个主体,在连接和控制命令的情况下,主体使用Action Message Format(AMF)进行编码。
    • 头部分为基本头部(从图表中分离出来)和块消息头部。基本头部是数据包的唯一固定部分,通常由一个复合字节组成,其中最高的两个有效位是块类型(在规范中称为fmt),其余部分形成流ID。根据前者的值,可以省略消息头部的某些字段,并且可以从先前的数据包中派生它们的值,而根据后者的值,基本头部可以扩展为一个或两个额外的字节。如果基本头部的剩余六个位(最低有效位)的值为0,则基本头部为两个字节,表示从流ID 64到319(64+255);如果值为1,则基本头部为三个字节(最后两个字节编码为16位小端),表示从流ID 64到65599(64+65535);如果值为2,则基本头部为一个字节,保留用于低级协议控制消息和命令。块消息头部包含元数据信息,例如消息大小(以字节为单位)、时间戳增量和消息类型。最后一个值是一个字节,定义数据包是音频、视频、命令还是“低级”RTMP数据包,例如RTMP Ping[1]

    Learn more:

    1. Real-Time Messaging Protocol – Wikipedia
    2. RTMP协议深度解析:从原理到实践,掌握实时流媒体传输技术-阿里云开发者社区
    3. 实时消息协议 – 维基百科,自由的百科全书
  • RTP(Real-time Transport Protocol)是一种用于实时流媒体传输的协议

    RTP(Real-time Transport Protocol)是一种用于实时流媒体传输的协议。它是一种面向数据报的协议,用于在IP网络上传输音频和视频等实时数据。RTP协议通常与RTCP(Real-time Transport Control Protocol)一起使用,RTCP用于传输控制信息,例如流媒体的质量反馈和同步信息。

    RTP协议的特点和功能包括:

    1. 实时传输:RTP协议被设计用于实时传输,可以在网络上以实时的方式传输音频和视频数据。
    2. 分组传输:RTP将音频和视频数据分割成小的数据包进行传输,每个数据包都带有序列号和时间戳等信息,以便接收端可以正确地重建数据流。
    3. 时间同步:RTP协议使用时间戳来确保音频和视频数据在接收端能够按照正确的时间顺序播放。
    4. 负载类型:RTP协议支持多种不同的负载类型,例如音频编码(如G.711、AAC)和视频编码(如H.264、VP8)等。
    5. QoS支持:RTP协议可以通过设置不同的服务质量(QoS)参数来满足实时流媒体传输的要求,例如延迟、带宽和抖动等。

    RTP协议在实时流媒体传输中起着重要的作用,它可以与其他协议结合使用,例如RTSP(Real-time Streaming Protocol)用于控制流媒体的会话和传输。


    Learn more:

    1. 实时传输 Web 音频与视频 – Web 媒体技术 | MDN
    2. 【RTP 传输协议】实时视频传输的艺术:深入探索 RTP 协议及其在 C++ 中的实现-阿里云开发者社区
    3. RTP协议详解-CSDN博客