如何开发一款会议室(音视频)产品？好像有点难

[dnjat]

上头交给年后任务，开发一款用来在线教育的音视频软件，先让我先研究一下，然后规划下流程方案和技术选型，主导这个软件的开发（我会 c++,java ，另外两个会 java ）。

本人无音视频开发经验也无理论知识，完全从头开始研发。

为什么不用市面上已有产品？因为要交钱，老板希望有自己的产品，方便日后扩展，升级，满足他的控制欲，为称霸扫平道路。

👑希望能得到音视频大佬们的指点👑。

软件需求：

1 、桌面端界面使用 QT ，移动端界面使用 Flutter 或原生。

2 、业务库统一用 C++实现，多端界面端统一调用业务库（粗略了解到过程中还有交叉编译之类的，不知道是不是很复杂）。

下面是我这两天的查阅，拼湊出的一个简略框架和流程：

大体框架：

1 、桌面端界面使用 QT ，移动端界面使用 Flutter 或原生。

2 、业务库统一用 C++实现，多端界面端统一调用业务库（粗略了解到过程中还有交叉编译之类的，不知道是不是很复杂）。

大体流程：

1 、通过 gRPC 传输信令，建立 WebRTC 点对点连接（这里打算直接用 P2P 建立连接，涉及到 NAT 穿透，如果穿不透，使用 TURN 做中继,用中继后所有流量都得走服务器，人一多，对服务器带宽是个挑战，基本一个 5M 带宽，最多支持 5 个一对一，那得多少带宽才能带得动）。

2 、教师通过系统 API 捕获屏幕，摄像头采集，麦克风采集，通过 ffmpeg 处理后，用 WebRTC 传输。

3 、学生端直接使用 WebRTC 显示。

使用 WebRTC：

使用 WebRTC 比较方便，有网络自适应。但好像只能在浏览器中使用。

WebRTC 也有 native 库（原生 native 库，metartc ），直接在 C++调用，不知道坑多不多。

不使用 WebRTC:

采用 RTMP/RTSP 传输，ffmpeg 解码后，用 OpenSL ，OpenGL 之类自己做渲染。

疑问：

1 、使用 WebRTC 方便 还是 用 RTMP/RTSP 传输后自己解码显示？

2 、如何避免/减少点对点流量对服务器造成的带宽压力？

这中间有的地方可能理解得不对🐞，希望得到大佬们的批评指点🌻。如果有不错的学习资源，帮忙推荐一下🎁。

软件需求贴错了，不能修改了。
软件需求：
一对一的模式，一方开启投屏(教师端)，另一方进行观看(学生端)，支持语音对话(后期可能会扩展荧光笔这类标记功能)。
支持多端，桌面端(windows,mac)，手机平板端(andorid,ios)。每个端都支持教师与学生。

[iOCZS]

降噪、回声消除这些你们自己就搞不定的。。。

[leonlx]

为啥用 Qt ，你们很熟悉其技术栈吗

[dnjat]

@iOCZS 自己写肯定是不会写了，看能不能网上扣个算法下来，或是用 WebRTC 自带的处理。
好像还有音视频同步，也挻难的。

[dnjat]

@leonlx 会 c++,了解点 QT ，觉得这个会好下手点。查了下资料，看用 QT 来做音视频也挺多的，方便跨端。

[iOCZS]

@dnjat WebRTC 是有处理的，看看有没有现成的开源，直接跑起来看看效果如何

[iOCZS]

2 这个问题就涉及架构问题，综合来看，多方通信架构无外乎以下三种方案。

Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A 、B 、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A 、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
MCU （ Multipoint Conferencing Unit ）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
SFU （ Selective Forwarding Unit ）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

我估计你们会采用 SFU 架构。

[dnjat]

@iOCZS @iOCZS 软件需求贴错了，不能修改了。
软件需求：
一对一的模式，一方开启投屏(教师端)，另一方进行观看(学生端)，支持语音对话(后期可能会扩展荧光笔这类标记功能)。
支持多端，桌面端(windows,mac)，手机平板端(andorid,ios)。每个端都支持教师与学生。

