嵌入式音视频解决方案 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的区别

  1. MetaRTC编译简单
  • webrtc编译难,需要*,仓库几十个G。
    而metartc在B站有完整的编译教程和视频
  1. 体积小
  • webrtc使用c++开发,体积大,不适合嵌入式。
    metartc大多数使用c语言开发,天生适合嵌入式。
  1. 容易二次开发
  • webrtc是谷歌开发,代码量大,二次开发难度大。
    meta代码量小,二次开发难度小,并且有完整的国人社区。
  1. 打造国人生态
  • webrtc是p2p的,没有服务端,而开源的服务端,五花八门,学习成本高,开发者经常纠结使用那个webrtc开源服务。metartc推荐使用srs 杨成立大佬开源的服务端(国人写的),当然如果你有自己的流媒体服务器也支持对接。
  1. 更开放
  • metartc更本土化,拥有自主的开发权,需要的功能和建议都可以提issue,会根据开发者的建议来更新迭代metartc
  1. 提供全套解决方案
  • 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。
嵌入式音视频解决方案 Webrtc vs MetaRTC

总结

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

上一篇:VS指定多个dll库目录


下一篇:MySQL - 可重复读 vs 读提交