嵌入式音视频解决方案 Webrtc vs MetaRTC

前言

疫情后，音视频领域引来新的腾飞，视频会议，云桌面，云游戏等应用层出不穷。实时，高效，协同成了企业的代名词，没有这几点，感觉企业跟不上时代的步伐。

前几日，刷爆朋友圈的 “天空课堂”，神舟十三号乘组航天员翟志刚、王亚平、叶光富将在空间站进行太空授课，中国载人航天工程办公室联合教育部、科技部、中国科协、中央广播电视总台共同主办。中央广播电视总台将进行全程现场直播。

我们可以看到随着5G技术的成熟，人们对实时性，互动性提出了更高的要求。

大名鼎鼎的Webrtc

提到音视频，就不得不提谷歌的Webrtc，很多以前没接触过音视频领域的，随着企业的发展和客户的需求，也开始接触Webrtc技术，我们在这2年看到了很多新人，涌入了这个行业，这是一个好事，但是我们也看到了很多新人对谷歌Webrtc的抱怨。

1.编译难，下载难
2.第三方库众多
3.算法复杂
4.系统庞大，代码复杂，二次开发难度大
5.不适合嵌入式，嵌入式的算力有限，webrtc太重
6.文档少，遇到问题不知道怎么解决

虽然有以上的缺点，但谷歌Webrtc，依然是个优秀的开源项目

MetaRTC

MetaRTC是一个为嵌入式/物联网打造的RTC库，为第三代互联网元宇宙提供RTC能力。
MetaRTC实现了webrtc协议，支持webrtc/srt/rtmp，可与谷歌webrtc互联互通。

MetaRTC与Webrtc的区别

MetaRTC编译简单

webrtc编译难，需要科学上网，仓库几十个G。
而metartc在B站有完整的编译教程和视频

体积小

webrtc使用c++开发，体积大，不适合嵌入式。
metartc大多数使用c语言开发，天生适合嵌入式。

容易二次开发

webrtc是谷歌开发，代码量大，二次开发难度大。
meta代码量小，二次开发难度小，并且有完整的国人社区。

打造国人生态

webrtc是p2p的，没有服务端，而开源的服务端，五花八门，学习成本高，开发者经常纠结使用那个webrtc开源服务。metartc推荐使用srs 杨成立大佬开源的服务端（国人写的）,当然如果你有自己的流媒体服务器也支持对接。

更开放

metartc更本土化，拥有自主的开发权，需要的功能和建议都可以提issue，会根据开发者的建议来更新迭代metartc

提供全套解决方案

metartc 提供全套的解决方案，比如开发者想使用H265，而srs不支持265，我们就在srs上扩展了H265的支持,提供客户端到服务端的完整解决方案

7.更可控

近期Java log4j的安全漏洞，刷屏了整个互联网，log4j捅破了Java的大半片天，对于RTC这种底层应用来说，更需要一个自主可控的RTC库

MetaRTC的功能

视频编码 8bit:x264、x265、vaapi、nvenc等，二期增加AV1和多种硬件编码。
视频编码 10bit:x265、vaapi、nvenc等。
视频解码：ffmpeg和yangh264decoder。
VR:基于抠图实现虚拟视频的互动和录制、直播等。
8bit和10bit网络播放器：yangplayer
音频：Opus、Aac、Speex、Mp3等音频编解码。
音频：AEC、AGC、ANS及声音合成等处理。
传输：webrtc、rtmp、srt，webrtc为自己实现，没使用谷歌lib库。
直播：rtmp、srt、webrtc、HLS、HTTP-FLV。
8bit录制：h264、h265的mp4和flv。
10bit录制：h265的mp4
实现了屏幕共享与控制。
实现了声音和图像多种处理。
专业摄像头的云台控制与多镜头导播切换。
支持32位和64位编程。

MetaRTC的使用场景

MetaRTC可用于视频会议、高清录播直播、直播互动、云游戏、云3D等多种视音频应用。可用于远程教育、远程医疗、指挥调度、安防监控、影视录播、协同办公、直播互动等多种行业应用。

延时测试

一位热心的网友测试情况，端到端延迟时间为40ms。

总结

对于中国RTC来说，需要一个自主可控的RTC库，诚邀各位开发者体验MetaRTC，欢迎star和fork。