也想过一对一也用 SFU 架构，但想着如果有 200 组同时上课，像一个 5M 服务器，最多就 5 组的并发量。这个带宽是个压力。想着 NAT 穿透，两个不同的局域网通过公网点对点，基本不可能，只能走服务器了。

[gaobh]

做这玩意太麻烦了，不知道给了你们多少钱投入，带宽，延时，波动，分辨率，帧率，视频采集，摄像头采集，扬声器，麦克风采集，解码器，录制，传输，代理设置，账户，存储，热活冷备……每一个都够喝一壶的

[dnjat]

@gaobh 有什么简便的方案推荐吗，是挺难的，很多资料说说没个三，五年经验，很难开发出来。 只要一对一投屏🤣

[wentx]

是不是可以基于 Livekit 去做一些修改

[foxhunt]

@iOCZS 确实是行家，当年我们搞视频会议，降噪回音这块还专门找的人来进行的处理，但效果也不是特别理想

当时为了降低主讲端的压力，采用的是 SFU 架构，加 N 个中转服务器对数据进行转发

[GeekGao]

直接用声网 sdk 吧，别折腾，在不依赖于其他 sdk 的情况下你们大概率无法在 1 年内搞定的。

[zhangyb123]

这种可以直接研究开源的产品，比如 github 上的 Telegram

[dnjat]

@wentx 不错的开源项目，我先去关注下，看适不适合二次整合。

[dnjat]

@foxhunt 如果是一对一视频会议，也走服务器做数据转发，服务器的带宽是不是会要求很大

[iOCZS]

@dnjat 音视频的成本就是高的，不过你们这种一对一的，其实还是算简单的。但是正如你说的，如果需要 NAT 穿透，流量还是要走服务器，无法 p2p 。

[dnjat]

@GeekGao 这个领域是挺难，之前调研了三方 sdk ，就是要钱，老板想着自己开发一个吧。只要一对一投屏（一方投屏，一方观看），自己研发是不太可能，看不能借助开源项目，整合个最小可用的框架出来不。

[dnjat]

@iOCZS 如果流量走服务器，一台服务器并发不了几个一对一，走服务器反而适合一对多的这种。

[dnjat]

@zhangyb123 看了下 Telegram ，带有这样的功能。有源码，是个好的研究方向，太谢谢了。

[foxhunt]

@dnjat 占多少带宽，可以算出来的
看一组教学有几路视频几个屏幕共享，根据码流算下就行

[maxwel1]

你们三个搞下来，成本肯定要比直接外采多的多。当然不一定能搞出来

[foxhunt]

说真的，这个东西重要的是稳定性和用户体验
自己搞，真的划不来

[HenryDai]

我觉得要兼顾稳定性和可用性，从 0 到 1 太难了，吃力不讨好。可以看看 jitisi ，我之前给我的领导部署和魔改过 我觉的效果还算不错，开源协议友好。https://jitsi.org/

[dnjat]

@foxhunt 一对一，三路吧。一路教师屏幕，两路双方摄像头。 翻阅了资料，确实开发也很难，还没算开发出来后的运营成本。

[dnjat]

@maxwel1 是的，算下来，投入是很大。三个人搞一年就是多少工资了，还有后期带宽，觉得也是个大头。看扣开源代码这条路看还有戏没了。

[dnjat]

@HenryDai 噢，你在 jitisi 上二次开发过，这经验太好了，至少在魔改的过程中，能坚信它是能成功的。这个从 0 到 1 的魔改过程，你花费了多久？方便分享下嘛

[HenryDai]

@dnjat 我记得当时我和另一个同事改起来十分吃力（比如要改按钮的位置无从下手），哈哈哈，我建议是根据官方的配置修改一下配置就好了（比如更换图标，换个背景啥的），跳转到私有化的 jitsi 这样子的。

[vopsoft]

口罩刚开始时 常见的视频会议都崩溃过 只有 zoom 没事 事实上日常用 zoom 也优于其他视频会议。zoom 作者原是负责思科会议的。这东西还是有很高的壁垒的。楼上说的对 直接用声网的 SDK 吧

[dnjat]

@HenryDai 好的，谢谢，我去研究了解下。

