SRS:webrtc_to_rtmp详解前言SRS(Simple Realtime Server),自我开始做音视频行业开始,就有人力推给我的一个开源库,虽然我到现在还是音频领域的入门出徘徊,但也积攒了一些对 简介srsSRS是一个开源的(MIT协议)简单高效的实时视频服务器,支持RTMP、WebRTC、HLS、HTTP-FLV、SRT、MPEG-DASH和GB28181等协议。 SRS支持互联网广泛应用的音视频协议转换,比如可以将RTMP或SRT, 转成HLS或HTTP-FLV或WebRTC等协议官网地址:SRSSRS关于rtc-to-rtmp:srs:rtc_to_rtmpsrs 关于直播以及协议转换,主要还是设计媒体传输层,webrtc协议媒体传输层使用rtp(Real-time Transport Protocol)。 git地址:webrtcsrs关于rtmp:srs:webrtcwebrtc传输协议:WebRTC学习 实时数据传输网络协议详解(浏览器协议栈、WebRTC传输协议分析)RTP协议介绍:rtprtmpRTMP
WebRTC: 对比 对比RTMP,WebRTC有以下几个优势:其一,它是一种新型、由IETF和W3C进行标准化的开源技术。 WebRTC在推流时替换RTMP RTMP仍然是第一英里视频贡献的标准,这其中有以下几个原因。第一,RTMP获得了来自直播编码软件和硬件的广泛支持,同时许多社交媒体平台也在使用它。 如图中所示,当以这种方式传输视频时,WebRTC可用于广泛的工作流程中,包括WebRTC端到端,或者从RTMP到WebRTC。 更重要的是,使用次秒级流媒体传输的应用场景还可以利用RTMP到WebRTC的工作流程。 规模化的挑战:导致WebRTC在向成千上万(或更多)观众直播时很难使用。 幸运的是,行业已经为以上问题找到了解决方法,使WebRTC成为了RTMP的强大替代方案(无论是在推流时还是在播放端)。
背景好多开发者,希望对WebRTC、RTSP、RTMP、SRT有个初步的了解,知道什么场景该做怎样的方案选择,本文就四者区别做个大概的介绍。 WebRTC、RTSP、RTMP比较协议特点适用场景WebRTC基于浏览器、点对点通信、低延迟、安全性高、广泛支持视频会议、在线教育、实时客户支持、实时协作工具、远程医疗RTSP控制协议、不直接传输数据 以大牛直播SDK的模块为例,Android平台分别为启动了轻量级RTSP服务,和RTMP推流,Windows分别播放RTSP和RTMP流,无论是RTMP还是RTSP的,延迟均在100-150ms。 写到这里,回答下好多开发者的疑惑,为什么WebRTC和SRT这么好,大牛直播SDK只做了跨平台的RTMP推送、RTMP播放、轻量级RTSP服务和GB28181设备接入? 是的,WebRTC和SRT也都有适用的场景,WebRTC已经非常成熟,SRT实际上我们之前也有做过,只是没有对外发布,以目前我们的经历,能把RTMP推送、RTMP播放、RTSP播放、RTSP转RTMP推送
省流版先说结论直播领域,RTMP和WebRTC各有优势。如果直播场景对延迟有一定要求,但更注重稳定性和兼容性,那么RTMP可能是一个更好的选择。 再说二者异同点RTMP(Real-Time Messaging Protocol)和WebRTC(Web Real-Time Communication)都是用于实时音视频传输的技术,但它们各有特点,适合的应用场景也略有不同 直播领域,选择RTMP还是WebRTC,主要取决于具体的需求和场景。RTMP的特点及适合场景低延迟但相对稳定:RTMP基于TCP协议,具有较高的可靠性,能够保证数据的完整性和稳定性。 WebRTC的特点及适合场景更低延迟:WebRTC采用UDP协议,能够实现更低的延迟,通常可以控制在几百毫秒以内,非常适合实时互动场景,如视频会议、直播互动等。 因此,在选择RTMP还是WebRTC时,还需要结合当前的技术趋势和具体需求进行综合考虑。
经过半年的开发和测试,我们最先在EasyGBS上完成了webrtc协议的播放,随后又研究了EasyDSS的webrtc协议播放的实现方式。 EasyDSS 项目与其他项目略有不同,需要实现 RTMP 转 WebRTC 播放功能,因此编写文章记录了 WebRTC 最简化的流程。 由于WebRTC 是点对点通信技术,因此如果需要实现 WebRTC 播放功能,则需要在服务器端实现一个 WebRTC 客户端,在服务端的 WebRTC 客户端仅用于发送数据,而不接收数据播放即可。 收集到这些信息后,就按照 WebRTC 的标准编码流程,就可以实现双方的视频信息查看。最终实现 WebRTC 播放。
好多开发者可能会疑惑,走RTMP怎么可能低延迟?网上看到的RTMP推拉流延迟,总归要2-3秒起,如果是自己实现框架,RTMP推拉流逻辑自己实现的话,延迟确实可以控制在毫秒级,这个已无需赘述。 随着无纸化会议、智慧教室、智能化硬件产品的普及,RTMP的技术方案发展一度非常好,有些无人机或智能机器人,都可以自带推送RTMP流数据,配合大牛直播SDK的RTMP低延迟播放器模块,可以实现毫秒级的技术体验 智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等场景等,目前选择GB28181的更多一些,如果主要是上云或者无纸化同屏、智慧教室等,还是 RTMP推送多一些。 大家比较担心延迟问题,如果GB28181平台侧走RTMP或者webrtc的话,延迟也不大,和RTMP方案一样,整体都可以做到毫秒级。
上面的方案适合直播的基本都是RTMP和WebRTC两个中选择。 但是 延迟上WebRTC优于RTMP,WebRTC可以做到延迟低于1秒,RTMP一般在1秒以上 基本都在2到10秒之间 完善程度RTMP优于WebRTC 我们对低延迟直播技术的未来展望有三点: 厂商的选择 即构科技(RTMP) 当初也考虑过使用WebRTC来做视频直播,但是后来经过调研后放弃转而使用RTMP来做视频直播。 原因是在国内有60%的浏览器不支持WebRTC,而且主推WebRTC的Google Chrome在国内的效果也大打折扣。RTMP其实也不是最优的选择,但是我们最终还是选择了RTMP,为什么呢? 因为RTMP是标准协议,能被众多CDN网络支持,能兼容客户的老系统。尽管RTMP比较难做到比较低的延迟,但是经过我们不断的死磕,还是创造了奇迹,在主播端做到400毫秒延迟,观众端1秒左右的延迟。
上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://zhuanlan.zhihu.com/p/47302561), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施 目前国内低延迟直播的做法是在rtmp的基础调优, 比如使用可靠UDP方案替换RTMP的传输层, 目前使比较多的方案有KCP和QUIC. 但魔改RTMP的方案始终没有特别好的适配浏览器的方法. 相比有超过40亿设备支持的WebRTC来说, WebRTC的方案无疑更有想象空间. 但WebRTC天生为Peer-To-Peer而生, 并没有提供对大规模分发的支持. 全链路的WebRTC直播跟我上篇文章写的RTMP-WebRTC的方案类似, 有其中几个点需要注意一下: 0, 在源站接入点, 使用WebRTC接入, 这样我们可以省去RTMP到WebRTC协议转封装时间 这部分的原理跟我们在RTMP直播中缓存一个GOP原理一样. 最简单的一个架构如下: ?
其实我们可以在现有的RTMP-CDN系统上做一些优化调整, 在边缘节点把RTMP流转化为WebRTC可以播放的流来达到低延迟和CDN系统的复用, 同时还可以利用WebRTC抗丢包来优化最后一公里的观看体验 需要注意的问题 当然事情不可能那么完美, 让RTMP和WebRTC可以很好的互通也需要做一些额外的工作: 1, RTMP推流端低延迟以及GOP大小 如果想做到低延迟, 我们需要在推流端尽可能的快, , WebRTC也支持pcma和pcmu, 如果RTMP推流端推送的音视是pcma或者pcmu格式, 我们就不用转码了. 如何落地 目前身边完全没有完全匹配的需求, 这个方案目前并没有落地, 设想中的落地方式是, RTMP部分还是用现有的CDN, 自己部署WebRTC的边缘节点, 根据访问请求向CDN拉流. 完整的代码在这里 notedit/rtmp-to-webrtcgithub.com 我部署了一个测试版本网址在这里:https://rtmp-to-webrtc.dot.cc
背景在比较同一个数据源,是RTMP播放延迟低还是RTSP延迟低之前,我们先看看RTMP和RTSP的区别,我们知道,RTMP(Real-Time Messaging Protocol)和RTSP(Real 传输方式RTMP:RTMP通常使用TCP连接来传输数据。RTMP的传输是单向的,信息主要从服务器端传输到客户端。 应用范围RTMP:RTMP因其低延迟和高效传输的特点,广泛应用于需要高性能实时流媒体传输的场景,如直播、视频聊天等。 安全性RTMP:RTMP提供了相对较低的安全性,因为它主要依赖于TCP协议进行传输,容易受到中间人攻击等安全威胁。然而,通过加密和认证等措施,可以在一定程度上提高RTMP传输的安全性。 其他特点RTMP:RTMP还支持音视频同步传输、优先级设置等功能,以确保播放时的音视频同步性和在带宽受限时合理分配传输资源。
来源 | 掘金 作者:Nirvana-cn 排版 | 前端时空 WebRTC (Web Real-Time Communications) WebRTC 是一项「实时通讯技术」,它允许网络应用或者站点 WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下,创建点对点(Peer-to-Peer)的数据分享和电话会议成为可能。 本篇文章从自身实践出发,结合相关代码,总结WebRTC实现的基本流程。 1. 引言 首先我们先看《WebRTC权威指南》上给出的流程图,从这张图,我们要明确两件事: ? WebRTC实现流程 以下代码不能直接运行,因为我这里并没有实现「信令服务器」,如何实现信令服务器可自由选择(比如,socket.io、websocket等)。 maxRetransmits:设置消息发送失败时,最多重发次数 protocol:设置强制使用其他子协议,但当用户代理不支持该协议时会报错 negotiated:设置开发人员是否有责任在两边创建数据通道,还是浏览器自动完成这个步骤
RTMP转RTC流 直播推流场景一般是RTMP,事实上的标准协议,因为各种系统之间对接都会支持RTMP协议,所以虽然RTMP很老吐槽很多,但是还是比较方便对接的协议,总不能为了技术上看起来不优美,就把所有系统都改造一遍的吧 ,我们提到可以用WebRTC播放器做直播,SRS将RTMP流转成WebRTC流,提供给客户端。 RTC转RTMP流 WebRTC推流,RTMP播放,是非常重要的功能,每次SRS直播都会有很多朋友问这个功能的进展。 如下图所示: WebRTC推流,RTMP播放的功能,打通了RTC到直播这条链路,效果请看下图,配置请参考: https://github.com/ossrs/srs/wiki/v4_CN_WebRTC #rtc-to-rtmp WebRTC推流,转RTMP播放,还有哪些应用场景?
众所周知,iOS系统支持HLS流,但是HLS流延时高,无法满足实时流的要求;而WebRTC播放延时低,因此,很多用户希望能在iOS系统上播放Webrtc视频流。 RTMP流媒体服务器LiteCVR视频监控平台基于云边端一体化架构,具有强大的数据接入、处理及分发能力,平台支持海量视频汇聚管理,支持分发多类型的视频流,包括RTSP、RTMP、HTTP-FLV、WS-FLV 、HLS、Webrtc等,能覆盖多终端、多平台。 用户可以在iOS系统集成我们的播放器,就能实现LiteCVR平台分发的Webrtc流在iOS系统播放。 但是需要注意以下两点:1)平台分发的webrtc流为非按需直播模式;2)在iOS系统上集成LitePlayer.js播放器。
”,“该选HTTP-FLV还是WebRTC”,“用什么播放器播HTTP-FLV”。 用HTTP-FLV还是HLS? 答案是: 看你的业务的延迟要求,2-5秒用HTTP-FLV,5-10秒用HLS。如果是替代RTMP,一般来说要用HTTP-FLV,因为RTMP延迟也是3秒左右。 用HTTP-FLV还是WebRTC? 答案是:HTTP-FLV。 WebRTC是做通信的,不是用来做直播。 移动端微信小程序,用RTMP,HTTP-FLV或HLS。 移动端Native,用RTMP或HTTP-FLV。 而且SRS还能将RTMP转成WebRTC,是居家必备的不二之选。 用什么播放器?
N(>=3)年前Adobe官宣了2020年底就不支持Flash了,最近发现非常多的朋友,到了真正完全不能用时,才考虑如何逃生,一顿狂问“没有Flash了怎么播放RTMP”,“该选HTTP-FLV还是WebRTC 用HTTP-FLV还是HLS? 答案是: 看你的业务的延迟要求,2-5秒用HTTP-FLV,5-10秒用HLS。 如果是替代RTMP,一般来说要用HTTP-FLV,因为RTMP延迟也是3秒左右。 看业务对平台的要求,跨平台要求很强就用HLS,比如要在PC和移动端浏览器中都能播放那就要选HLS了。 用HTTP-FLV还是WebRTC? 答案是:HTTP-FLV。 WebRTC是做通信的,不是用来做直播。 移动端微信小程序,用RTMP,或HLS。 移动端Native,用RTMP或HTTP-FLV。 用什么播放器?
虽然项目已经停止更新很多年,但是Star还是在平稳增长,所以这是做开源不能过分在乎Star的原因,躺平也能涨Star。 老语言也一样,比如C看不惯C++的浮躁所以要搞个,C++看不惯C的低效得搞个,C++11看不起C++98还是得再来一个,C++20出来肯定还得有RTMP server被创造出来。 •srs[9], SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV 简单高效,直播和WebRTC互联网场景。•janus-gateway[10], Janus WebRTC Server. 做会议(WebRTC)的服务器。 •从业务上看,互联网音视频正在跨越行业,实现业务价值的同学不关注直播还是RTC,小孩子才做选择,成年人我都要。
什么是WebRTC webrtc 是为浏览器之间提供实时数据传输(Web Real-Time Communication)的javascript API 支持 peer-to-peer 音频、视频、数据流传输能力 信令(signaling) 信令是WebRTC用来协助建立p2p通讯的。主要用于协商双方通讯过程,传递基本信息SDP(会话描述协议)。 include_text=1 SDP握手 下图为WebRTC通过信令建立一个SDP握手的过程。只有通过SDP握手,双方才知道对方的信息,这是建立p2p通道的基础。 ?
理论上webrtc可以通过损失程度和乱序情况相关的反馈,自适应选择kFecMaskRandom还是kFecMaskBursty,效果比较好。 但是可惜的是,webrtc这块功能缺失,默认使用随机丢包模型。 1、1D行异或 2、1D列异或 3、2D行列异或 这块还是草案,如何选择异或模式的代码看没深入下去。后续补充。 需要注意,开启FlexFEC需要同时使能 WebRTC-FlexFEC-03/Enabled && WebRTC-FlexFEC-03-Advertised/Enabled 否则会出现死机异常 五、FEC 六、webrtc代码分析 1)使能FEC webrtc默认使能Red+Ulp的FEC。Flex仅在实验阶段,还不能正式使用。
• 有一定的软件开发基础,虽然设计了比较简单的入门场景,还是有部分场景需要移动端开发能力,以及Linux服务器的操作能力。 直播开源方案,推流工具还是用OBS[5],使用方法也是一样的。但是我们需要自己部署服务器,也需要选择直播观看的客户端: • 推流工具:OBS,vMix,芯象,腾讯会议等。 • 服务器混流:连麦的平台将连麦的流混流后转直播流,或者将WebRTC流转RTMP流后混流。 FFmpeg ---RTMP--> 直播 StreamB ----WebRTC-----> SRS ----RTMP---+ 从技术方案上看,完全可以直接混合RTC的流,这就是一般说的MCU模式(SRS -RTMP--> 直播 StreamB ----WebRTC-----> SRS ----RTC---+ 这种方案去掉了RTMP的中间过程,效率更高,而且也可以利用RTC的拥塞算法等优势,实现SFU和
LiveVideoStack:关于小程序中的RTC能力,是通过WebRTC实现的(或其他RTC技术),还是基于RTMP呢? 常青:小程序的RTC能力是基于RTMP技术实现的,没有使用WebRTC是出于两方面的考虑:一是微信安装包(尤其是iOS版本)的体积增量必须要控制在可接受的范围内,这是一个硬性的要求。 同时,小程序的定位更加专注于能力实现,在体验和二次加载速度上,相比于H5还是有一定的优势。当然,相比于定制性和迭代速度,体验上的优势仅仅是一个小细节了。 LiveVideoStack:iOS 11可以支持WebRTC,相信iOS上的微信支持WebRTC也可期。许多开发者看好WebRTC可以打通iOS、Android和PC浏览器。 常青:这里第三方的相关服务要看是云服务还是终端服务了。如果是云服务,那是完全没有问题的,支持RTMP协议都可以(接入),比如连麦、CDN等都无限制。