上头交给年后任务，开发一款用来在线教育的音视频软件，先让我先研究一下，然后规划下流程方案和技术选型，主导这个软件的开发（我会 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)。每个端都支持教师与学生。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其他的同类产品

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

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

---

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

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

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

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

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

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

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

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

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

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

livekit

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

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

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

livekit/openvidu/mediasoup

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

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

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

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

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

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

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

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

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