[dnjat]

@vopsoft 嘿嘿，好的，大家都谈虎色变，看来这家伙确实不好惹。😊

[ysc3839]

Open WebRTC Toolkit 就完事了，客户端用 Electron 等浏览器套壳方案，服务端是 Node.js 。

[awing]

我们自己从头用 Rust 开发了 SFU 服务端（我们有自己的 P2P 和 SFU 融合模式），当然也支持集群： https://github.com/binbat/live777

可以把 SFU 作为中间件，业务流程（业务用异构问题也不大）基本上可以不去处理音视频相关的东西。当然也可以找我们要技术支持

其他的同类产品

比较高级的封装可以考虑：livekit, jitsi

更底层的 SFU 服务可以考虑：mediamtx, atm0s

* * *

> 1 、使用 WebRTC 方便 还是 用 RTMP/RTSP 传输后自己解码显示？

RTMP/RTSP 已经半截入土了，没有兼容其他系统需求的话，没必要用

> 2 、如何避免/减少点对点流量对服务器造成的带宽压力？

如果只有一个老师和一个学生的情况，可以考虑在这种情况下用 P2P 。不过这样如果有录制需求就需要单独的处理逻辑

[mgrddsj]

除了上面说的 Jitsi ，也可以参考一下 OvenMediaEngine ，也是开源的。Jitsi 似乎是用 Java/Kotlin 开发的，而 OvenMediaEngine 是 C++ 的。而且 Oven 系列也有一些现成的客户端配套的东西。

不过我没用这玩意进行过二次开发，只是部署过它，但它文档里也有一些二次开发相关的指南。仅供参考。

[wnpllrzodiac]

买个服务得了，零基础上强度。没个三年能出来？

[dnjat]

@ysc3839 听了大佬们的建议,打消了从头开发的想法,大家推荐了很多超出我认知的三方框架,了解后也觉得他们的支持非常好,后面要站在巨人的肩膀上,它们非常重要.谢谢建议.

[dnjat]

@awing 能把这个框架从头开发,你们团队太历害了.后面拜读下项目,更详细了解下.
同类产品,上面许多大佬推荐了优秀开源框架,了解后,感觉 livekit 会比 jitsi 支持更的 API,二次开发的灵活性会更高一点.但 jitsi 好像更热门一点,后面都测试一下,看下效果如何.
P2P 的情况,我们打算优先点对点,不走服务器.录制另外想办法,或提供另外的录屏方案.
就 P2P,两个不同的外网,穿透到两个不同局域网,不知道建立 P2P 容易不(不修改任何其它网络设备的情况下).

[abelmakihara]

这种能买服务的想想就知道有多复杂了
不复杂能卖服务？

[varxo]

livekit

[dnjat]

@mgrddsj 哇,这个 OME 很适合做一对多(直播)的这种情况,收藏了.谢谢大佬的珍藏分享. 因为我们都没有经验,感觉 Jitsi 做一对一,和多端的情况下会支持多一点,Jitsi 感觉会更适合快速开发些.感觉分享,这样在碰到任何场景会有更多应对方案,不像刚开始,想着从头开发.😊

[dnjat]

@wnpllrzodiac 不打算从头开发了,通过大佬们的推荐,又看到了希望,看能不能通过优秀开源框架,捣鼓出一个最小可用方案.实在不行,就只能买服务了.通过大家知道,很多大佬都研究过这方面,确实大多都是回答要处理点很多,没经验更别提了,自己研发周期太长,结果效果还未知.

[dnjat]

@abelmakihara 初生牛犊不怕虎,驰骋代码界多年,我们有迷之自信,誓做攻无不克的 coding boy,不踢到钢板绝不喊疼.现在知道他的历害了😂. 听了大佬们的经验之谈,不打算从 0 开发了.看到推荐的这么多优秀框架,自信好像又回来一点了.😊

[xsen]

livekit/openvidu/mediasoup

其实，最简单就是接入第三方，直接 sdk 接入；除非有私有云部署需求

[calvinHxx]

客户端、业务后台自己开发吧。 音视频服务采购第三方 SDK 吧。降噪、弱网、传输协议都是技术难点。传统 RTMP/RTSP 弱网不够用。

