***在七牛云校园黑客马拉松中，来自华南理工大学的SCUT01团队，为我们带来了UI精美、体验优秀的白板作品，在大赛中获得二等奖的好成绩。以下是这款在线协作白板的技术解决方案。***

![](https://pic1.zhimg.com/80/v2-f5d7e533dc9b6627fcbe87e6227c57d8_720w.webp)

## **背景**

疫情背景下，线上课堂、线上会议等业务背景下都有着在线协作白板的需求。如何实现图形的绘制和实时同步，这是核心的两个问题。本文介绍一种基于原生Canvas和Websocket通信协议的协作白板解决方案。

![](https://pic3.zhimg.com/80/v2-87a4c8468033786e8706881e19d43802_720w.webp)

## **基础技术介绍**

**Canvas**

**<canvas>** 元素是HTML5新增的，一个可以使用脚本( 通常为JavaScript )在其中绘制图像的HTML元素。它可以用来制作照片集制作简单的动画，甚至可以进行实时视频处理和渲染。  **<canvas>** 由API构成，除了具备基本绘图能力的 *2D上下文* ， **<canvas>** 还具备一个名为WebGL的 *3D上下文* 。

> API参考：Canvas - Web API 接口参考 | MDN ([http://**mozilla.org**](https://link.zhihu.com/?target=http%3A//mozilla.org))

### **WebSocket**

![](https://pic2.zhimg.com/80/v2-3bfc82729a7568972b2bae99d75c35e9_720w.webp)

WebSocket是在H5中常被使用的全双工通信协议，它有以下特点

* 建立在单个TCP连接上的全双工通信应用层协议，支持服务端主动向客户端推送消息
* 握手阶段采用HTTP协议 （101状态码，Upgrade），与HTTP协议良好兼容
* 既可以发送文本数据，也可以发送二进制数据

WebSocket完美继承了 TCP 协议的**全双工**能力，并且还贴心的提供了解决粘包的方案。

它适用于**需要服务器和客户端（浏览器）频繁交互**的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。

对于白板应用的同步功能实现，就使用了Websocket进行实现。

## **协作技术下WebSocket实践**

### **前置知识**

首先需要介绍一下浏览器与服务器是如何建立WebSocket连接的。

* 浏览器在 **TCP 三次握手**建立连接之后，都**统一使用 HTTP 协议**先进行一次通信
* 如果 **建立 WebSocket 连接** ，就会在 HTTP 请求里带上一些**特殊的header 头**

```text
Connection: Upgrade
 Upgrade: WebSocket
 Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n
```

* 服务器收到带有 `Connection: Upgrade`请求头的HTTP请求之后，会调用 `upgrade`方法，将连接更改为websocket连接，然后给该次HTTP请求响应101状态码
* 至此，Websocket连接已经建立，可以使用已经建立的连接进行双工通信

### **连接处理**

服务端采用高性能的Go语言进行开发，`github.com/gorilla/websocket`开源库已经封装好完成了upgrade、返回101响应等方法，这里我们直接使用该库进行开发

* 定义服务器结构体字段

```text
type WstServer struct {
   listener          net.Listener
   upgrade           *websocket.Upgrader
   onConnectHandlers OnConnectHandler
}
```

* 该结构体实现ServeHTTP方法，并在方法中调用 `Upgrade`方法实现websocket协议的切换

```text
func (thisServer *WstServer) ServeHTTP(w http.ResponseWriter, r *http.Request) {
   conn, err := thisServer.upgrade.Upgrade(w, r, nil)
   if err != nil {
      log.Println("[ws upgrade]", err)
      return
   }
   log.Println("[ws client connect]", conn.RemoteAddr())
   thisServer.onConnect(conn, r.URL.Path) //每个连接开启协程进行处理
}
```

**白板业务下的websocket服务架构**

![](https://pic1.zhimg.com/80/v2-90d3fbe78c83012c862b9d71649daca0_720w.webp)

* 将每一个白板抽象为一个Hub，所有进入该白板的Client都需要使用WebSocket进行连接到WebSocket服务器中白板对应的Hub；其数据结构定义如下

```text
type Hub struct {
   BoardId     string                                        //白板id
   Connections *utils.ConcurrentMap[string, *UserConnection] //当前白板下所有的连接
}
```

* *`BoardId`为该Hub对应的白板ID*
* *`Connections`为该Hub中所有已经建立的WebSocket连接，key为UserId*
* 当其中一个Client进行操作之后（如绘制、删除、移动一个图形等），Client将该操作抽象为一个 `Cmd`的消息，发送给WebSocket服务器
* WebSocket服务器会将来自Client的消息**广播**给其他Client，其他Client会调用注册的回调函数进行处理渲染

```text
func (hub *Hub) Broadcast(obj any) {
   //遍历每一个连接，发送消息
   hub.Connections.Data().Range(func(key, value any) bool {
      userId := key.(string)
      conn := value.(*UserConnection)
      err := conn.SendJSON(obj)
      if err != nil {
         log.Println("[Error] Send To ===============> ", userId, err)
         return true
      }
      return true
   })
}
```

### **Websocket集群解决方案**

如果在单机情况下，当websocket需要给用户推送消息时，由于用户已经与websocket服务建立连接，消息推送能够成功。

但如果在集群情况下，用户甲向websocket发起连接请求，有多台服务时，只能与一台服务建立连接（以服务器A为例），而这些websocket服务都是有可能会给用户甲推送消息，这时候的服务器B和服务器C并没有建立连接。

为避免这种情况，以及更方便实现同步，我们需要尽可能让同一个白板内的所有Client连接到同一台服务器上。

这需要引入MQ来实现。所有的websocket服务都绑定到一个名称为locate的exchange中并接收来自网关的定位消息。如果对应白板的连接管理（Hub）在本机中，就把本节点的IP和端口等信息发送给网关服务，网关与对应Websocket服务建立连接。如果都没有找到，说明目前白板的Hub尚未创建，便使用负载均衡等策略随机与某个Websocket服务器建立连接。

![](https://pic1.zhimg.com/80/v2-1fc2955fa0939742d66e4cdfff3f3a34_720w.webp)

**Web端白板应用实现**

**整体架构展示**

Web端使用React框架来搭建应用，整体架构分为三层：UI层，逻辑层，渲染层

* UI层：处理用户 **交互** ，显示最终展示白板的Canvas。
* 逻辑层：实现白板 **核心逻辑** （比如undo/redo，使用ws同步白板等），与渲染层进行交互。
* 渲染层：**渲染**整个**白板**以及其中的元素，使用**双缓冲**加快渲染效率。

![](https://pic3.zhimg.com/80/v2-388a99a6dcc148920d2b2a4d7a6db3ce_720w.webp)

**基于原生Canvas的白板渲染方案**

我们将白板及其包含的所有元素构成的 **画面** ，抽象为 **RenderScene** ，其负责渲染自身元素以及在渲染结束后将自身**传递到UI层**展现给用户。

### **元素状态**

每个元素都有两种状态：**激活**状态和**正常**状态，所谓激活状态就是容易发生变动的状态（比如说**被选中**时，或者 **正在创建中，** 这个时候就需要让其从**背景缓冲**中分离出来。

![](https://pic2.zhimg.com/80/v2-851b2c4f5d4461a50f1a9188b7666971_720w.webp)

**双缓冲**

渲染层中有两个Canvas画板，其中一个作为 **背景缓冲** ，另一个用于**整个白板**显示，从而提高渲染效率，渲染时先绘制背景缓冲，再绘制激活元素。

![](https://pic2.zhimg.com/80/v2-e9bd6c47ba0637a726d5ffd30048b8b1_720w.webp)

### **渲染流程**

* 当逻辑层调用RenderScene的render()方法时

  * RenderScene会先将**背景缓冲**绘制到**真实画布**上
  * 如果有被**激活**的元素，则再绘制被激活元素
* 当逻辑层激活场景内元素时
* RenderScene**重新绘制**整个 **背景缓冲** ，包括除了激活元素之外的所有元素
* 调用render() 进行渲染
* 当逻辑层取消激活场景内元素时
* RenderScene将激活元素绘制到**背景缓冲**上
* 调用render() 进行渲染

![](https://pic1.zhimg.com/80/v2-2a23b1d19e3c7f4e109007d25d4ea9d8_720w.webp)

### **事件传递机制**

UI层可能接收到两种事件，来自桌面端的鼠标事件MouseEvent和移动端的触摸事件TouchEvent

* 我们根据**window.devicePixelRatio**对事件坐标进行变换，从而实现**dpi的适配**
* 将其分别转化成**InteractMouseEvent**和 **InteractTouchEvent** ，两者都继承自InteractEvent，分别对外提供统一的接口type（类型，比如down，up...) 和 x， y，从而实现事件类型的统一
* 传递到场景时，再根据画布缩放比例 **scale** ，再次进行坐标变化，将其映射到场景画布中成为SceneEvent，场景事件的去向有两个。
  * 通过逻辑层与渲染层的 **桥梁** ——工具(**Tool**类)的**op**方法 **操作RenderScene** ，对激活元素进行操作
  * 通过dispatchSceneEvent方法传递给元素，由元素**反馈**该事件是否与 **自己相关** （通过范围判断，返回布尔值）。

![](https://pic3.zhimg.com/80/v2-877df4a4c410ef2738a5459400036766_720w.webp)

### **同步机制的实现**

### **数据结构**

* 前后端之间使用命令(Cmd)进行同步，Cmd和Cmd的载荷(CmdPayload)数据结构如下

```text
enum CmdType { //枚举从最后开始添加
    Add, // 添加元素
    Delete, // 删除元素
    Withdraw, // 撤回
    Adjust, //调整单个属性
    SwitchPage,  //切换页面
    SwitchMode, // 切换模式
    LoadPage // 加载新页面
}

class Cmd<T extends CmdType> extends SerializableData {
    id: string; // 命令id
    pageId: string; // 操作页面id
    type: T; // 命令类型
    elementType: ElementType; // 命令操作元素类型
    o?: string; // 操作对象的id
    payload: string;  // 操作的 payload, 由于go无法绑定到确定类型，使用string
    time: number; // 操作的时间戳
    boardId: string; // 操作所属的白板
    creator: string; // 操作创建人的userId
}

type CmdPayloads = {
    [CmdType.Add]: ElementBase, //需要增加的元素
    [CmdType.Delete]: null //需要删除的元素
    [CmdType.Withdraw]: Cmd<CmdType> //需要撤销的操作
    [CmdType.Adjust]: Record<string, [any, any]> //p键值为操作的属性，[0]:before, [1]:after
    [CmdType.SwitchPage]: {from: string, to: string} //从from页面切换到to页面
    [CmdType.SwitchMode]: number //新的mode
    [CmdType.LoadPage]: null
}
```

* 同时**Cmd**也是实现**撤销/重做**的OperationTracker的 **状态维护者** ，可以与逻辑层统一一个命令执行接口

```text
export class WhiteBoardApp implements IWebsocket, ToolReactor {

    /* ... */
    public cmdTracker:OperationTracker<Cmd<any>>;
    /* ... */   
   
}
```

### **同步机制**

* 每种工具都可能是 **创建者（Creator）** 或者 **修改者（Modifier** ），由逻辑层注册对应onCreate和onModify回调。
* 在创建或修改的时候，**构建**对应 **Cmd** ，通过**Websocket客户端**发送到服务器，服务器**广播**命令到房间内其他用户。
* 其他用户收到Cmd时，通过白板逻辑层的 add/delete/adjustElem **ByCmd** () 等接口，使用Cmd的**Payload**对白板进行**同步。**

![](https://pic3.zhimg.com/80/v2-d6c5073f33fe7162d9d7f3366592bd0a_720w.webp)

**频繁写场景下的存储架构实践**

对于白板类应用，在极大部分情况下数据的操作为更改操作（写操作），并且频率非常高；
应对如何应对高并发的频繁写入操作，成为白板技术下非常重要的问题。
Redis Buffer

如果写入操作直接操作数据库（如MySQL），高并发场景下，数据库的压力会非常大。所以我们选用分布式内存数据库Redis进行数据的缓存，待合适的时机将数据持久化到数据库。

![](https://pic2.zhimg.com/80/v2-c376c90ac490b88f7f2ec9ac72539d45_720w.webp)

**Redis数据结构的选择**

**Redis的数据结构包括以下五种：**

1. **`String`：字符串类型**
2. **`List`：列表类型**
3. **`Set`：无序集合类型**
4. **`ZSet`：有序集合类型**
5. **`Hash`：哈希表类型**

下面介绍一下页面上元素的数据结构：

```text
class ElementBase extends SerializableData {
    public id:string;
    public type:ElementType;
    public x:number; // 左上角点的x坐标
    public y:number;
    public width:number = 0;
    public height:number = 0;
    public angle:number = 0; // 弧度制
    public strokeColor:string = "#ff5656"; // 十六进制整数
    ...
 }
```

要存储这样一个含有许多属性的对象在Redis中，一般有以下两种方案：

* 方案一：将整个对象序列化为一个JSON字符串，使用Redis的简单String，进行存储；
  * 优点：实现简单
  * 缺点：如果每次修改只会更改其中某少量属性（如移动只会更改有元素x,y属性），但是采用简单字符串的方式每次都需要重新序列化整个对象，再进行覆盖存储，效率比较低（主要从网络传输的网络包大小考虑）
* 方案二：将对象存储于Hash结构中，field存储对象的属性名，value存储属性值
* 优点：可以实现对该对象的某个或多个属性的精准控制
* 缺点：实现起来复杂

在我们的应用场景下，只更改单个或少数属性的场景较多，所以我们选用Hash结构进行存储
同时，如果我们要知道一个页面内所有的所有的元素的集合，如果采用元素的key值内拼接页面id的方式，必须使用Scan进行全局键的遍历。为了避免全局，选用一个Set结构用于存储一个页面内所有元素的id
Redis Pipeline操作

在白板业务场景下，无法避免需要执行多个Redis命令的场景（如读取整个页面上的所有的元素数据的hash结构）
管道（pipeline）可以一次性发送多条命令给服务端，服务端依次处理完完毕后，通过一条响应一次性将结果返回，pipeline 通过减少客户端与 redis 的通信次数来实现降低往返延时时间，而且 Pipeline 实现的原理是队列，而队列的原理是时先进先出，这样就保证数据的顺序性。

![](https://pic1.zhimg.com/80/v2-e0c55d004243e6137fc9b5c7663dec00_720w.webp)

使用pipeline可以批量执行Redis命令，非常有效地提高系统吞吐量
Redis集群方案

在整个系统中，需要缓存页面上大量的元素数据，应用的拓展性受到Redis存储容量的限制，并且单节点Redis可用性较低。所以有必要在架构中引入集群方案。
Redis 集群提供了一种运行 Redis 的方式，其中数据在多个 Redis 节点间自动分区。Redis 集群还在分区期间提供一定程度的可用性，即在实际情况下能够在某些节点发生故障或无法通信时继续运行。

![](https://pic2.zhimg.com/80/v2-7ce48678d5a010480025fa7561cfe519_720w.webp)

**Redis集群有以下特点：**

* 每一个master节点都有其对应的一个或多个slave节点，他们之间为主从关系，会进行主从复制
* 每增加一个key会通过一定哈希算法分配到某一个master节点，理论上可以实现存储能力的扩展

在白板应用中一般读取的场景相对较少，所有每一个master节点有一个从节点即可实现高可用的架构。


在七牛云校园黑客马拉松中，来自华南理工大学的SCUT01团队，为我们带来了UI精美、体验优秀的白板作品，在大赛中获得二等奖的好成绩。以下是这款在线协作白板的技术解决方案。

SCUT01在线协作白板技术解决方案

***在七牛云校园黑客马拉松中，一款设计优秀、逻辑清晰的白板作品脱颖而出，获得第二名的好成绩，这就是来自郑州大学Since团队的White Rose白板，以下是他们的设计和架构分享。***

![](https://pic3.zhimg.com/80/v2-91b0aae0f0ec3200a7bc36d5804f143e_720w.webp)

### **一、前言**

White Rose是参加七牛云hackathon比赛的作品，赛题的主要内容是开发一个「多人协作白板」，旨在鼓励在校大学生用编程创造价值。

赛题核心需求包含三个：

1. 多人可以加入一个房间，同时进行绘画（尽可能多的形状随意绘制）
2. 所有操作可以撤销和恢复
3. 可以创建不同页面，支持只读模式（页面锁定后，所有人不可编辑）

### **二、产品设计**

### **（1）愿景**

基于hackathon的比赛要求，我调研了一些白板软件，这些软件不乏有一些「操作困难」「功能繁杂」等问题。所以，我定下一个产品愿景：「做一款从两岁到八十岁都能用的白板」

### **（2）追求**

基于以上愿景我也设立了几条产品追求：「功能一键即达」「界面极致简洁」「内容高度自由」

作为乔布斯的粉丝，印象中乔布斯当年设计iphone时，要求工程师所有的功能操作不能超过3步，而对于白板一个单独的软件来说「进入」一步，「功能选择」一步，所以留给我的只有一步了。

### **（3）界面**

为了让界面足够简洁，我将所有「扩展」功能全部放到了「上下左右」四个隐藏菜单里，从而让整个页面除了四个「必要数据」外，就只有一块“纯粹的白板”。

* 对于两岁的小朋友来说进入就可以直接随意的涂鸦。
* 对于八十岁老教授来说，这用起来跟教室的黑板一样。

下面分别是整体的界面效果。

![](https://pic1.zhimg.com/80/v2-c1de8dcec9a94a86621b99d380390b90_720w.webp)

无论多大的屏幕，什么形状的屏幕，都会无失真的自动扩张，因为它本质是一个高宽100%的矢量图。

因为不同屏幕的大小限制，这样的设计可能回导致小屏幕的人看到的内容没有大屏幕的「完整」。

对于有些软件的处理可能会有利用「拖拽页面」功能来确保每个人所能接收到的数据一致，这将意味着，用户的每次触屏操作，软件都要区分用户是想「拖拽页面」还是想「绘画」，而用户也需要在两个功能间频繁切换。

而我的理解：“白板”本质是一个大号的草稿纸，当我们给一群人讲一些内容的时候，「演讲者」可能随手会在白板上写下他讲的关键词「power point」，一般作为「演讲者」会写在一个大家都能看到的地方，这对「演讲者」不会增加太大负担，而对于「听众」一边听内容，还要一边还要拖拽页面去确认演讲者写在那里，这个负担更大。

回想一下我们在教室上课的时候，老师会尽量把内容写在中间靠上的位置，而不是底部，因为前排同学会挡到内容。

所以我摒弃了「拖拽页面」的功能。

当然「缩放」也不乏是另外一种解决方案，但是也会徒增操作者（缩放）的使用负担，并且还会引入另外一个问题就是「失真」。

关于颜色：

其实在选择白板的底色的时候，可能就是一个白色，但是其实白色也是五彩斑斓的，该用什么呢？

我想到一个词「青红皂白」，索性我就用「青红」和「皂白」调制了一个对眼睛更加柔和的 「青红皂白色」作为白板的底色。

### **（4）拓展功能**

设计好了整个页面，接下来就是功能设计，我在设计界面的时候，预留了4个隐藏菜单栏来放拓展白板功能，为了让所有功能「一键即达」，并且更简单的使用，我采用了icon + 文字描述的方式，让用户更易理解。

整体展开如下图所示：

![](https://pic4.zhimg.com/80/v2-3d1f5ff315386ce37858fbe274f13d4b_720w.webp)

为什么是这样的摆放呢？

1、功能分类

根据赛题要求的功能，我将所有功能分为了四类。

1. 形状拓展：用户可以选择圆、长方形、菱形、三角形、直线等形状。
2. 颜色拓展：用户可以修改所有形状轨迹的颜色。
3. 大小拓展：图形的大小和线条的粗细可以切换。
4. 页面拓展：页面可以添加删除和切换，另外页面的内容支持撤销和恢复。

2、何处安放

我在想这个问题的时候，想象了在一张纸上作画的场景。

* 一般我们习惯在桌子右侧放上各式各样的水彩笔，方便我们切换颜色，所以我将「颜色拓展」放在了右侧。
* 我们习惯在桌子的上方和左侧放尺子、圆规之类的用来拓展图形和丰富绘画形状的工具，所以我将「形状拓展」「大小拓展」放在了左侧和上侧。
* 当我们要做翻书、撕页等页面操作时，一般会从右下角开始，所以我将所有的「页面拓展」放置到了下侧，同时右下角有一个对应页面的页码，也因为大多数书的页码在这个位置。

### **（5）自由布局**

上面讲到，我根据我个人的想法将各个功能进行了分类，并且按照我所理解的「更方便的布局」进行了排放，但在实际操作过程可能并不符合一些其他用户的操作习惯，比如：左撇子。

因此我将每个功能做了集成，并且可以随意的改变不同功能所在的位置，也就是所有的功能布局，用户可以根据自己的想法进行布局上的DIY。

### **三、架构设计**

因为本次开发的周期只有21天，另外工作日的白天还需要上班，非常紧迫。所以需要采用非常简单且高效的架构设计，当然也需要考虑一些后续扩展的可能。

（1）整体架构

为了更好的「持续集成」我们采用自建的gitlab管理代理，并使用gitlab-runner完成自动化部署。

整体架构图如下图所示：

![](https://pic4.zhimg.com/80/v2-dd6713649adbc5c45f549e8e40e6d0df_720w.webp)

（2）交互模型

对于后端来说，为了更加高效的沟通，我将整个交互模型，定义为一个群聊，群内所有人的消息统一发给服务端，然后服务端再统一转发给其他人。

后端只需要确认三点：1.谁发的消息。2.发到那个群里的。3.消息类型。

整体交互结构如下：

```text
{
"type": 1234,  // 操作类型
"fromId": 123, // 发送人id
"roomId": 1234,// 所在房间
"time": 152150025421564 //时间戳，前端不需要发送
"data": {} // 操作内容
} 
```

这样做的两个好处：

1. 所有消息有一个统一的时序（即服务端时间）
2. 后端完全无需关注「data」的具体内容。只根据type区分「接收」「分发」「存储」操作。

（3）data模型

data模型主要是前端所发送的和接收到的message里的data结构。

data里面该放什么？我将用户的所有操作定义为option，将用户的所有option放到data里面完成用户操作的转发。option的结构如下：

```text
interface Op {
type: number // 页面操作or图形操作
graph?: {
op: number // 添加、旋转、缩放、平移
type?: string // 图形类别
key?: string // 图形所对应的key
page?: number // 图形所对应的页面
content?: any // 图形内容
}
page?: {
op: number //添加、删除、切换页面
key?: number // 页面对应的key
content?: any // 页面对应的内容
}
} 
```

这样的每个option，我们都会存放到操作栈里面，结合另外一个缓存栈，即可实现撤销和恢复。

（4）多人协同

对于多人的操作，其实是多个人对多个图形的操作，人与当前所操作的图形是一一对应的。

所以我通过一个令牌集的概念，来存放「所有的用户id」，以及每个用户当前「所操作的图形id」，这样就确定下来个每个用户正在操作什么。

不同用户的操作通过以下流程完成：

1. 操作者设定当前所操作图形的id，并更新令牌集。
2. 接收者同步更新令牌集。
3. 操作者发送操作数据（option）。
4. 接收者根据用户信息从令牌集中确定所操作的图形，再根据option修改具体的svg数据。

整体白板从产品的设计到架构的设计就结束了。

欢迎体验：[http://whiterose.cf.since88.cn](https://link.zhihu.com/?target=http%3A//whiterose.cf.since88.cn/)

前端代码：[https://**lab.since88.cn/whiteros**e/frontend](https://link.zhihu.com/?target=https%3A//lab.since88.cn/whiterose/frontend)

后端代码：[https://**lab.since88.cn/whiteros**](https://link.zhihu.com/?target=https%3A//lab.since88.cn/whiterose/backend)


在七牛云校园黑客马拉松中，一款设计优秀、逻辑清晰的白板作品脱颖而出，获得第二名的好成绩，这就是来自郑州大学Since团队的White Rose白板，以下是他们的设计和架构分享。

White Rose设计与架构的想法分享

来自上海应用技术大学的「SIT-board」团队，在七牛云校园黑客马拉松中勇夺冠军，以下是他们的参赛作品——SIT-board远程交互白板的实现过程。

SIT-board 远程交互式白板的实现

在[之前的文章](http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=2652202350&idx=1&sn=55ceebc2e0dfc6c7ed3e0d54a8df278c&chksm=bd0153fb8a76daed8ab9ca4af0b43e69f839a421840b1f11ea284d6f0af76762cd591638408b&scene=21#wechat_redirect)中，我们为大家重点介绍了 HDR 的相关内容，相信大家已经能对「色域」、「动态元数据」、「码率」等概念如数家珍。七牛云全面支持 HDR，很多小伙伴们不仅有所耳闻，也在使用中享受到了七牛云功能强大、集成方便的转码服务。


## 屏幕：有用武之地

这年头，支持 HDR 的屏幕越来越多，但是用户在使用中，却往往会发出「这画面好像也没比之前强多少」的感叹。这个锅其实不能让屏幕来背，问题出在视频内容上。

虽然能够拍摄 HDR 的设备日益普及，但是目前市面上大多数的视频内容，仍然以 SDR 的标准来制作，这就导致用户拿着一块儿高质量的屏幕，但无法让它发挥出真正的实力。宛如 AWM 在手，弹夹却空空如也。

通过七牛云转码，SDR 内容可转码为 HDR，让视频平台能够为用户提供更具吸引力的内容，也让更多的好屏幕不被辜负。

![](https://pic4.zhimg.com/80/v2-b6a7ac6518f2e388ea56660f04dcd25f_720w.jpg)

## 画面：亮眼又出彩

从 SDR 转化为 HDR，最重要的特征就是变「亮」了，原本画面中「太阳」、「焰火」等元素，在 HDR 中终于能够让用户感受到如现实般的耀眼。这得益于转化过程恢复了 SDR 视频被压缩的动态范围，HDR 视频相比 SDR 视频，亮度峰值由 120nit 提升到 1000nit 甚至更高，从而使画面拥有更高的对比度。

在「亮眼」之外，「出彩」也是 HDR 视频的重要特质。与 SDR 的色彩空间相比，HDR 的表达范围从 0-255 提升至 0-1024， 色域空间为 bt2020，比 SDR 的 bt709 更加宽广，这意味着可以表现出更深、更丰富的颜色，与亮度提升一起，共同为用户带来更逼真的画面体验。

![](https://pic4.zhimg.com/80/v2-07ea9f1b7461c85222357f00511edecf_720w.jpg)
*亮度更高、颜色更深、色域更宽*

## 细节：不过曝，质量高

在 SDR 转化为 HDR 的过程中，往往会出现色彩失真、噪声、压缩失真等问题，导致亮度和色彩提升后，观感反而不如原画面。为了避免这些问题，七牛云 HDR 算法通过计算当前像素中 RGB 的差异来调整，使得相近位置相近颜色获得不同的增益强度，从而提升细节差异，防止过亮导致细节损失。

通过实测，相比于其他算法，七牛云转码后视频画面动态范围更大、细节更丰富、色彩更有层次感。

![](https://pic3.zhimg.com/80/v2-52d64838552e25a18c6a98d708753de6_720w.jpg)

目前，七牛云 SDR 转 HDR 功能已正式上线，欢迎大家实测体验。

更多的现实方法和技术细节，在下期「牛人说」中会为大家做详细介绍，敬请期待！


亮了！七牛云支持 SDR 转 HDR

**编者按：** QRTC 产品作为流媒体流量入口之一，背后有一套完整的支撑体系。而在整个体系中，核心是要保障业务场景的稳定运行，保障音画质量的正常展现，那么业务与音画质量提升的实践方法有哪些呢？

在 LiveVideoStackCon 2022 音视频技术大会上海站，七牛云资深架构师 刘诗遥，为我们详细解析七牛云 QRTC 背后的质量提升实践。

以下内容根据演讲实录整理。

大家好，很开心能在这里和大家一同探讨RTC类产品质量相关的话题。

![](https://pic2.zhimg.com/80/v2-ec92772a18d4a93f18925857fe252025_720w.jpg)

本次分享主要内容将围绕四个方面展开。首先，探索一下质量问题到底是怎样的一个问题。

**1、质量问题的探索**

![](https://pic3.zhimg.com/80/v2-e1889a4857bf098bca1512fe57f0ed7e_720w.jpg)

![](https://pic1.zhimg.com/80/v2-1ff50d2c9e177ac8e258f468bdeb9568_720w.jpg)

质量问题描述起来其实很简单，无论我们是使用RTC类型的产品，还是比较常见的微信、语音通话类产品，都会存在用户在某些时候体验不佳的问题。例如视频卡顿掉线、画质模糊、声音断断续续等问题，会让用户感觉这个实时传输或者通话类的产品它是不稳定的，那么要怎样做才能改善质量问题呢？

在讨论怎么做之前，我们先思考有没有办法对这几类问题进行分类。这三类问题中，视频卡顿掉线是传输类的问题，画质模糊是画质相关的问题，声音断断续续是音质相关的问题。那么，整个问题是否就是围绕传输、画质和音质来展开的呢？

![](https://pic4.zhimg.com/80/v2-19257bc76a9a700a4d05a6493b304dbf_720w.jpg)

首先我们来看下WebRTC的技术框架。从WebRTC的架构图中，可知在RTC上层统一的API下，隐藏了对RTC产品的三个分类，分别是音频、视频和传输。那么，这三方面是否与上述提到的质量问题有很强的关联呢？

![](https://pic3.zhimg.com/80/v2-52ad390596eb31aeba856c037d8847d6_720w.jpg)

我们继续挖掘音质和画质背后更深层次的原因。

音频路线中从采集到播放，会经历如图所示的几个环节：在采集到音频数据后，我们首先会使用3A算法对数据进行降噪、加强、回声消除等处理，然后会对音频数据做编码、压缩进行传输。在解码前，针对传输中的问题，设置了抖动消除和丢包补偿的机制，来达到音质高保障输出的效果。因此，音质与传输有一定关联。

然后我们再来分析画质。若使用RTC产品，在网络不好时会进行动态调节，如降低码率、分辨率，这也是围绕画质、针对传输线路的调整。

通过以上分析可知，若能解决传输质量上存在的问题，可一定程度上提升音质和画质。

![](https://pic3.zhimg.com/80/v2-cece2dd54900b4f5d2c66f226d32595e_720w.jpg)

RTC产品涉及的环节中有一部分是与传输质量强相关的。如图，是七牛云QRTC最初搭建时的架构图，它展示了从边缘接入到服务端处理的能力。图中红线圈出的部分都与传输相关：如从用户端到边缘节点接入的网络，从服务端到服务端的传输线路，同时这部分传输会涉及服务端流媒体处理和流媒体初始的与边缘节点相关的通信线路。

![](https://pic1.zhimg.com/80/v2-f781d14f325db44025ab21ae127f0170_720w.jpg)

我们再将传输问题细化可以分为三个问题点：服务间传输质量、接入节点的传输质量和弱网对抗。

于佳在 **《七牛云QRTC自研传输协议（QRTP）对音画质量的提升》** 的分享中已经为大家详细解读了七牛云是如何保障服务间传输质量的。那么，针对接入节点的传输质量和弱网对抗两部分，我们应该先聚焦在哪一部分？举个例子，接入节点的传输质量即从用户侧到接入节点这段网络的问题。这个问题分为两种情况，一种是自身的服务覆盖不足或当前线路抖动问题；另一种是客户网络有问题，即客户网络为弱网。如果我们能先保证接入节点能覆盖所有用户，那么下一步就可以重点考虑弱网对抗的问题。

**2、传输质量提升的实践**

![](https://pic4.zhimg.com/80/v2-d76134b213b66ebdca323effa088b2bb_720w.jpg)

因此，我们优先来解决接入节点传输质量的问题。

![](https://pic2.zhimg.com/80/v2-8b90175a003c197ceb750f27d450b9dd_720w.jpg)

提升传输质量可通过以下几种方式：一种是增加足够多的接入节点以覆盖所有用户；另一种是为用户选择最适合的接入节点，且能覆盖新加入且尚未被覆盖的用户。在这两种方案中，我们更倾向于后者，这样选择的考虑是：即使我们能够提供给到用户足够多的节点，但当用户选择其中某一个节点时仍有可能会出现卡顿的情况，此时我们考虑的重点应当是如何为用户选择连接本地情况最好的节点，才能更好满足用户的需求。

这里还有另外两种提升传输质量的方式和选择：一种是增加节点以覆盖全球每个角落；另一种是在有需求的地方增加节点，在这两种方案中，我们也更倾向于后者。举个例子，选择第一种方案时，如果我们当前在非洲没有客户，那么没有人会使用在非洲建立的节点，而当我们选择第二种方案时，即我们在非洲有客户后再建立节点，若用户使用其他线路可达到百毫秒以内的延迟，甚至无需再建立新的节点。

综上，传输质量的核心挑战可分为两个点：一是为客户选择最适合的节点，二是增加有需求的节点。

![](https://pic2.zhimg.com/80/v2-68ba0e65b556bc9cb21a44e682b9e771_720w.jpg)

接下来我们针对这两个点分别进行展开。首先是如何选择最适合的接入节点。与用户接入端连接质量最优的边缘接入节点即为最适合的接入节点。最适合的接入节点选择过程如下，首先获取当前机房和节点列表，了解线上可用的节点情况，然后对节点进行排序。我们初始产品上线时，采用的是地域就近接入的排序策略，即判断当前用户接入端IP所属哪个国家、省份、城市、运营商，然后为其配置就近接入策略默认的节点，这样可通过地域性的最近达到质量的最优。

但是这个策略有一个问题，针对以下情况：例如IP所属上海的用户连接上海本地所有的运营商的网络质量都较差，反而是连接浙江的运营商的网络质量会更好，那么此时地域就近接入排序策略就无法满足用户的需求，或无法更好提升产品的接入质量。针对以上问题，我们提出了用户接入端与接入节点相对最优策略为用户接入端提供最优质量的接入。最后，使用策略后可得到排序规则，然后对异常节点（负载过高的节点、线路不通的节点）进行过滤。经过以上三步，就完成了最适合的接入节点的接入。

![](https://pic1.zhimg.com/80/v2-1277cdbfacdc3e2b540af17226421abc_720w.jpg)

继续深入展开，我们如何建立用户接入端与接入节点间的规则。这里存在三种关系：用户接入端与接入节点建立连接，排序策略保障接入质量是最优的。从这三者关系里抽象出数据指标项去标识对象内容。可用IP来标识用户接入端，此外还有国家、省份、城市和运营商，这些内容与IP强关联。接入节点是服务端的边缘性节点，同样可用类似的信息唯一地标识接入节点内容，因此用户接入端和接入节点的关系是类似的。最后，考虑如何做质量打分策略处理，与质量相关的指标有低延迟、零抖动和成功率等，这几个指标构成了初始排序的起步阶段。

![](https://pic4.zhimg.com/80/v2-ddf5009dc2685cc29d8a7a42795af9ef_720w.jpg)

建立三者模型后，为了得到对接入节点实际有效的可量化的数据，要进行一系列处理。首先，针对已有的数据模型，建立数据关系的打点。定义的数据模型包括用户接入端的数据、接入节点的数据及两者之间的关系（延迟、成功率），这些内容通过RTC SDK的数据打点上报给服务器。基于上报的埋点数据，利用质量评估公式来评估两点之间的质量好坏，然后进行纠错，处理异常数据。最后当前输出的数据能辅助未知IP下发最优节点的策略。

![](https://pic1.zhimg.com/80/v2-2351508730c70fdc6d97358f0ee2e248_720w.jpg)

左侧是线上实际上报数据埋点的结构，包括了用户接入端的IP信息，国家、省份、城市、运营商四元组间的关系，接入节点的四元组关系和IP信息，以及当前两者是否建立成功、延迟大小的内容。

此外建立一个计算分数的公式，公式的核心是表示质量的好坏，分数越低，质量越好。公式中涉及到的因素有连接耗时，连接耗时与分数成正比，因此连接耗时最低时质量可能最好。因素还有连接成功次数，成功率越高时，分数越低，即质量越优。根据这个公式，可以计算质量分数。首先看第一个数据表，包含了用户接入端和边缘接入节点的统计数据，通过这个统计数据，可知用户接入端接入过哪些节点，它们彼此之间的关系如何。然后假定模型只与连接耗时单一关联，因为在这个过程中可用相同方式获取其他数据。

最后当一个同地域的未知IP进入后，可为其分配一个对其而言当前地域最优的节点，若IP有问题，也可为其分配之前接入过的最优节点。因此，通过再次统计数据，可知用户接入端所属的四元组关系（国家、省份、城市、运营商）和服务的四元组关系，彼此间哪一部分联系是最好的（分数越低，联系越好）。当用户接入端所属IP在四元组关系内时，只需下发相同地区的服务端的最优节点IP，就能给其一个最适合的边缘接入节点。

![](https://pic1.zhimg.com/80/v2-a7fe50f8a8b2f51b8c05b8c79304a554_720w.jpg)

整个过程中，我们完成了用户接入端可用节点返回、用户接入端IP最优可用节点加权和异常节点过滤。左侧的数据表包含了最终得到的数据，据此可寻找用户端与边缘接入节点间的最优数据，这构成了最适合节点分配的基础规则。根据这个规则，若当前IP已接入其他节点，且接入其他地域节点时质量最佳，那么将数据进行加权，这样就可为用户选择一个最适合的节点。

![](https://pic3.zhimg.com/80/v2-60bc6415a09471eb2b244c947156e576_720w.jpg)

客户端得到数据表后，RTC SDK内部还采取了其他优化策略。我们从两个点出发，优化客户端与最适合接入节点间的连接。首先，并行请求相同的节点列表，来解决某个边缘节点在传输过程中宕机的问题。其次，增加SDK并行连接，通过赛马机制来加速连接建立。

![](https://pic4.zhimg.com/80/v2-aa2037b413eceaaf54f843a89b311a13_720w.jpg)

至此，已解决最适合节点的选择问题，继续探讨如何增加接入节点。增加接入节点与机房和节点列表有关，也与用户接入端的数据有关，如某个用户接入端或区域的所有用户接入端可能与全部接入节点的连接都较差。当前区域所有节点连接的数据都较差，构成了增加接入节点的判断逻辑。

![](https://pic4.zhimg.com/80/v2-4510e16c3ac29ae42668e7f7cf05f94b_720w.jpg)

当某个IP连接IP所属节点的质量差时，意味着这个IP可能并不归属当前区域，只是被当前设定绑定在了这个区域，将其更改到正确区域即可。但若如表格中所示，用户接入端IP连接全部节点质量都差（表格中为连接耗时都很大）时，需通过增加接入节点的方式提高传输质量。

![](https://pic1.zhimg.com/80/v2-c6f234ea6baff2ed17bb7f87553507d4_720w.jpg)

最终得到的数据围绕着SDK的打点数据进行处理，通过统计运算可知用户接入端四元组关系（国家、省份、城市、运营商）、总的请求次数、请求过程中的最小连接耗时。这些内容构成最终增加节点的参考。

![](https://pic2.zhimg.com/80/v2-a3204d872b368ac59002082b9456d00d_720w.jpg)

增加接入节点的参考和下发整个接入节点的策略是提升传输质量的两个策略点。为用户选取最优的边缘节点进行连接，使得质量分数越来越高，或通过增加节点让连接质量越来越好，这个过程构成了传输质量的自优化。这意味着，当某个节点接入不佳时，可自动根据参考增加节点，当新增节点上线后，用户接入的情况会自动优化，可知哪些用户连接到这个节点的质量最优，通过数据建模和数据参考过程，达到了传输质量上的自优化。

![](https://pic2.zhimg.com/80/v2-2b5c66027e80b5f5217fc90d7afbb75d_720w.jpg)

我们的产品能满足RTC产品的基础功能。在基础功能之上，我们认为传输质量是核心点，传输质量的提升可带来整体效果的提升，也发现数据是质量提升方面的优化项。至此，优化尚未结束，因为画质和音质虽然受到传输质量影响，但也受到自身问题的影响，因此还需围绕质量参考数据，研究如何继续提升质量。

**3、业务场景中质量提升的实践**

![](https://pic4.zhimg.com/80/v2-b602ee8b5cb8aff9bbb77a09632648eb_720w.jpg)

![](https://pic1.zhimg.com/80/v2-23668a9de52256bd2d94e2ecd2595538_720w.jpg)

七牛云站在客户角度，根据客户对业务场景的质量要求，思考如何才能更好地提升业务质量。在语聊房时，会有声音嘈杂的情况，这可能是降噪方面做得不好，若有回声，就需要优化3A算法，在互动直播场景画质模糊或教育场景录制异常时，也需要进行相应的处理。这些是业务质量提升的原始需求。

![](https://pic1.zhimg.com/80/v2-a0d1e9757b4af7711544696cca7a1844_720w.jpg)

七牛云比较擅长的是社交互娱场景里的直播PK、语聊房，和教育领域的监考和大小班课，首先是互动直播场景。在互动直播过程中，客户要求低延迟、线路稳定、音质高保真、画质清晰等，这些要求可归属为接入端的传输质量保障、视频画面质量保障以及转推路传输质量保障。

![](https://pic2.zhimg.com/80/v2-bb6871e20cc8946390126f85aed22c65_720w.jpg)

类似地，语聊房也有一些相关的质量要求。

![](https://pic2.zhimg.com/80/v2-647c093f8497a5585c5e307972553711_720w.jpg)

教育中的监考场景要求三路监考，能做到全场留证。

![](https://pic3.zhimg.com/80/v2-4d3190e240e873a43bfc63b5b3ba8206_720w.jpg)

课堂场景中，保障多产品相关的内容。

细化场景后，我们思考能否按照优化传输质量的方式，通过数据进行质量的提升。

![](https://pic2.zhimg.com/80/v2-6a8ff1dfb7bdd31fc2ab49bd7841bb0d_720w.jpg)

传输质量数据和流媒体数据是质量数据统计的基础。此外，QoE进行了画质上和音质上的检测，是主观内容转换到客观的方式，是一种量化指标转换。MOS分转换也是量化指标转换，它是找相同的人评估相同的内容，然后打MOS分（1-5分）。最后，划分场景，通过数据指标搭建类似传输质量的策略自优化体系。

![](https://pic4.zhimg.com/80/v2-d678d3de45d229d45b9a564c9390a4d7_720w.jpg)

我们如何去做数据驱动。基于业务质量（QoE）的数据可构成当前音画质的基础，这是数据驱动的一部分。此外，传输质量数据是数据驱动的另一部分。

**4、以质量数据为驱动的产品体系**

![](https://pic2.zhimg.com/80/v2-8b110598ef420dd6879ac094cf259b6d_720w.jpg)

![](https://pic4.zhimg.com/80/v2-eecd9aceaf17d1d50c6b28f876e3464b_720w.jpg)

构建音画质量的数据体系，这是最直观的数据标签。构建当前直播间的样本数据，所有的指标是最原始的数据基础，构成了音画质量的数据基础。分析这些数据，可知不同场景下（如直播互动场景）的画质要求是什么，针对不同的场景，对画质进行优化，比如是否应该保证线路可传输更多的数据，保证分辨率是恒定的，在丢包可控的情况下，保证最优的画质传输。

![](https://pic3.zhimg.com/80/v2-574d925c1023c3be0a884043fea57306_720w.jpg)

另外一个是传输质量的数据体系。这个图不是凭空画出来的图，而是当前机房中部分节点间的传输关系的质量统计图，构成了节点间如何通过量化数据的方式来知道节点间的传输的依据。通过这样的方式，在当前场景下，若以低延时为核心进行优化，应找到节点间传输耗时最小的线路，并用这样的线路进行传输。直播场景对画质要求较高，可以接受一定的延迟，那么要寻找节点间传输稳定，但延迟稍高的节点。这些内容构成了数据的基础。

![](https://pic1.zhimg.com/80/v2-fe15f8ae40af54eec97b7e6c86b21b1c_720w.jpg)

这涉及到两部分内容，一是传输质量数据体系，二是音画质量数据体系。音画质量数据体系中分三类进行核心数据的优化和基础参考。首先是音频数据，对当前声音的好坏进行打分，然后是视频数据质量，最后是场景权重参数，不同的场景（如社交互娱场景、教育场景）带来权重的区别，划分场景的方式决定了不同场景的关注质量点不同。传输质量数据体系关注三个点：接入传输质量、机房传输质量和弱网对抗。完成传输质量的优化后，节点能覆盖所有用户，通过自研的传输协议可保证服务间的低延时和可控传输。那么接下来就要完成弱网对抗，保证客户端网络质量差时，客户可更好地使用产品。

![](https://pic4.zhimg.com/80/v2-111f6790eb3ae82fd5919de2a0ce407b_720w.jpg)

最后，通过数据体系的搭建，形成了以质量数据为驱动的QRTC产品体系。音画质量数据、传输质量数据不是体系化的思路，不能构成当前产品上的驱动点，只是某部分优化的手段和方法。

因此，我们分三部分对产品质量进行提升。第一部分是基础数据指标，包含了接入传输质量和节点相关内容。第二部分是业务质量，包括QoE针对音质和画质方面的数据内容，以及业务场景的区分。第三部分是质量数据运营，是针对下两层数据的运营策略，在不同的场景中，对接入数据和画质数据进行区别对待，在不同场景中使质量最优，并确定自优化策略，以及在通信场景里，策略要保证最低延时，在直播场景里，策略要保障稳定的画质。这就构成了以质量数据为驱动的QRTC产品体系。

以上是本次的分享，感谢大家！


QRTC 产品作为流媒体流量入口之一，背后有一套完整的支撑体系。而在整个体系中，核心是要保障业务场景的稳定运行，保障音画质量的正常展现，那么业务与音画质量提升的实践方法有哪些呢？

在 LiveVideoStackCon 2022 音视频技术大会上海站，七牛云资深架构师 刘诗遥，为我们详细解析七牛云 QRTC 背后的质量提升实践。

七牛云 QRTC 背后的质量提升实践

在线监考场景中，有哪些痛点和难点？七牛云在线监考方案是如何解决的？未来又有怎样的规划？在**「音视频实践日 Live」直播活动中，七牛云音视频解决方案技术专家宣利民，为我们就「在线监考场景的应用实践」话题带来分享。**

**本文内容基于宣利民分享整理，为方便阅读略有删改。**

---

大家下午好，我是来自七牛云的宣利民。今天我给大家带来的议题是在线监考场景的应用实践。

我的分享会从三个部分展开。首先为大家介绍在线监考的起源和背景，阐述在线监考场景的难点。第二部分会重点讲七牛云在线监考方案的实现与打磨。第三部分会给大家带来未来的规划。

![](https://pic3.zhimg.com/80/v2-9f4c85d367c550f12231479f8b16ca92_720w.jpg)

在线监考场景的难点

从在线监考本身来看，它很难成为一个单独的场景。因为监考首先得有考试，所以考试和监考其实是两个结合非常紧密的场景。那么讲监考之前，我们可以先讲一下在线考试。

考试本身有非常悠久的历史，比如我国历史上的科举，流程和监考过程都非常严谨。在线考试的历史，也可以追溯到上世纪九十年代的美国，目前已经发展到全球一百多个国家。在线考试利用互联网技术和计算机快速运算的特点，可以快速、准确地进行考试。

之所以能日渐普及，源于在线考试具备的优势。第一个方面当然是成本节约，因为考生可以在任何地方，只要有一台电脑就可以进行对应的考试。也就是说，整个过程是动态的，所有的组织不需要集中在一个考场里，是高度自动化的。如果考试选择题或填空题居多，整个批改的过程也会非常的高效和便捷，可以极大降低阅卷的工作量。同时阅卷全部是由计算机来进行介入，可以让整个考试过程更加公正，这对整个考试而言意义重大。

![](https://pic1.zhimg.com/80/v2-be8b99ec7526422832386cda2bc34ec8_720w.jpg)

作为完整的在线考试系统，面向的用户可见上图。从用户层开始，通过 PC 或移动设备进行访问，接下来会有一些前端的处理，前端通过各种协议，例如 socket 或者 http 对应考试或试卷，然后调到业务层，业务层里有考试、题库、考场管理、考生管理的业务单元，在底层会有数据库和存储。

那为什么七牛云要做在线考试、在线监考？它整个的市场规模如何呢？

![](https://pic3.zhimg.com/80/v2-75caa7d351dfb2f4a921806b0f8a8ff6_720w.jpg)

从几个方面来讲。首先是政策环境，自去年开始，国家对教育行业进行政策上的影响，所以目前职业教育会成为在线考试的新风口。第二个是经济层面，从宏观上来讲，因为在线监考可以有效降低成本，能够让整个社会运转成本下降。然后从文化环境来讲，疫情后的在线考试、在线办公都得到了极大的普及和爆发式增长，考生和组织方对线上考试的接受度也是有非常大的提高。最关键的一点，是整个技术环境有了质的发展，基于 5G 和 RTC 技术的成熟，使在线监考、在线考试的稳定性和监考的公平性，都得到非常大的提升。通过 AI 的引入，可以使整个监考过程中的舞弊行为被更好地甄别。

通过恒州智博研究中心的推演，在线考试的市场规模，从 2020 年的 31 亿将会增长到 2027 年的 86 亿，年均增长率达到 15.9%。所以从市场规模来讲，这其实会是一个比较有前景的行业。

![](https://pic1.zhimg.com/80/v2-e3dd9d3951cab49425f9649141564ef8_720w.jpg)

对在线监考来说，我们可以先分析客户的诉求。我们把它归为三个要点：首先是跨区域跨时间，然后是成本上的节约，最后是监考的公平性。除此之外，也有一些批量上传试卷和智能分析的诉求。

那分析客户的诉求以后，我们发现在线考试会有一个痛点。就是公正性，其实对任何考试来说，公平公正才是最被关心的一点。

![](https://pic3.zhimg.com/80/v2-ae3d17fd524a3a88e24263596456c37e_720w.jpg)

其实大家可以想一下，如果我在一台电脑上进行考试，会的题目就直接做掉了，如果不会，那这个时候怎么办？最简单的，可能拿着题目去网上搜索一下，然后可能立马就有答案，或者刚好我不会，我旁边请了个比较厉害的人，他跟我讲然后我来做。那这样的话，会严重影响整个考试的公平、公正，也会严重影响整个行业的发展。所以我们在线监考，其实是重点着眼于怎么确保整个考试的公平、公正。基于这样的情况，业务实现上的难点主要是远程人工监考下，漏检率要得到改善，要在监考过程中，对各种舞弊行为能够及时告警，后续也能进行及时复盘，包括数据、证据的一些落地。最后是在线监考会涉及到非常多的服务，我们帮客户快速把这些服务对接起来，更好地落地。

七牛云在线监考方案的实现

在这一部分的开始，大家可以先看下图，是我们七牛云的一些方案页面。

![](https://pic4.zhimg.com/80/v2-96126ed6107e5246b4f5ffb0dd733463_720w.jpg)

首先是设备的验证，要确保考生的麦克风和耳机是能够正常使用的。第二部分是需要确保考生能够进行身份验证，这里我们会带来七牛云身份认证的一些服务，会跟公安部身份证信息进行比对，确保人证统一，不会有替考行为出现。第三个重点放在考生答题过程中的一些动作。

比如作为考生来说，他需要做几件事情，一个是把摄像头打开，让监考者能够看到考生的行为。第二个是需要考生把自己的屏幕共享出来，整个屏幕上的操作在后端能够监看到。第三会让考生拿起他的手机，把手机架在自己的后方 45 度，确保考生周围是一片干净的场景，没有人员或者设备进行干扰，确保整个考试是比较安静的，没有其他人进行指点。

最后一图是作为监考者的视角，除了能看到每个考生的情况，我们也会把一些疑似舞弊的行为标注出来，便于监考者进行排查。监考者也可以跟考生进行语音通话，包括提醒大家注意行为，或者终止考试的进度。

那从这里可以看出，考生的两路视频流，一路是摄像头的，一路是手机的，再加上桌面的屏幕情况也可以被监看，所以可以很好地保障整个考场的公平、公正。

七牛云的在线监考方案，从核心模块上来讲会分为四个部分：

![](https://pic2.zhimg.com/80/v2-2a8dbd752ecf0b0a8e4eb85825c78ae1_720w.jpg)

第一个是实时监测，这也是最核心的功能。我们会通过三路流同时上传的形式，确保整个线上考场的稳定。那三路流会通过 RTC 的方式进行上传，延迟低至 200 毫秒以内，确保任何舞弊的操作都能够得到及时反馈。我们也是支持浏览器跟手机的同步进行，远程支持多终端，iOS、安卓、PC 都是能够支持的。

第二个功能是我们在整个在线监考里引入了 AI 的能力，包括考试前的人脸识别和身份验证。考试中我们会有一些人员隔离框的检测，包括我们会监控考生切换屏幕、复制粘贴的一些操作，然后包括所有的语音识别，来确保整场考生里没有额外因素的干扰。

第三个我们做了监考管理的功能模块，这里面就会有监考大屏。我们在整个监考的大屏里有两种监考方式，一种是视频流监考，还有一种是图像监考。视频流监考就会把考试的三路流转化为一路流，在大屏上可以实时监考。图像监考可以把考生的三路流集中生成对应的图片，图片监考辅以 AI 检测，会把对应的疑似行为提前标注，便于监考官能够更好地发现异常场景。

那第四个部分，是所有考试视频我们会进行录制，便于后期梳理。这里我们所有的功能都是通过 High-level SDK 接入的。

那什么叫 High-level SDK？High-level SDK 是基于具体场景，来提供不同版本的一些接口。比如说人脸检测，那如果不用 High-level SDK，那可能就需要先进行 RTC 流的截帧，截完帧以后上传到对应的存储，拿到接口以后进行接口的返回，再在终端进行展示。那我们这里就会把对应的流程包装成接口，就叫人脸检测，这样接口上就可以实现核心的功能。那这一块其实所有的 High-level SDK 接口，都是跟场景相绑定，用户对接起来会非常简便。

下图是我们在线监考方案的整体架构。其中可以看到，我们将其分为端和云两部分进行展示。端上我们会有屏幕共享、实时的监考和答题，进行对应的能力输出。然后用户可以集成我们对应的 High-level SDK，来封装它对应的客户端或者 web 端。

![](https://pic3.zhimg.com/80/v2-418cf0daadca4a6a3ac30a48305ac0c6_720w.jpg)

云上会用到非常多的内置功能，比如 RTC 里就会有我们最核心的屏幕共享，会有房间的管理。对在线监考来说，我们会把一个考生作为一个房间，那他的三路流就会作为房间里的三个所有者，包括一路屏幕流，一路摄像头的流，以及手机流。其中我们还会用到直播的一些场景，因为我们需要把对应的整个考试过程录制下来。我们内部也会打通 RTC 和智能多媒体的一些服务，提供对应的检测、身份认证等相关功能。

那最后，我们所有的机器日志、对应的打点日志，都会存储到我们机器数据处理平台去。可以让用户在后期进行对应的检索以及可视化监控。目前来说，在线监考服务了众多客户，整体非常成熟。

从整个方案架构上来讲，可以拆分成两类，一类是考生，一类是监考人员。考生需要做的事情包括两个动作，一个是进行答题，第二个是把答题过程实时推到云端，供监考官查看。

![](https://pic4.zhimg.com/80/v2-b1116c25ac1261d2a6fbe966396e219b_720w.jpg)

在这个过程中，首先考生需要在 PC 界面打电脑摄像头的流，然后进行考试题目的选择。这样在 PC 界面就会把两路流推到我们的 RTC 上，一个是属于监考电脑摄像头的流，还有一个是考试屏幕的流。同时我们要求所有的考生拿出手机，扫描屏幕上的二维码，就会自动进入考生自己的房间。那需要把他的手机，放在其后方 45 度的视角。这样从考生的视角而言，他需要把三路对应的流，推到我们 RTC 的云上。

对监考人员来说，一场考试可能面对一百个人甚至一千个人，那他需要监考到所有考生的情况。这里我们会重点给他一些对应的提示和告警，监考人员可以有针对性地选定某一个考生。如此一来，考官可以实时查看每个考生的三路流，如果有疑似情况，那他就可以进行对应的处理。

流转到了 RTC 以后，我们会打进流内部的智能多媒体，在这里面就会做对应的 5G 检测和替换。比如说屏幕上显示一个人，后面突然来了另一个人，这种情况我们就会进行对应的报警。那也有可能人没出现，但是声音多了一个，这样也会报警。

还有就是考生会进行屏幕切换，比如打开浏览器进行检索的操作，或者是键盘的一些特定操作，我们也能够监控得到。

以上就是我们在线监考的介绍。

接下来会为大家介绍我们方案的优势，主要有四个方面。第一是通过我们七牛云 RTC 的低延时和 AI 能力的结合，提升整个作弊的检出率，确保整个考试的公平、公正。第二个是通过我们实时大盘和过程数据的标注，可以有目的、有选择地进行实时监考，让老师的效率得到大幅提升。第三是通过 High-level SDK 的接入，可以帮助我们的客户大幅缩减开发成本，让产品快速上线，服务更多的客户。第四是因为我们的存储可以进行多样化选择，用户可以使用七牛云的云存储，如果用户有自建存储，也可以把对应的视频，放到自建存储里来缩减成本。

![](https://pic1.zhimg.com/80/v2-1be29ee3309b921ee49470beb3bb6964_720w.jpg)

在线监考方案未来的规划

接下来我为大家介绍整个在线监考方案的未来规划。其实刚才讲到，我们提供了 High-level SDK，它会让整个接入成本降低，用户不需要强大的开发能力也可以接入使用。

尽管如此，对很多客户来说，可能还是觉得会有一些门槛，所以基于这种现状，我们正在构建低代码平台。其中的核心概念，就是最大化降低客户的使用门槛。他如果想跑通标准的在线监考，如果没有太多个性化的配置，理论上不需要自己开发，直接使用我们的低代码平台就可以一键运行。它跟 High-level SDK 的区别是，完全不需要自己搭建后端和业务平台，我们的低代码平台还会提供所有的 UI 页面、后端逻辑和业务操作。

![](https://pic2.zhimg.com/80/v2-06ec8aaf89dcf947371ff944a2d7d989_720w.jpg)

为了更好地服务客户，我们的低代码平台将公用的业务组件进行封装，包括房间、连麦 PK 等具体场景的标准组件，以及服务端的能力和对应的 UI 的页面。那在低代码平台上，会衍生出在线监考、互动直播、电商直播带货等各类产品。客户如果需要对应的场景，就可以一键把服务跑起来。

![](https://pic4.zhimg.com/80/v2-7c332a79ea127ae4cd72ddbe5d3bda1f_720w.jpg)

目前来看，用户使用我们的方案，一两天就可以完整实现产品的上线。如果他有一些个性化的诉求，整个更改起来也是非常的便捷。

在低代码方案中，我们帮用户做的事情会比之前更多。我们不仅会帮用户画 UI、实现交互，也会提供用户的业务服务端，包括互动直播、PK、禁言、举手等操作。用户可以在我们的低代码服务器申请低代码的 token，然后把我们的低代码嵌入到他的自己的业务应用里面，然后访问整个低代码的服务器，其中会有各种业务组件，理论上就不太需要开发代码。目前这一块低代码服务端我们是开源的，所以用户可以部署在自己的服务器上。

对用户而言，通过下图所示的三步操作，即可实现集成。

![](https://pic3.zhimg.com/80/v2-61eb4d8c75e487978dc4a164e93678aa_720w.jpg)

目前我们新一代的低代码产品，理论上只需要十行代码就可以。如果它需要修改，可以在里面进行一些功能或者组件的替换。整个替换都是开放的，也非常便捷。

所以，低代码会作为我们团队接下来非常重要的一个方向，刚才讲到的各类监考场景，也会往低代码方向上迁移。希望通过我们的不断努力，为用户提供更加优质便捷的服务。

今天我的分享就到这里，谢谢大家。


音视频实践日 Live｜在线监考场景的应用实践

为了满足用户量较大且低延迟的需求，针对这种场景七牛云 RTC 提出了新的低延迟解决方案，从「RTC+CDN」模式改为用户直接使用 RTC 的方案，在大大降低用户延迟的基础上，也满足了多用户加入房间的需求。

**在「音视频实践日 Live」直播活动中，七牛云音视频资深开发工程师 张卓，为我们就「万人大房间低延迟技术方案实现」话题带来分享，重点介绍了**大房间低延迟技术方案对比，大房间信令网关建设和大房间流媒体网关介绍


**本文内容基于张卓分享整理，为方便阅读略有删改。**

---

直播间的观众朋友们，下午好。我是七牛云音视频开发工程师，现在主要负责 RTC 产品这块业务。今天我给大家分享的是七牛云在大房间低延迟技术方案的实现。

围绕这个主题，我们分三块内容展开： **第一、大房间低延迟方案对比；第二、大房间信令网关建设；第三、大房间媒体网关介绍** 。

---

**一、大房间低延迟方案对比**

我们先定义一下大房间。我们知道 WebRTC 主要是用来端到端通话的，当然我们也可以通过 SFU 中转来做一个视频会议场景。但是这种房间一般情况下房间人数不会太多，可能几十个人已经到顶。我们这里说的大房间，一般要求的可能是人数超过上万的情况。

比如，职业教育培训场景。如果培训机构需要的话，可以在全国范围内招比较有名的讲师，然后再对全国的教育培训的网点做一个视频直播。这样，一旦人比较多的话，传统的这种 WebRTC 加入房间，连麦的情况可能就不太适用了。

再比如，我们一个集团，全国都有分公司，如果开集团会议的情况下，我们也不可能说让所有的员工都进入同一个房间连麦，这种也实现不了。

所以我们这里说的大房间概念，一般指的是一个房间人数一定要多，比如说超过几千人，上万人。另外一个就是这个大房间不是所有人都可以发布的，解决的场景是把一部分人的音视频推出去，就是一小部分人推流，绝大部分人拉流的这种情况。

在业内，我们用的比较多的方式，一般是「WebRTC+CDN」。就是几个人连麦，我们可以用 WebRTC 方式做连麦，连麦后的音视频通过 CDN 转出去，这样所有的客户端通过 CDN 去拉流。这个方案现在是比较成熟的一套方案，一方面 WebRTC 本身连麦功能比较成熟，另外 CDN 节点做的比较成熟。

但是这个方案存在一个缺点，存在一定的时延。而且如果是多人，或者如果每个人想看到自己独特画面，这个是实现不了的。因为多人连麦导致出现的画面，首先要经过把多人的画面合成一路流转播出去，没办法针对每一个人，提供一个个性化的展示。

我们在实现大房间的方案是通过「WebRTC+SFU」，也就是 RTC+转发节点的方式。

我们可以对这两种方案做一个对比。如果我们用「WebRTC+CDN」这种方式，优点是能够支持很多人，因为对于 CDN 来说，客户端都通过 CDN 去拉流，那么限制它的只有一个带宽，只要这边厂商的带宽没有啥问题，拉的人数一般不成问题。

但是它也有一个缺点，就是单人直播的时候，直接把这个人的音视频流推出去就可以了，那么如果是多人的情况下，我们可能需要针对自己的业务场景做一次合流，可以在客户端，也可以在服务端去做合流，再把这个流转推出去。所以它中间经转的流程就是先连麦，再合流，再 CDN，再拉流。经过以上四步以后，延迟可能会稍高一点。

![](https://pic2.zhimg.com/80/v2-e729f1740926393b6025653b45a46a79_720w.jpg)

如果我们用「WebRTC+SFU」这种方案，第一我们只需要限制一下上麦的人数，具体拉哪些流，可以看每个人的需求，只需要去订阅就可以了，这样就不需要去做合流的操作。也就是每个人根据自己的业务需求去定不同人的视频流。但是这也有一个缺点，传统的 SFU 节点，没有办法承接一万人以上的拉流。这个方案优点就在，如果我们直接使用 RTC 这种方案，延迟会比较低。

所以对比这两种方案，一个延迟稍微高一点，但支持人数比较高，如果我们用 RTC 方案，延迟会比较低，但是对拉流的人数，传统的 SFU 没有办法支持上万人的拉流。所以针对这个，七牛云做了自己的一些优化。

---

**二、大房间信令网关建设**

***1、大房间信令网关-原架构***

我们之前连麦是正常一个用户进来以后，会给它一个房间，就是用户会开一个房间。房间的用户可以相互连麦。首先第一个用户进来以后，会有一个选点的问题。一个用户进来选完点之后，其他用户只要是一个房间，所有的用户都落到同一个 server。这样的话，这台机器的 server 就可以对连上的用户做一个转发。A 用户发的所有的信令消息，同一个房间内的所有用户都可以收到，房间内的其他用户的信令消息，也都可以通过服务转发给所有人。

![](https://pic4.zhimg.com/80/v2-4e574915eeed51bccf4f67e858a0793b_720w.jpg)

***2、大房间信令网关-原架构问题***

这个方案却存在一定的问题。第一个，就是受限于单节点能力，处理能力有限，无法支持大房间。第二个，就是调度能力问题，我们没办法提前知道这个用户分布情况是怎样的，只能确保第一个用户就近，无法保证房间内几方均衡。最后一个，就是抗弱网能力差，依赖加速节点的部署情况。

***3、大房间信令网关-新架构***

针对上面说的几种问题，如果要实现万人进场的情况下，我们对之前的架构做了一些调整。第一个调整的点是解决调度问题，我们专门搞一个调度的服务。用户进来之前，先会到调度服务上去选取节点，请求调度服务，然后让调度服务分配一个节点。第二，我们对之前单节点业务服务做了拆分。拆分成两块内容，一个是网关，一个是业务处理集群。网关这块主要负责用户的连接。业务集群这块处理跟之前差不多，存储用户房间内的信息。

![](https://pic3.zhimg.com/80/v2-08cc6a32cc6036341ac2b1c694cfe76e_720w.jpg)

我们先看调度，调度服务器负责将用户分配到最近节点，解决的主要是就近接入的问题。再看网关，网关负责用户信令和媒体的接入。而业务服务集群，则进行业务逻辑处理和相关信令的转发。

***4、大房间信令网关-调度***

我们这个调度服务主要做的是针对单用户来说的，我们理解的就是通常情况下，如果用户跟机房的物理距离比较短，本身网络情况也会比较好，用户一旦上来后，请求调度服务的时候，我们能够拿到对应用户的 IP 情况。我们会通过 IP 和 IP 地址库，查找用户所在地区，拿到对应的位置信息。

![](https://pic3.zhimg.com/80/v2-785f606ed2256ecf988731c6ceaea35a_720w.jpg)

除了拿到位置信息外，依赖另外一个 IP 质量的数据库，这个质量数据库存储的信息主要是某一个地区，到我们某一个节点的网络情况。这个数据来源有很多种，第一个就是我们通过 SDK 上报，能够实时知道网络情况。另外一方面，我们还有第三方特殊测速工具，针对服务器做测速，来拿到服务器的质量数据。有质量数据之后，我们 IP 数据库拿到对应的地区，再从质量数据库里面挑选出节点比较好的节点做一个排序。这就是服务端的情况。

在 SDK 端上，支持对服务器节点测速选点，并发建立连接，选最快的接入。

调度这块做完之后，我们就能够把用户分散到全国不同的信用网络的节点上。

***5、大房间信令网关-拆分***

关于服务拆分的情况，我们之前所有服务都是在一起的，也就是转发服务上面，服务器上部署的转发单元，还有业务处理单元。业务处理单元那块，包括信息的存储，用户进来、退出、验证信息。针对这块信息我们发现其实它是不经常变更的，所以我们针对这块信息做了一个拆分，直接把这块信息调到网关层。

![](https://pic3.zhimg.com/80/v2-6125482e95d2d44925443b466c6a562e_720w.jpg)

就服务集群，主要是做了以下几点：第一个就是全量信息做的集群，我们在服务器这块，会有一个全量的存储，对房间的所有用户信息全量保存。另外一方面，网关上有一些业务信息需要通过服务器进行转发，比如说用户进来之后，我们会把消息通知到集群里，然后集群再中转到所有房间用户，然后 Push 到 SDK。此外，我们还对外承接了一些业务接口。

***6、大房间信令网关-角色***

刚才我们说到除了对业务节点做一层处理，我们对用户的角色也做了一层处理。正常情况下，我们 WebRTC 进来之后，都会进行订阅和发布。如果真要实现万人房间的话，我们没有办法所有人进来都推流、拉流，所以针对这种情况，我们对用户做了一个角色拆分。第一个正常的情况下，如果需要推流的用户，会有订阅和发布的一个权限。如果其他用户他只能订阅。如果是有发布和订阅权限的，这种人我们把你加到主播类型的，或者是有发布类型的一个人。然后另外一方面我们就直接叫他订阅用户。

![](https://pic3.zhimg.com/80/v2-df497f05c8c59830d9dd9574deaca59e_720w.jpg)

我们在处理的过程中，一般如果是主播类型的用户进来之后，会把对应的数据同步到我们业务处理服务器上，通过业务服务器中转给所有这个房间内的信令网关和推到各个用户那里去，这样他们的流和所有的信息，其他用户都能够拿到。但是针对订阅用户，我们只让他连接到对应的网关，不请求中心节点去做处理。这样的话，整个中心节点，对于这个房间的处理，会变得相对简单一点。连上来的这种订阅用户，他是可以接收到所有主播的信息的，他也可以知道所有流的情况。

***7、大房间信令网关-优势***

总结起来，大房间信令网关的优势在于：「拆」，第一步就是把功能节点拆分，针对万人进房的情况，解决单点容量的情况。「调」，通过我们的调度选线，保障每一个用户都能就近接入，解决弱网问题。「拆」，针对用户角色的拆分，解决消息通知问题。

---

**三、大房间媒体网关介绍**

***1、媒体网关架构***

我们之前媒体网关，就是单节点，所有的人连到同一个 server 拉数据。那么现在拆分网关之后，因为用户登录的是一个不同的网关节点，所以他没办法做到连接同一个媒体节点。假如说连到边缘节点服务器上没有对应流，那么这个时间我们如何把流给转过去，这是一个问题。首先我们推流的用户，还是把自己的流推到对应的一个网关节点，一个边缘节点上。

![](https://pic1.zhimg.com/80/v2-7d8ef0787c5650c6d8fef07515b21fc0_720w.jpg)

那么其他用户在其他网关节点上，我们怎么去订阅？首先他连上来之后，他也会去进行订阅操作，他会先看下自己对应的边缘节点上，到底有没有自己需要的流。因为流上来之后，主播类型会推到所有人，那么他拿到这个流来订阅的时候，发现自己对应的边缘节点没有。没有这种情况下，如果当前节点已经有需要的流，直接进行订阅拉流操作；如果当前节点没有，看当前机房是否有相同的流，如果有机房内订阅；如果机房都没有，向路由节点进行订阅。

如果万人实现的话，我们可以使用几个机房边缘节点，都能够支持一个上万人的连接，所以效果还是可以的。

***2、媒体网关架构规划***

关于万人房间，我们后续还会有一个持续优化过程，大概分这几个方面。首先最主要的还是选线问题，解决使用过程中网络不稳定情况下网络选择问题。

关于媒体转发策略这块，就是我们现在媒体转发策略，也会持续优化，比如说就近接入，或者是找一个最优的转发路径。我们也会利用更多的数据，来选择一个更优的转发路径来减少空间转发或者拉流的策略，从而提高拉流的效率。

另外一方面，信令网关这块，我们接下来准备配套 Quic 协议，之前我们处理得比较多的是媒体。针对信令这块，也会加上其他的信令协议支持，一方面除了支持更多协议便于不同场景下 SDK 使用 ，也会利用其他手段，提升信令抗丢包。

最后，是大量边缘节点的部署，在全国部署更多的节点，支持更多地区的就近接入问题。

我今天的分享，就先到这里，谢谢大家。


音视频实践日 Live｜大房间低延迟技术方案实现

分辨率，一直是视频的硬指标，720p、1080p、到日渐普及的 4K，带给我们最直观的体验，就是越来越清晰了。然而在 4K 的屏幕上「数毛」还没几天，更加清晰的标准便来了——8K：我不是针对你，我是说在座的各位……

![](https://pic3.zhimg.com/80/v2-625bd98f5d54c2aa5e00b87cbe160fce_720w.jpg)

但是，我们真的需要 8K 视频吗？我们为什么需要 8K 视频呢？

首先从视觉体验来讲，4K 的分辨率是 3840*2160，而 8K 能达到 8192*4320，也就是比 4K 大 4 倍、比 1080p 大 16 倍。大，意味着更多细节、更强的画面冲击力，意味着大开眼界的全新感受。但是……

*「4K 就够了，再清楚也看不出来」*

*「8K 又没内容，去哪找 8K 资源呢？」*

*「我的电视还是 8 年前买的，根本不支持」*

*……*

其实类似的论调已经存在了几十年，比如 94 年开拍的《老友记》，按照当时的电视标准，完全没有必要使用 35mm 胶片摄像机，但也正是因为坚持采用了更为高清的胶片拍摄，才能让我们在时隔近 30 年，仍然以优秀的画质看到这部经典作品。时至今日，「超采样」已经成为影视制作者的共识，但 8K 真正凭显示效果碾压 4K 的舞台是——VR！

![](https://pic2.zhimg.com/80/v2-78395539a952fd382426b8db968e967d_720w.jpg)

目前全景视频仍以平面画面存储，并通过球面化变形呈现出全景的观影效果，导致其实际观影角度下的 PPD（ Pixel Per Degree）大打折扣。简单来说，在 VR 的场景下，4K 刚刚够消灭「纱窗感」，8K 起步，才能真正沉浸在虚拟世界中。

而眼下更多的场景中，也不断有 8K 出现。央视 8K 频道在年初已经上线，并为我们带来了前所未有的超高清冬奥赛事转播；越来越多的流媒体平台在技术升级，「8K」的标签成为视频质量的保障；市场上支持 8K 标准的设备越来越多，8K 电视、8K 相机不再是价格高企的奢侈品，正在走进我们的生活。

![](https://pic2.zhimg.com/80/v2-2122599f746a5d33183767495d24d541_720w.jpg)

> *图片来源：北京日报*

所以可以说，选择 8K ，就是选择未来！

那么问题又来了？

如何在 8K 时代将至未至之时，抢得先机提前布局？

七牛云 8K 视频转码入口，现已全面开放！

两大理由，你值得信赖！

1、低码高清

七牛云自研的锐智转码，支持最高可达 8K(8192*4320) 分辨率的视频，支持 H.265、H.264。通过对图像的降噪、纹理增强等处理，七牛云锐智转码可以在保证画质不变的情况下，减少 25%以上的码率，实现降本增效。

![](https://pic2.zhimg.com/80/v2-9e753fdc5c61ca233476a76ce661ffa9_720w.jpg)

2、技术提升

针对解码器和编码器的转码性能，七牛云技术团队进行了优化提升。在不降低画质的前提下，可以提升编码解码的速度。针对 H.265 解码，七牛云转码编解码团队通过指令集加速等手段，对解码器实现加速处理，让数据在流转过程中减少不必要的拷贝。

![](https://pic1.zhimg.com/80/v2-71e5a5e71a7fd54cbd52eeacb7ea7d2c_720w.jpg)

总而言之，优化的高性能视频编码算法，加之七牛云机房的全球化部署，七牛云锐智转码 8K 入口，轻松应对增长的资源需求，让我们提前看到未来！
