「回顾2022，展望2023，我正在参与2022年终总结征文大赛活动」

1 概述

回顾2022，感触还是蛮深的。做过很多事，但是这些事情，都是在资源(软件、硬件、开发者)有限情况下完成，所以，现在回想起来，感觉很心酸。

身处一些小公司的开发者，想必和我的感受一样，老板什么都不提供，就想让开发者开发一个“火箭”出来。

比如，我司接到了一个数字乡村项目，其中有一个功能就是，将某乡村的各个摄像头以国标的形式推流给我司的应用软件界面上。但是，却让我犯难了。(1) 客户不提供任何关于国标的测试例子，只能自己去搭建环境，自己推流，自己拉流；(2) 公司不提供国标的摄像头，我只能自己模拟摄像头，或者自费购买国标摄像头(不能报销)。真是面向虚空编程......

上面吐槽好像有点多了，现在回归正题。

下面做一下自我介绍。

我是一名桌面软件开发者，主要用Qt和OpenGL做三维可视化开发。

回顾2022，我主要做了三件事，(1) Qt控件开发；(2) 云渲染；(3) 集群渲染。当然，我还做了一些其他的事情，比如：3dtiles、AR、视频流等，不过，这些事情现在都是半成品，拿不上台面。

下面我所总结的，都是一些使用方面相关的，如果要深入到底层，那可能有些不现实，因为我也没有彻底搞懂底层......

2 Qt控件

为什么我要做Qt控件开发，因为公司的三维可视化引擎在图表这块，功能很有限。比如，要展示某项数据的统计图，公司的引擎短时间没法完成。

由于项目种类繁多，如某军校科目训练、某工厂流水线组装、某油烟机设备组装、某武器仿真等，各种各样的数据，都需要可视化。

开始，我想着找一些开源库来使用，发现开源库的资源不全，都是以某一个功能点。

后来想着购买别人成品，但是收费着实有点贵。

比如：QtitanRibbon(如下图)

确实漂亮，但是价格也是高的吓人。

所以，想让公司购买这些成品，有点天方夜谭了。

2.1 Qt学习简述

如果要描述如何学习Qt，那估计用一本书，都无法讲完。因为Qt涉及的知识点还挺多的。

所以，我不打算说如何学习Qt，只能说一下心得。

Qt做软件开发，主要有两个方向，一个是传统C++的开发方式(简称widget)，另一个是js开发方式(简称qml)。

qml开发方式非常简单，也相当漂亮，开下面一个简单成果。

但是qml有一个不好的缺点，就是和C++通信非常方便。因为任何软件，底层的数据管理、算法等，基本都是用得C/C++。所以，用qml开发完界面后，就要考虑如何和C++通信。由于这方面Qt公司做的还不是特别完美。所以我现在基本上都是用widget做开发。

心得如下：

(1) 会UI构建和样式搭配

(2) 对样式表和QPainter非常了解，这样就能自绘或改造了很多控件，有随心所欲定制特殊功能的能力

(3) 了解mvc模式(模型-视图-控制)，对Tree控件的功能几乎开发到极致，并扩展了很多功能

(4) 海量数据的展示技术，展示千万级别的数据，可能略微卡顿，百万级别的基本没什么问题

(5) 大量数据的EXCEL格式化导出，多种方案

(6) 完成一个稳定的与下位机通信的网络框架（TCP+UDP），包容如设备断电、软件异常崩溃、网络异常等各种异常情况的处理，及数据断点的续接收发。

(7) 一个纯自绘的批量对象操作选区、一个编程式的表格（含错误检查）、一个多轴灵活操控及定位的图表

(8) 串口编程（设备维护升级）

(9) 万用表通信，SCPI标准命令（设备校准）

(10) 多语言版软件及安装包制作、产品版本管理

......

2.2 Qt一些作品展示

一个软件的主界面，就是该软件的身份象征。我开发Ribbon(Office界面风格)，作为某些项目主界面。

Office风格菜单，我也做了一份

某典哥的图表控件，我也实现了一部分

2 云渲染

什么是云渲染，就是将三维可视化程序，放在一台高配的计算机上运行，将程序可视化界面以流媒体的形式，推送出去，用户通过普通的手机、PC等终端，使用浏览器直接查看三维可视化界面，并可以流畅操作三维可视化界面。

说白了，就是以下几点：

三维程序所在的计算机，进行截图，存储成视频
将视频发送给服务器
服务器将视频实时发送给终端用户，终端用户通过浏览器或者程序查看视频流
终端用户在视频上进行鼠标、键盘、触摸操作，操作指令发送给服务器，服务器将指令转发给三维程序

所以，云渲染的核心就是流媒体(视频流)。

在研究云渲染，主要经历了三个阶段，闭门造车、视频流技术调研，webrtc研究。

2.1 闭门造车