[newbeelity]

感觉要有架构师或者产品角色，理一份成本表，3 个研发按照资深程度，200 万/年。同样买产品 xx 万。自研优势可控、劣势周期长，效果一般

[dnjat]

@varxo livekit 粗略了解后,很适合我们.这个开源方案很优秀.谢谢推荐分享.🦀

[dnjat]

@xsen 我们现在也把接入三方 SDK 做为最优选择了,这个音视频不好惹,功力还不够. 先尝试简单的解决方案,接触多了,可能经验会有所积累,来日再杀一个回马枪.

[dnjat]

@calvinHxx 对于我们小白,借助三方库是我们能继续在这条路上走的唯一选择了(#8 楼已经把难点列出来了🤣). 目前我们也只能站在巨人的基础上做个二次开发,把整个流程打通下来.没有经验积累,那些难点确实只能绕过了.

[dnjat]

@newbeelity 嘿嘿,当时想得太简单了,本想着一个人开发核心库的,到时另外两个同事帮下忙,做个多端适配什么的.结果大佬们帮我们一分析这个产品的难点和开发周期.这成本一下就摆在那了,根本不适合.所以借助大家推荐的优秀开源项目,再折腾一把.

[lidedongsn]

第一步使用三方 商用解决方案 SDK ，先把业务跑起来，同时学习理论概念，并尝试用开源解决方案自行搭建，慢慢替换

[Censhuang]

在线教育吗？用过猿辅导，他们看起来是直接把课件下发到 ppt 里，笔记和荧光笔同步。发现用的课件是我能按住鼠标左键把图片拉下来放到别处。主讲老师漏个脸，网络不好就让把老师那个摄像头关了，听声音就行。

[mightybruce]

我觉得你们做不到这种需要专门音视频知识的开发，最简单的做法还是用别人的音视频会议服务器项目做二次开发，
这方面有 openmeetings,jitsi desktop, bigbluebutton.

openmeetins 是在 kurento 之上开发的，用到的音视频处理服务器比如 kurento, janus 也可以了解了解。

此外音视频最大的开支是 CDN 和 服务器带宽，这点你得多问问云厂商和不同的 ISP, 否则效果很差。

[lefer]

市面上有很成熟的产品了，而且本身就是非常复杂的产品。

话说，既然要用来 [在线教育] ，为啥要重新开发，而不是用市面上成熟的产品呢？

[mightybruce]

openmeetings 是最贴近在线教育的功能的，不过二次开发不太好弄。音视频的带宽和 CDN 是一定要花钱买的，除非你们做的是那种没几个人用的产品。

[mightybruce]

如果你们找第三方专门做音视频会议和直播视频流的厂商来通过 SDK 做二次开发,可以看看声网。
https://www.shengwang.cn/

[xz410236056]

@leonlx c# + MAUI ，从桌面到移动端一把梭

[mingtong]

做出 Hello world 容易，做出能稳定使用的产品很难，花的钱不会少。
专做视频会议软件的公司，做了 30 年，千八百号人。
你老板想几个人几个月就搞出来。

[newshbb]

所以才有声网

[haoz1w0w]

声网、zego 、腾讯云，成熟方案

[javalaw2010]

点对点不现实，商业产品这么做自己找死。
直接上大厂的 RTC 云服务，你们专心搞业务逻辑就好了，基础设施的东西交给专业的人去弄。

[bugu1986]

agora

[huihuilang]

技术上不是什么问题，问题是带宽和线路、现在国内跨网网络劣化的厉害，就需要你在每个城市就近部署服务器，走类似于 anycast 的传输，再一路走内网。国内那么多搞在线会议的公司，最后腾讯和阿里钉钉各霸占半壁江山，靠的就是海量的集群服务器啊

[Helsing]

@haoz1w0w
+1 ，用这几家最快，要不各种问题处理起来那叫一个头大

[lonccc]

推荐 livekit ，开源的，提供云服务也可以自己部署，这里就有一个 demo https://github.com/livekit-examples/meet

[shuax]

反正都用 flutter ，为啥桌面端不用

[capric]

https://github.com/jitsi
https://github.com/bigbluebutton
https://jami.net/
https://openmeetings.apache.org/
https://element.io/
基于 webrtc 启动开发，后面上 mesh/mcu/sfu ，而且你这个在线教育，学生端只要播放教师端视频就行了吧，做成直播会更简单

[xjh5572]

因为需求不明确

[Promtheus]

这样的老板太多了，想几个程序员找个开源的东西改改就能抵上别的公司多年做出来的产品。。

[Vindroid]

建议全部选用 Qt 来实现多平台，ui 用 qml 就能搞定。或者就拆分，各平台各做各的，移动端效能会好上一大截，但人力要求也很高

[mightybruce]

大家都在谈技术，我还忘了另外一点，那就是这种音视频服务如果是公开对外的是需要牌照的
首先是第一点，企业做在线教育业务的目的肯定是为了营利，会涉及到经营性的活动，所以 ICP 许可证是肯定要有的。第二类增值电信业务--信息服务业务 简称 ICP ，主要是用于有偿信息服务的.经营性网站必须办理 ICP 证，否则就属于非法经营。因此，办理 ICP 证是企业网站合法经营的刚需.

其次就是要看在线教育业务，是用何种方式开展的，不同的开展方式，所需要的证书也是不同的.

公司经过选择、编辑、加工自己或他人创作的作品,并在互联网上发布供公众浏览、阅读、使用或下载的在线沟通行为,应当申请《互联网出版许可证》;

如果公司独立制作在线教育课程,学生可以在线点播动画视频内容,该模式可能包含以计算机为接收终端,通过移动信息网络、广播(包括点播、广播)、集成、传输、下载视听节目服务等活动,应申请《广播电视节目制作许可证》。

在线教育属于互联网生产、传播和流通文化产品,还会涉及到在线一对一,或者一对多视频传输课程知识点,一般是直播为主。所以就需要办理《网络文化经营许可证》(网络表演)范围的“直播文网文许可证”。

综上所述，开展在线教育业务，根据业务的开展方式不同，所需要的证书也是不同的.

[andyskaura]

听你的场景，如果是一对多的，webrtc 用 SFU 的模式，不然先不提带宽，光性能都吃不消。
编码可以升级成 AV1 ，大不了让用户软解。流量太贵了。

RTMP/RTSP 的方案解决不了带宽的问题，反而还增加了延迟。

[Solace202]

上家公司就是做网络会议、电话会议的，我旁边就是一帮子搞底层的，光听着就觉得不好搞。

[andyli9449]

上面基于 webrtc 的方案 可以提醒一句，不定制优化的话在国内 P2P 成功率是不高的，大概率都需要服务器转发，转发就会带来服务器流量费用。 你们开发加上流量费用真的建议 用声网 sdk 这种成熟。 没有相关音视频背景，你们这个配置二次开发都可能有难度。

[JarlZhang]

控制欲在成本面前不值一提，先给你们老板算一笔账，看看他愿不愿投入吧，很多东西不是有技术就能堆起来。云服务，各种资源，都是要花钱的

[dnjat]

@lidedongsn 今天和老板聊了下,也是这么想的,先用商用 SDK 把业务打通了,看成本能否控制在现有的解决方案之下,再尝试开源方案, 和大佬你的想法不谋而和.这个流程也比较适合当前资源能力的局限.

[dnjat]

@Censhuang 是的,做在线教育行业. 猿辅导,这种方案好像更节省流量,不需要一直投屏转发.摄像头有些情况也是非必要的,看来成熟的方案已经把每个细节都做了优化.

[dnjat]

@mightybruce 哈哈,是的,做不了,音视频壁垒太高了,经过大佬们的建议和查阅资料,已经放弃自行研发了. 先用商用 SDK,后续看用开源方案,自行搭建服务器,能捣鼓出来一个不😂
openmeetins 看了下,和#49 楼提到的猿辅导很像.与其它方案不一样,这个更适合做教案,也似需不需要像投屏那么占用带宽.
如果自行搭建,带宽,CDN 后期是大头,到时成本综合一下,还得与商用解决方案便宜才行.

[dnjat]

@lefer 有在用成熟的产品,上面想把这个费用再降一降🤣. 如果自行弄,又得考虑成本,效果,稳定,所以先调研一下可行性,看自己能捣鼓成什么样.

[lefer]

@dnjat #77 好的。反正绝对不是一个简单的事情。想想看就觉得恐怖。。。

[dnjat]

@mingtong 上面也向周边搞这方面的了解过,所以现在想尝试先用商用 SDK,再自行搭建,不然真等不会看得见的那一天.
做产品就是这样,方方面面都得丝滑.打磨得圆润才行.

[dnjat]

@newshbb 老板想,我得降本,你能搞出来,我也想搞个低配版. 音视频确实很难,这玩意不简单. 这短视频直播方面,是不是大厂在这方面都有历害的庞大团队.

[dnjat]

@haoz1w0w 谢谢建议,老板说,找个物美价廉的 SDK 先开发下去.😅

[dnjat]

@haoz1w0w 当然物美价是建立在稳定好用才行.这三个应该都不错的.

[dnjat]

@javalaw2010 想着点对点不走服务器,成本低呀. 这个找死是监管问题吗?
是的,这个领域太难了,这笔成本很难降下去了.准备先上商用 SDK,再后面积累经验,用开源项目搭建下,看有没有可能.

[dnjat]

@bugu1986 谢谢,很多人都建议这个,肯定是不错的选择.

[dnjat]

@huihuilang 我们才开始了解,就已经觉得带宽的压力,和线路该怎么优化的问题了.技术和服务器部署都很重要,冷汗直冒.

[dnjat]

@Helsing 谢谢推荐,我一定会少走弯路,少踩坑的😂

[dnjat]

@lonccc 谢谢推荐,这个 livekit ,大佬们推荐得最多,查资料了解到无论 api 还多端支持,适合做二次开发.

[dnjat]

@shuax 我不知道 QT 对 andriod 和 ios 支持得好不好,所以大概看了下 flutter,多端统一确实会好一些

[dnjat]

@capric 是的,只要一对一,学生端播放教师端投屏就行了. 一对一,一对多都算直播吧. 我们要自己捣鼓也打算基于 webrtc 这种了(因为很多开源的都是基于这个),从 0 开发确实不现实.

[dnjat]

@xjh5572 就是做一个一对一的投屏(一方投屏,一方观看). 因为刚开始了解的是从 0 开发,看到的视频和资料用到的技术比较多,自己都理不清用哪种好,所以来这希望大佬们给点经验和指导一下.

[dnjat]

@Promtheus 主要自己也感点兴趣,没想到这个玩意门槛这么高.惊呆了.

[dnjat]

@Vindroid QT 在适配手机端(andriod,ios)下容易适配吗,之前只了解过桌面端.肯定能统一更好了.

[dnjat]

@mightybruce 这个我提醒下上面.现在是用的腾讯会议开个房间.

[dnjat]

@andyskaura 是一对一的场景(一方投屏,一方显示).双方语音交流.livekitr 看文档比较适合做一对一,但他也是基于 webrtc 的. 如果自己做二次开发,好像基于 webrtc 的方案会容易点.

[dnjat]

@Solace202 那肯定是完全自研了. 没想到这领域这么难.

[dnjat]

@andyli9449 P2P 订制优化牵扯到什么方面? 基本上都是公网进局域网,应该是没办法直接穿的. 谢谢建议,软件和服务器,线路都要搞定,确实成本摆在那.二次开发我们想着改一改看看效果怎么样,大多是适配到现有业务中,真正去修改实现模块,那还是没那个功力.

[dnjat]

@JarlZhang 老板就是想减少成本,今天和他聊到了成本,服务器,流量这些,他有点犹豫了.

[OneMan]

老板连方案能不能搞，底下人有没谱都不知道，牛

[simo]

要真是你们三个人，并且必须搞出来，感觉 2 年都费劲。
好好找找能二开的成品吧

[dnjat]

@OneMan 哈哈,老板只负责大方向.😅 我们也没弄过,想着推下流,拉下流,就算难,应该多吭一下,应该也能弄个七七八八吧.结果....