当前位置:Gxlcms > html代码 > 可以用WebRTC来做视频直播吗?

可以用WebRTC来做视频直播吗?

时间:2021-07-01 10:21:17 帮助过:41人阅读

经常看到WebRTC的点对点的视频, 能不能做一个平台,让别人通过WebRTC播放视频直播,让粉丝都可以看见? 有什么方案讲讲?

回复内容:

我所在的项目用这个技术两年多了,先说结论:完全可以!

但是,凡事总有但是,也没那么简单。你以为调用几个Chrome的API就能直播了?too simple

楼上 米小嘉 回答中的猜想是不正确的,WebRTC用的不是插件,是Chrome自带的功能,是原生js的API,也没有什么浏览器自带的插件。
楼上 煎饼果子社长 的方法也不对,WebRTC的API不仅仅是给你获取本地信源的,所谓RTC是real time communication的缩写,自然这套API是带传输功能的。所以获取图像信源之后不应该用websocket发送图像数据,而是直接用WebRTC的通信相关API发送图像和声音(这套API是同时支持图像和声音的)数据。

所以,正确的方法是什么呢?
1、你得有一个实现了WebRTC相关协议的客户端。比如Chrome浏览器。
2、架设一个类似MCU系统的服务器。(不知道MCU是什么?看这:MCU(视频会议系统中心控制设备)

第一步,用你的客户端,比如Chrome浏览器,通过WebRTC相关的媒体API获取图像及声音信源,再用WebRTC中的通信API将图像和声音数据发送到MCU服务器。
第二步,MCU服务器根据你的需求对图像和声音数据进行必要的处理,比如压缩、混音等。
第三步,需要看直播的用户,通过他们的Chrome浏览器,链接上你的MCU服务器,并收取服务器转发来的图像和声音流。

先说步骤一,如果你只是做着玩玩,完全可以直接用Chrome浏览器做你的直播客户端。把摄像头麦克风连上电脑之后,Chrome可以用相关的js的API获取到摄像头和麦克风的数据。缺点就是如果长时间直播,Chrome的稳定性堪忧,我不是吓唬你。我们项目的经验是,chrome这样运行24小时以上内存占用很厉害,而且容易崩溃。

第二步,你可能要问,WebRTC可以直接在浏览器之间P2P地传输流,为什么还要有中转的MCU服务器?因为Chrome的功能很弱,视频的分辨率控制、多路语音的混音都做不了,所以需要MCU参与。最重要的是,Chrome同时给6个客户端发视频流就很消耗资源了,所以你如果有超过10个用户收看的话,Chrome很容易崩溃。

第三步就比较简单了,没什么好说的。

最后最后,还是老话题,兼容性。你可以查一下现在支持的浏览器有款,IE据说支持,但是我们研究了一下好像他用的协议和Chrome不一样,不能互通。firefox和opera情况也不是很理想。

-------------------------2015年11月17日 更新--------------------------
韦易笑 的答案中说“10人以内使用,超过10人就挂了”。从我个人的经验来看,我认为WebRTC并没有那么不堪。我不知道他是用什么样的方案,但是我原来的那个项目,13年做的结果是 1人广播,39人收看,在一台i3 + 4G + Centos6.4 mini的机器上跑MCU,连续运行48小时没有出现问题。CPU的使用率大概在60%左右,内存使用率是多少我记不清了,但是印象中不高,而且比较稳定。能不能支持更多的客户端我们没有尝试,因为当时已经满足我们的需求了。 别迷信 WebRtc,WebRtc只适合小范围(8人以内)音视频会议,不适合做直播:

1. 视频部分:vpx的编码器太弱,专利原因不能用264,做的好的都要自己改264/265代码才行。
2. 音频部分:音频只适合人声编码,对音乐和其他非人声的效果很糟糕。
3. 网络部分:对国内各种奇葩网络适应性太低,网络糟糕点或者人多点就卡。
4. 信号处理:同时用过 GIPS和 WebRTC 进行对比,可以肯定目前开源的代码是GIPS阉割过的。
5. 使用规模:10人以内使用,超过10人就挂了,WebEx方案支持的人数都比 RTC 强。

正确的方法是啥呢?
------------------------- 分割线 -------------------------
让粉丝们来看直播,如果同时粉丝数>10人,那么不关 WebRtc 鸟事,服务器请使用 nginx rtmp-module架设,架设好了用 ffmpeg 命令行来测试播摄像头。主播客户端请使用rtmp进行推流给rtmp-module,粉丝请使用 rtmp / flv + http stream 进行观看,PC-web端的粉丝请使用 Flash NetStream来观看,移动 web端的粉丝请使用 hls / m3u8 来观看。

如果你试验成功要上线了,出现压力了,那么把nginx分层(接入层+交换层),稍微改两行代码,如果资金不足以全国部署服务器,那么把 nginx-rtmp-module 换为 cdn 的标准直播服务,也可以直接调过 nginx,一开始就用 cdn 的直播服务,比如网宿(斗鱼的直播服务提供商)。

这是正道,别走弯路了。
--- 我弄一个手机视频直播应用,刚刚上线,基于WebRTC技术,Mesh tree的网络架构,浏览器之间走P2P Relay, 正在产品迭代中。产品见: yacamera.com 谢 @郭小灿 邀…最近是有参与相关的事,然而也只是初接触。
Talk is cheap, show you some codes:
  • meetecho/janus-gateway · GitHub
  • WebRTC-Experiment/webrtc-broadcasting at master · muaz-khan/WebRTC-Experiment · GitHub, with demo: WebRTC Broadcasting - Muaz Khan
WebRTC 的初衷和优势是 Browser-to-Browser 的,它是 Web 端音视频实时通信。考虑到需要实现 live broadcast,所以 WebRTC 几乎不靠谱,顶多在 broadcaster 和 server 上实现协议栈。server 实现各种 management,比如 room server;如果不在 server 端转发,而是以 broadcaster 为中心进行多个 p2p 连接,那要实现 signaling server, ice server,供 browser 之间连接,而且一个 broadcaster client 能力有限所以支持不了太多连接(基本上是个位数);如果要在 server 端转发(几乎是必需),那要实现 stream server,接收 broadcaster 的 WebRTC 的 rtp 包,流媒体处理(考虑下 gstreamer ?),录制成文件或 rtmp 发送到各个 participants。大系统可以考虑用多台 stream server,cdn + p2p 结合,于是要再实现个 server 搜集和维护各个 peer 的网络信息进行分发调度……其他的 client 端问题无非是网络传输协议和音视频编解码问题,注意统一和兼容。Chrome 的 WebRTC 实现已经很完整,有人提到回声消除,这在 VoiceEngine 里有实现,是用的 NetEQ 算法,源自 GIPS,还有降噪、静音检测等功能。VoiceEngine 十分强大,我想剥出来自己使用(其实不是我想)。 可以的. webrtc就是浏览器直接有实时视频功能, 不需要额外的插件, 但有可能是浏览器的默认插件


----


楼上有人说
" 视频部分:vpx的编码器太弱,专利原因不能用264,做的好的都要自己改264/265代码才行。"
请参见Firefox默认携带的Cisco提供的H264插件, 专利方面是没啥问题的. 这个插件是一个开源项目, 想要改进其性能可以自己去github上面提改进. 呵呵。我来回答这个问题吧
1:视频主播、直播多采用本地软件采集视频和语音(试试OBS),然后RTMP传到服务端,服务端搭个RTMP服务器+web网站就可以实现直播了,再加个聊天室,就是典型的游戏、美女直播系统了。然后再把rtmp流传到CDN去,好!你可以支持到上千人了。但是注意:只能跟直播人文字聊。
2:webrtc是语音与视频的互动,可以互相语音和视频。但是让他做直播?显然不是一个系列的东西了。当然6-8人的视频直播啥的还是可以玩玩的。 可以实现功能,但是效果绝对让你抓瞎,不知道你的应用场景是什么,千万别进坑里去,见过公司都烧钱烧精力结果搞出一个四不像,最后苦苦挣扎资金断流...如果能详细讲一下应用场景,大家可以帮你分析一下的。
贴一个我刚刚写的答案的一部分,希望对你有帮助
--------------------------------------------------分开----------------------------------------------------------------
火热的游戏直播行业,为什么优酷土豆爱奇艺这样视频站没有抓住机会? - 张腾的回答
一,视频直播与视频点播
很多人凭着第一印象,觉得两个名词里面都有视频,就认为两者实现的方式和技术要点是一样的,众多视频点播网站巨头(题主所说的:优酷,土豆,新浪等)都在探索视频直播的道路上吃了大亏,也是因为对两者之间区别的认识不够深刻。

视频点播对于视频本身的要求是:高质量(高码率)和流畅(低卡顿,即加载时间)
视频直播对于视频本身的要求是:清晰,流畅,低延时(无互动,不直播,把延时控制在3秒以内,甚至1秒内意义重大,这一点很多直播平台还都没有认识到)。

注意到区别了?低延时,也就是实时性,差之毫厘谬以千里。
为什么低延时在传统视频点播平台运营商那里会遇到大麻烦,需要讲一下现在所有视频服务的骨架CDN的前世今生,请仔细阅读下面的文字:


随着Internet的迅速发展,用户数量和信息量快速增长,为了从技术上全面解决网络带宽小,用户访问量大,网点分布不均匀等问题,1998年诞生了解决问题的方案,即CDN(内容分发网络)。

CDN技术采用了分布式缓存/复制、负载均衡、流量工程和客户端重定向等技术,设立若干分支节点,尽量将用户请求的内容存储到距离用户“最后一公里”的边缘节点上,在Internet上构筑一个地理上分布的内容分送网络,将信息资源向网络边缘推近,用户可以在 “最近”的位置快速访问到所需的内容,继而提高了终端用户的访问速度和服务质量。


CDN整体框架的顶层设计是为了解决文件的分发和传输问题架设的,系统起初是服务于文件而非实时的流媒体数据。在处理流媒体数据时,现有方案仍沿用了传统的分发原则与模式,无法满足互动直播高质量低延时的要求。



读到这里,你仿佛知道了他们之间的差异。但是,如果你认为CDN是现在主要的技术瓶颈,那你就错了,CDN只是个基础,更纠结的还在下面

二,流媒体传输协议
传输层协议主要讲下面三种

1.TCP

TCP为点对点的协议,虽然能保证了数据传输的可靠性,但是对服务器资源耗费较大,在数据流大的场合难以保证数据流传输的实时性。

2.UDP

UDP为不可靠传输协议,不需要维护连接状态,也不认为每个数据包都必须到达接受端,因此网络负荷比TCP小,传输速度也要比TCP快;但在网络越拥挤时,越有更多的数据包丢失。

3.RTMP

RTMP一个专门为高效传输视频,音频和数据而设计的协议。它通过建立一个二进制TCP连接或者连接HTTP隧道实现实时的视频和声音传输。

现在传统的视频直播都使用的RTMP传输协议,因为不管是UDP还是TCP协议,都不适用于流媒体的实时传输。但是使用RTMP+CDN或云的方案也存在根本性的缺陷。因为不管事RTMP还是CDN, 都源自服务于文件传输的方案,问题主要有以下几个

a:现在做的最好的用RTMP来搭建视频直播方案,其延时也最多能达到5秒左右,实际上,如果要保证视频的流畅(低卡顿)和清晰(高码率),5秒的延时都很难达到,有的方案甚至在7-8秒,直播的很大一部分意义在与互动和实时性,互动对于延时的要求,最佳时间是在2-3内,再长就会体验很差(大家可以自己试一下),而对于很多行业,直播的要求甚至要在半秒以内才有意义,这是现有方案完全无法满足的。

b:对于客户资源的最大程度利用,这一点涉及公司的方案设计,不再详述,有兴趣的可以私信。

c:CDN节点完全属于盲点,直播流浪涌入,一旦某个节点出现波动,只能被动地让用户承担极差用户体验的风险(卡顿,模糊),而对于网络状况本身却处于黑箱状态,不可管,不可控,受制约严重。我相信这一点有相关运维经验的知友都深有感触。

d.e.f....太多字了不写了


我想上面的答案应该能让题主明白,为什么优酷这种巨头做不好“一点微薄的工作“

简而言之

1.运营能力不能代表技术开发水平

2.流媒体实时传输这块领域太窄,不要说优酷,全世界真正深入研究的公司或团体,据我所知,除了我们公司还有一家美国的公司在做,不过他们和我们做的方向还是不一样,这是后话了。

3.互联网节奏太快,很多巨头的想法是,加大投入,缩短研发周期,立竿见影地把流媒体直播这个坑填平,但他们没有想到的是,一个坑后面还有无数个坑,坑里面还有坑,甚至方向可能都错了,赶时间赶进度的初衷反而被这种浮躁的心态给牺牲了。

可以的,http://www.anyrtc.io可以去了解一下,有成熟的视频直播方案,而且可以实现互动直播 天翼rtc就提供这种能力,可以音频聊天,视频会议,对讲,和微直播。 完全可以的,现在已经有很多成熟的范例了,包括行业内的一些SDK也有用到WebRTC中的模块

人气教程排行