在研究云渲染初期，我曾经闭门造车的一段时间，过分高估自己的能力，以为自己能造一个轮子，现在回想起来，真的很幼稚。

闭门造车的大致思想，如下图：

新建 Microsoft Visio 绘图.png

(1) 将三维可视化界面截图；

(2) 将截图，分为m * n小块，m和n的具体值是一个经验值，开发者自己尝试；

(3) 前后两帧图像的m * n小块图像进行对比，如果后一帧的图像小块和前一帧不同，那么就将后一帧图像小块发送给服务器；

(4) 服务器将图像小块分发给各个终端(手机、PC等)。

下面看一下效果

从效果图上看，貌相效果还可以。

但是，在互联网上部署后，简直惨不忍睹。局域网下，效果还行。

2.2 流媒体调研

从自己闭门造车后，有一点感悟。

要想自己能独立造一个轮，除了有高深的理论基础，还要精通各种算法，以及高超的计算机编码能力。

我发现，上面三点，我一点都不具备。

这里顺便吐槽一下：

引用“罗太君”一句经典名言：“我们都是方案整合商，你装什么装”。

老罗的话不好听，但确实反映了国内技术的现状，从硬件到软件，我们能拿出的东西真的是少之又少......

貌似扯远了

明白了“我们都是方案整合商”的真理后，我就明白了，自己造一个流媒体协议，真的是太难了。

于是，我调研了一下，现在市场上主流的流媒体协议，分别是rtsp、rtmp、hls等，当然还有其他，如http-flv等。

下面对这些流媒体协议做一下总结：

协议	说明
rtsp	rtsp协议，是开源的视频流协议，该协议延时较低，在2秒左右
rtmp	rtmp协议，是不开源的。延时在2秒~3秒，浏览器原生不支持，需要安装flash插件才能播放rtmp协议的视频流。
hls	hfs协议是苹果公司推出视频流协议，延时较大，约有10秒左右

可能此时，有些“杠精”要怼我了，“我们公司的rtsp可以保持在2秒延时”。

但是，一项技术被研发出来后，它就决定了它的上限。(不理解？请看下面)

rtsp、rtmp和hls等流媒体协议，他们的诞生，是为了多人能同时访问，说白了，就是为了直播或者视频会议。

所以，它们的延时一般都在2秒左右，甚至更高。

有些公司对这些流媒体协议进行了定制和优化，确实可以更低的延时。但是，就算延时再低，能保持1秒以内的延时吗？

还有一个问题，这些流媒体协议，原生不支持持浏览器。

然后，我就找了一下前端播放这些流媒体的解决方案。

前端播放这些流媒体的有：ckplayer、videojs、LivePlayer和flvjs。当然还有其他的，在此不一一列举。

前端方案	说明
ckplayer	ckplayer支持http协议下的flv,f4v,mp4（谷歌浏览器可用），对于rtmp需要flash支持（仅在IE下可以）
videojs	Videojs需要flash才能播放rtmp（仅在IE下可以）
LivePlayer	通过云平台转码（需要购买，价格昂贵）实现rtmp的支持
flvjs	flvjs仅支持http-flv协议，需要将rtmp转为http-flv后才能使用，且不支持手机浏览器。（谷歌浏览器可用）

由于作者的能力有限，上述如有错误，请勿喷。

下面看看rtmp效果

这是1920 * 1080分辨率的桌面进行rtmp推拉流效果。

下面看看rtsp效果

从效果图上看，rtsp比rtmp要好很多。

其他协议效果图就不在此展示。

思考：为什么不同的流媒体协议，延时差异较大？(下一小节回答)

2.3 webrtc研究

从常见的流媒体协议调研后，没有找到一种符合云渲染需求的流媒体协议。在查找资料时，发现了webrtc。浏览器原生支持webrtc，这一点就深深的吸引了我。

看一下webrtc的原理图

WebRTC为了实现实时的点对点双方音视频通信，需要解决媒体协商和网络协商问题，引入信令服务器(Signaling Server)和STUN服务器的会话管理，需要一个信令服务器来实现双方通过网络进行连接。信令服务器的作用是作为一个中间人帮助双方在尽可能少的暴露隐私的情况下建立连接。WebRTC信令指建立、控制和终止通信会话的过程需要交换几个信息：媒体信息、网络信息、具体业务。

媒体信息，需要媒体数据来确定呼叫者和被呼叫者共有的编解码器和媒体类型。通过使用会话描述协议（SDP）格式的提供和应答在对等方之间交换媒体配置信息的信令，通过SDP协议描述信息，最后通过信令服务器中转。

网络信息，多个客户端通过信令服务器交互双方在网络（局域网或互联网）上的位置（IP地址和端口），以便呼叫者可以找到被呼叫者。

关于webrtc的原理、测试demo等，同学们去官方查看。

这里不做深入的讲解。(因为作者也没有搞懂)

下面看一下webrtc效果