背景好多开发者,希望对WebRTC、RTSP、RTMP、SRT有个初步的了解,知道什么场景该做怎样的方案选择,本文就四者区别做个大概的介绍。 WebRTC、RTSP、RTMP比较协议特点适用场景WebRTC基于浏览器、点对点通信、低延迟、安全性高、广泛支持视频会议、在线教育、实时客户支持、实时协作工具、远程医疗RTSP控制协议、不直接传输数据 实时通讯RTMP协议因其良好的实时性和可靠性,也被广泛应用于实时通讯领域。在视频会议、在线客服以及社交软件中,RTMP协议可以作为视频和音频数据的传输协议,保证实时通讯的稳定和流畅。4. 写到这里,回答下好多开发者的疑惑,为什么WebRTC和SRT这么好,大牛直播SDK只做了跨平台的RTMP推送、RTMP播放、轻量级RTSP服务和GB28181设备接入? 是的,WebRTC和SRT也都有适用的场景,WebRTC已经非常成熟,SRT实际上我们之前也有做过,只是没有对外发布,以目前我们的经历,能把RTMP推送、RTMP播放、RTSP播放、RTSP转RTMP推送
HTTP将数据作为文件处理,所以HTTP不是流媒体协议,RTMP和RTSP是流媒体协议。 RTMP是Adobe的私有协议,未完全公开,RTSP和HTTP是共有协议。 RTMP一般传输flv,f4v格式流,RTSP传输ts,MP4格式流,HTTP没有特定的流。 RTSP一般需要2-3个通道,数据和命令通道分开,RTMP和HTTP在一个通道上传输命令和数据。 RTSP+RTP主要用于IPTV或低延迟场景,比如监控摄像头,传输数据使用的是UDP或TCP,在网络环境比较稳定的情况下,传输效率是比较高的; RTMP主要用于互联网音视频传输,它使用的是TCP传输, 因为互联网环境相对较差,采用RTMP保证了视频的传输质量,但是其传输延迟相对较高,传输效率相对较低。 HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。
有时需要rtsp、rtmp测试地址时,网上搜出来的都是千篇一律的已停用的测试地址,因此在这里维护一个播放列表,随缘更新(发现新的地址可以在评论区留言) 【last update】2022 /vod/mp4://BigBuckBunny_175k.mov (已停用) rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov (已停用) rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4 (可用) 可自行使用live555搭建rtsp服务器 [rtmp] 1、湖南卫视 rtmp://58.200.131.2:1935/livetv/hunantv (已停用) 2、广西卫视 rtmp://58.200.131.2:1935/livetv/gxtv (已停用) 3、广东卫视 rtmp://58.200.131.2:1935/livetv/gdtv (已停用) 4、东方卫视 rtmp://58.200.131.2:1935/livetv/dftv
大牛直播SDK(Github)多路RTMP/RTSP转RTMP转发软件,系原有转发SDK基础上,官方推出的Windows平台定制版。 如监控类摄像机、NVR等,通过厂商说明或Onvif工具,获取拉流的RTSP地址,图形化配置,完成拉流转发等操作,轻松实现标准RTMP服务器(或CDN)对接。 视频转发支持H.264、H.265(需要RTMP服务器或CDN支持扩展H.265),音频支持配置PCMA/PCMU转AAC后转发,并支持只转发/录制视频或音频,RTSP拉流端支持鉴权和TCP/UDP模式设置和 image] 添加转发项配置信息 [image] 配置说明: 添加配置项:点击页面“添加”按钮: ² 序号:无需关注,系统自动生成; ² 名称:该路转发配置项的描述信息; ² 拉流地址(必须填):需要转发的RTSP 或RTMP地址; ² 推流RTMP地址:需要转推的RTMP地址; ² 推流播放地址:需要预览的播放地址; ² 音视频转发选项:可选择之转发音频或视频,亦或同时转发音视频; ² 录像参数配置:可选择录制音频或视频
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
4. RTSP / RTMP / HTTP-FLV / WS-FLV 的技术本质在理解 WHIP/WHEP 的定位后,我们来看看传统协议真正解决了什么。 RTSP/RTMP/FLV 都比 WebRTC 简单得多。 替代 大牛直播SDK在 RTMP 场景的能力 RTMP 推流(支持 H264/H265 + AAC/PCMA/PCM) RTMP 播放(支持断线重连、弱网优化) RTMP → FLV 本地录制(MP4 全文总结本文从协议定位、媒体链路特性、生态适配性、系统复杂度、成本模型、行业需求等多维度全面分析了:WHIP/WHEP vs RTSP / RTMP / HTTP-FLV / WS-FLV的本质区别。 ✔ 4.
RTSP与RTMP区别 RTSP(Real-Time Streaming Protocol)和RTMP(Real-Time Messaging Protocol)是用于实时流媒体传输的两种协议。 它们有以下区别: 传输层协议:RTSP是基于UDP或者TCP的应用层协议,而RTMP是基于TCP的应用层协议。 为什么直播都使用RTMP协议推流,而不用RTSP或者webrtc 直播行业选择使用RTMP协议推流的原因有几个: RTMP协议具有较低的延迟。 相比之下,WebRTC和RTSP协议在直播行业的推流使用上存在一些限制: WebRTC协议在推流方面的应用相对较新。 虽然WebRTC协议具有实时性较好和延迟较低的优点,但是在直播行业的应用相对较新,目前还存在一些兼容性和稳定性的问题。
RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议,以前的项目里实现了一个RTSP协议转换RTMP直播协议的程序,为的是可以接收远端设备或服务器的多路RTSP直播数据, 要点分析 首先,程序的主要目的,是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据,并生成RTMP数据包,然后组装RTMP推送协议,并发往RTMP服务器。 因此,本程序的关键点有以下部分: RTSP直播流的读取 H.264和AAC编码数据的分析、处理 FLV文件数据的提取及与RTSP直接的切换和衔接 RTMP数据包封装 RTMP推送协议 有了关键点,就可以一项一项的去分析 第4和第5点,可以参照我之前的文章“RTMP协议发送H.264编码及AAC编码的音视频,实现摄像头直播”的技术方法,来加以实现。 还有一个关键点,就是要在自己的线程循环中,调用live555 environment的事件循环,就像这样 [hgaixa1rvw.jpeg] 4.
图片众所周知,国标GB28181视频平台LiteCVR平支持多种视频流媒体协议输出,如:HLS、HTTP-FLV、WebSocket-FLV、WebRTC、RTSP、RTMP。 2)WebRTCWebRTC地址一般以webrtc://开头。WebRTC是一种点对点的视频/语音通话协议,基于UDP建立通信后,不断以流的形式发送数据,固延迟小,适合交互性较高的场景。 3)RTSPRTSP地址一般以rtsp://开头,一般用作摄像机等硬件设备的实时视频流拉取和推送。4)RTMPRTMP地址一般以rtmp://开头,既可以推流,也可以拉流,一般用于直播推流。 WebSocket-FLV和HTTP-FLV类似,区别就是HTTP-FLV基于HTTP ,只能单向传输数据,而WS-FLV基于WS可以双向传输数据。 图片国标GB28181视频平台LiteCVR可支持多协议方式接入,包括主流标准协议GB28181、RTSP/Onvif、RTMP等,以及厂家私有协议与SDK接入,包括海康Ehome、海大宇等设备的SDK
这种将RTSP/RTMP/FLV等直播协议、摄像头数据,转为WebRTC方式,有以下优势:1、良好的兼容性:目前主流的浏览器均支持WebRTC,因此该方案无需担心浏览器兼容性问题,用户可以选择自己习惯的浏览器使用 4、前端引入方便、代码量小:前端不再需要复杂的播放器解码等方式,只需要用标准的WebRTC就可以接入。 以上解决方案工作量主要在后端,拉取RTSP、RTMP等数据,中转为WebRTC协议,不过已有成熟技术可使用。 点量团队作为专业视频流公司,有成熟技术可实现:传入RTSP/RTMP等地址直接生成WebRTC使用,并提供完善的前端示例,后台的部署安装也比较便捷,有专门的技术服务,无需从头研究。 具体架构图如下:以上系统平台具体功能有:1、支持多协议、多设备接入:支持RTMP/RTSP/Onvif/GB/T28181/等协议,多厂商品牌的设备接入 2、标准化输出,多终端全平台覆盖: 输出标准的WebRTC
2、vp8 vp9编码器用过没 都有什么特性 还有一些关于webrtc的问题: webrtc 的nack策略是怎么实现的? webrtc 的nack 请求丢失的帧 请求帧的rtcp包的格式是什么样的 webrtc 的fec 策略跟nack策略 同时开会如何? mp4封装 AAC(Advance Audio Coding)封装 有哪些规格 ADTS帧头包含哪些字段和含义 WAV Waveform Audio File Format WAV格式以什么开头 WAV HLS点播和直播的区别? m3u8有哪些字段和含义? 音视频同步的做法 音视频同步的做法 声音或者视频慢的解决办法 什么是RTT,RTT有什么作用? rtsp包含哪些方法,rtsp的流程 rtmp是可靠的传输协议吗? rtmp一般采用那种封装格式? rtmp的握手流程 udp如何做到稳定传输,说出你 的思路? http与tcp的区别?
在一些特殊应用场景中,可能希望把摄像头或者其他推流视频加入到FreeSWITCH中,我这里提供2个示例供大家借鉴 <action applicaiton=”playback” data=”vlc://rtsp ://xxxx/vod”> 安装 mod_vlc load mod_vlc (安装这个看前面文章介绍) image.png originate vlc/rtsp://192.168.1.100:8554 /vlc &conference(3000) image.png FreeSwitch1.6.18,ESL命令从会议室里呼叫Rtmp电话端 进入会议 (命令格式如: bgapi expand originate ${rtmp_contact(default/1015@192.168.2.32)} &conference(3502@video-mcu-stereo), rtmp电话端主动呼叫会议室号码进入会议可以看到会议视频
众所周知,TSINGSEE青犀视频汇聚平台EasyCVR可支持多协议方式接入,包括主流标准协议GB28181、RTSP/Onvif、RTMP等,以及厂家私有协议与SDK接入,包括海康Ehome、海大宇等设备的 视频监控汇聚平台EasyCVR平支持多种视频流媒体协议输出,如:HLS、HTTP-FLV、WebSocket-FLV、WebRTC、RTSP、RTMP。 2)WebRTCWebRTC地址一般以webrtc://开头。WebRTC是一种点对点的视频/语音通话协议,基于UDP建立通信后,不断以流的形式发送数据,固延迟小,适合交互性较高的场景。 3)RTSPRTSP地址一般以rtsp://开头,一般用作摄像机等硬件设备的实时视频流拉取和推送。4)RTMPRTMP地址一般以rtmp://开头,既可以推流,也可以拉流,一般用于直播推流。 WebSocket-FLV和HTTP-FLV类似,区别就是HTTP-FLV基于HTTP ,只能单向传输数据,而WS-FLV基于WS可以双向传输数据。
/WebRTC/RTSP。 AES CM)这意味着: WebRTC 不允许明文传输媒体 连接建立时必须完成密钥交换 加密不可被关闭(浏览器级强制) 这一点与 RTMP/RTSP/FLV 完全不同。 11.3 大牛SDK当前录制能力(MP4/FLV)完全统一FLV 录制: 适用于 RTMP/HTTP-FLV/WS-FLV 推流 支持 H.264/H.265 + AAC/PCMA MP4 录制: 适用于 RTSP / GB28181 / RTMP 支持严格的 PTS/DTS 构建 支持 H.264/H.265 + AAC 跨协议统一录制带来的优势:✔ RTSP → FLV ✔ RTMP → MP4 趋势 4:HTTP-FLV / WS-FLV 继续成为轻量级服务的黄金组合WebRTC 虽强,但对 Web 与服务端的成本极高。
像是对于流媒体协议的选择,如HTTP-FLV、WebRTC,RTMP,HLS及其它私有协议等,到底哪个比较合适?哪种协议可以用在PC平台上?哪种协议在移动设备上效果比较好? WebRTC:基于Google开源技术,在Web端上实现流媒体的协议。 优点:RTMP和HLS都是掌握在大企业手中的协议,而WebRTC已被纳入W3C标准;无需安装插件,支持的浏览器越来越多。 综合以上的优缺点比较,首先从各自的平台适配性上,且实现效果差不多的情况下,RTMP、HLS要比HTTP-FLV和WebRTC更优秀。 另外补充一点,之前文中没有提到RTSP协议,此协议和RTMP效果差不多,在技术上只是区别于传输数据上占用多少通道、传输格式流不太一样而已,RTSP其实也可以用于直播。 但依然是因为市场环境,RTSP目前主要应用在安防监控上,和RTMP一样,早已形成了自己的盈利链。以上就是在直播软件开发过程中,对于流媒体协议选择的讨论结果。
LiveGBS如何获取接入的海康大华宇视华为摄像头硬件NVR设备通道视频直播流地址HLS/HTTP-FLV/WS-FLV/WebRTC/RTMP/RTSP等视频流集成1、背景LiveGBS国标GB/T28181 /flv/ws_flv/hls/rtmp, 默认 auto checktoken 鉴权 token, 可选, 没有开启分享的通道需要携带登录接口返回的 URLToken4、视频流地址播放集成说明获取通道视频直播流地址 : "rtmp://192.168.2.135:11935/hls/34020000001110000234_34020000001310000002_1200000109"RTSP: "rtsp:// : rtmp://{smsip}:{port}/hls/{设备国标编号}{通道国标编号}RTSP: rtsp://{smsip}:{port}/{设备国标编号}{通道国标编号}HTTPS端口直播流地址格式 : rtmp://{smsip}:{port}/hls/{设备国标编号}{通道国标编号}RTSP: rtsp://{smsip}:{port}/{设备国标编号}{通道国标编号}5、相关问题5.1、接口调用
技术背景 最近不少开发者找到我们,他们在做智能家居等传统行业时,希望实现在Android板件拉取本地的RTSP或RTMP流,然后对外推送RTMP出去,亦或内部启个轻量级RTSP服务,提供个对外对接的媒介 拉流:通过RTSP|RTMP直播播放SDK的数据回调接口,拿到音视频数据; 2. 转推:通过RTMP直播推送SDK的编码后数据输入接口,把回调上来的数据,传给RTMP直播推送模块,实现RTSP|RTMP数据流到RTMP服务器的转发; 3. 录像:如果需要录像,借助RTSP|RTMP直播播放SDK,拉到音视频数据后,直接存储MP4文件即可; 4. 设置RTMP、RTSP拉流的URL; 2. 设置转推RTMP的URL; 3. 实时播放|录像过程中,实时静音、实施快照; 4. 实时播放; 5. 实时录像; 6.
整个架构如下图所示,分为服务器端和浏览器端两部分: websocket.png 方案二:RTSP转RTMP到RTMP服务器,转http-flv,播放端用flv.js播放 flv.js在获取到FLV格式的音视频数据后将 flv格式简单,相比于MP4格式转封装简单、性能上也占优势,解析起来更快更方便。 方案三:RTSP转RTMP到RTMP服务器,转hls,播放端用video.js播放 Video.js是一款web视频播放器,支持html5和flash两种播放方式。 方案五:RTSP转WebRTC播放 浏览器对webrtc的支持良好,特别是在H264编码方面几个主流的浏览器都已经支持了。 webrtc使用srtp进行媒体数据的传输,那么我们只需要将rtp中的负载数据通过webrtc通道发送给浏览器,而浏览器端只需要通过video标签播放即可,目前RTSP转WebRTC对浏览器的适配比较好
可以在通道列表中开启分享 3.1.2.2、分享页面传参 具体的分享页面可以附件的一些参数可以参考:使用分享页面 3.1.2.3、分享页面播放 手机端可以直接扫码观看,或是 手机浏览器访问分享的直播页面 4、 ": "rtmp://192.168.2.135:11935/hls/34020000001110000234_34020000001320000234", "RTSP": "rtsp://192.168.2.135 _34020000001320000234", 4.1.2.6、获取RTMP直播流地址 取接口返回的 RTMP 字段,对应的 RTMP 端口需要在服务端开放 TCP "RTMP": "rtmp://192.168.2.135 : rtmp://{sms_ip}:{port}/hls/{设备国标编号}_{通道国标编号} RTSP: rtsp://{sms_ip}:{port}/{设备国标编号}_{通道国标编号} HTTPS端口直播流地址格式 : rtmp://{sms_ip}:{port}/hls/{设备国标编号}_{通道国标编号} RTSP: rtsp://{sms_ip}:{port}/{设备国标编号}_{通道国标编号} 5、接口调用相关问题
WebRTC: 对比 对比RTMP,WebRTC有以下几个优势:其一,它是一种新型、由IETF和W3C进行标准化的开源技术。 WebRTC在推流时替换RTMP RTMP仍然是第一英里视频贡献的标准,这其中有以下几个原因。第一,RTMP获得了来自直播编码软件和硬件的广泛支持,同时许多社交媒体平台也在使用它。 WebRTC在拉流时替换RTMP 浏览器不再支持RTMP导致播放端无法再使用它。当今大部分直播厂商都在使用HLS进行“最后一英里”的交付,但HLS的延迟要超过30秒。 如图中所示,当以这种方式传输视频时,WebRTC可用于广泛的工作流程中,包括WebRTC端到端,或者从RTMP到WebRTC。 更重要的是,使用次秒级流媒体传输的应用场景还可以利用RTMP到WebRTC的工作流程。