1.RTMP推流方案总结
2.SRS流媒体服务器——WebRTC推拉流演示
3.CentOS7下使用SRS搭建流媒体服务器
4.流媒体客户端RTMP拉流保存h264(flv保存为h264)
5.SRS+SRT从“有”到“好用”的飞跃
6.网易云音乐 RN 低代码体系建设思考与实践
RTMP推流方案总结
RTMP协议简介,其全称为Real Time Messaging Protocol,是由Adobe Systems公司为Flash播放器与服务器之间音频、视频和数据传输开发的私有协议。RTMP协议像一个容器,用于装载AMF格式的软件源码好用的数据或FLV中的视/音频数据,一个连接可通过不同的通道传输多路网络流,通道中的包遵循固定大小的传输规则。更多协议细节请参考《rtmp specification 1.0》。
RTMP服务器的选择有多种开源方案,如Nginx的rtmp插件,用于实时流推送,具体实现可参考另一篇博客。SRS(Simple RTMP Server)是一款国人开发的优秀开源流媒体服务器软件,使用C++开发,适用于直播、录播、视频客服等场景,提供丰富的接入方案和流变换功能,GitHub源码链接为:github.com/ossrs/srs。
crtmpserver是一款由C++语言编写的开源RTMP流媒体服务器,功能相对简单,与Flash Player的兼容性较差,但代码结构良好,适用于学习RTMP协议和服务器端编程。GitHub源码链接为:github.com/shiretu/crtm...。
livego是基于Go语言的RTMP直播服务器,Go语言为服务器性能而生,开发效率高于C/C++。GitHub源码链接为:github.com/gwuhaolin/liv...
基于Go的livego服务器解决了语言级别上的并发问题。node-rtsp-rtmp-server是使用Node.js实现的RTMP服务器,GitHub源码链接为:github.com/iizukanao/nod...
测试时,推荐使用大牛直播提供的推流工具,也可以使用FFmpeg进行推流。
RTMP推流器的选择同样多样,librtmp软件包含一个基本的客户端:rtmpdump,以及提供RTMP协议支持的库。FFmpeg也能实现RTMP推流,内部集成了librtmp,官方给出了muxing.c源代码示例。srs-librtmp是srs提供的一个RTMP库,可以推送H数据,但在Windows环境下存在兼容性问题。
音视频开发相关教程与资料可免费订阅QQ群:,领取学习资源。名片赞 下单 源码
SRS流媒体服务器——WebRTC推拉流演示
SRS官方WebRTC文档: github.com/ossrs/srs/wi...
SRS安装部署相关内容:
SRS部分源码分析相关内容:
1. WebRTC推拉流配置
学习地址: FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发 文章福利:免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图,资料包括(C/C++,Linux,FFmpeg webRTC rtmp hls rtsp ffplay srs 等等)有需要的可以点击 加群领取哦~
3.其中rtc_server是全局的RTC服务器的配置,部分关键配置包括:
4.然后是每个vhost中的RTC配置,部分关键配置包括:
5.注意:对应端口,比如,端口必须开启,否则不能进行WebRTC测试。
2. WebRTC拉流演示
3.使用ffmpeg命令进行推流(注意:ip需要换成自己的):
4.推送流成功之后,使用srs自带的rtc_player播放器进行播放,直接请求srs服务的端口即可。
3. WebRTC推流演示
3.如果是window系统,可以Chrome的启动参数。方法:
4.mac系统没找到对应方法,可以配置一台Nginx,申请个免费的HTTPS证书,并配置转发。
5.然后就可以使用WebRTC或者RTMP进行播放。
版权声明:本文为CSDN博主「Lumos`」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接: SRS流媒体服务器--WebRTC推拉流演示_Lumos`的博客-CSDN博客_webrtc推流和拉流
CentOS7下使用SRS搭建流媒体服务器
本地服务器配置:使用 CentOS7 Linux 系统(版本:3..0-..1.el7.x_),IP 地址为 ...。将服务器角色定位为使用 SRS(Simple Realtime Server)搭建流媒体服务器。SRS 支持 RTMP、HTTP-FLV、HLS、WebRTC 协议。推流端设备采用 ffmpeg + OBS 软件进行流媒体推送,拉流端则可以使用 VLC 播放器或在网页中嵌入 SRS 自带的播放器。测试场景设计为通过 ffmpeg 测试 RTMP 推流功能,然后分别使用 VLC 和 SRS 播放器进行流媒体拉取。
所需资料与工具:
链接:pan.baidu.com/s/1x5DyST...(提取码:epxx)
参考网站与资源:
GitHub:ossrs/srs(SRS 源码)
SRS 官网:ossrs.net/(SRS 官方网站)
GitHub Wiki:ossrs/srs/wi...(SRS 起步知识与文档)
SRS:如何用 NGINX 搭建 HLS 分发集群(链接:qq.com)(关于使用 NGINX 与 SRS 集成搭建 HLS 分发集群的教程)
下载 ffmpeg 官方地址:ffmpeg.org/download.htm...(官方 ffmpeg 下载页面)
1、准备工作与环境搭建(使用 root 用户执行):
1.1、安装 CentOS 基础依赖环境
1.2、关闭与禁用防火墙(避免重启服务器后自动开启)
1.3、将 ffmpeg、yasm 和 kk.flv 等文件拷贝至 CentOS 主目录下(使用主目录作为存储位置)
1.4、安装 yasm 编译器
1.5、安装 ffmpeg
1.6、修改 /etc/ld.so.conf 文件
1.7、配置环境变量
1.8、winform 饼图 源码检查环境变量配置是否生效
1.9、Windows 下安装 VLC 和 OBS 播放器
2、SRS 流媒体服务搭建:
2.1、获取 SRS 源码:
- 通过官网下载
- 通过 GitHub 使用**软件下载(推荐)
- 在国内码云使用 gitee.com/ossrs/srs 下载(推荐)
2.2、配置与编译 SRS:
2.3、查看 SRS 配置文件与支持的协议配置(参考 SRS 官方 Wiki)
2.4、启动与关闭 SRS 服务
2.5、通过网页控制台查看 SRS 状态
3、流媒体服务测试:
3.1、使用 ffmpeg 进行 RTMP 推流测试(注意替换实际值)
3.2、RTMP、HTTP-FLV、HLS 拉流地址获取与测试(VLC 或网页 SRS 播放器)
3.3、使用 OBS 播放器进行推流测试(文件推流、摄像头推流与更多推流方式)
4、扩展与学习资源:
4.1、Windows 下搭建 nginx-rtmp 流媒体服务器(参考教程)
4.2、深入学习 SRS 相关知识与技巧(访问 GitHub Wiki 或 SRS 官方网站)
流媒体客户端RTMP拉流保存h(flv保存为h)
librtmp是通过调用int RTMP_Read(RTMP *r, char *buf, int size); 来拉取流,直接得到的流是flv格式,保存后即可播放。
RTMP_Read内部调用Read_1_Packet,其功能是从网络上读取一个RTMPPacket的数据,RTMP_Read在此基础上增加了个字节的flv头。
在librtmp的源码中,可以看到flv头信息。
flv头实际只有9个字节,但为何是个字节?因为除了9个字节的flv头外,还有多个Tag,每个Tag的开头有4个字节表示上一个Tag的长度,即使是第一个Tag也需填充这4个字节,以匹配源码中的flvHeader。
srs_librtmp是通过srs v2.0-r6版本(v2.0-r7版本加入了ipv6功能,但连接rtmp服务器时总是失败,可能是个人使用不当)来拉流并保存为flv文件。
从srs导出的srs_librtmp客户端详情见github.com/ossrs/srs/wiki...,导出后,在research/librtmp下有作者编写的demo,其中srs_rtmp_dump.c用于从rtmp服务器拉流并保存为flv文件。
以下是简化版的demo源码,我注释了自己的理解,若有错误请指正。在vs下此代码能编译运行,但在linux下能正常播放。
主要讲述了flv头信息的源码反码补码 英文结构,srs_librtmp源码中srs_flv_write_tag通过data封装成Tag并写入flv文件,srs_rtmp_read_packet读取的数据是flv文件中的tag data。
Tag data分为Audio、Video、Script三种,这里仅讲解Video Tag Data。
VideoTagHeader的第一个字节包含了视频帧类型及视频CodecID的基本信息。VideoTagHeader之后跟着的是VIDEODATA数据,即video payload,对于H.格式的视频,VideoTagHeader会额外包含4个字节的信息。
AVCPacketType和CompositionTime。AVCPacketType表示VIDEODATA的内容类型:若AVCPacketType为0,则为AVCDecoderConfigurationRecord(H.序列头);若为1,则为一个或多个NALU(完整帧是必需的)。
AVCDecoderConfigurationRecord包含H.解码相关的sps和pps信息,解码器在送数据流之前必须送出sps和pps信息,否则解码器不能正常解码。在解码器停止后再次开始之前,如seek、快进快退状态切换等,都需要重新送出sps和pps的信息。AVCDecoderConfigurationRecord在FLV文件中通常只出现一次,即第一个video tag,但有些视频流的sps和pps可能会发生变化,所以可能会出现多次。
Composition Time用于告知渲染器视频帧进入解码器后多长时间在设备上显示。在flv格式中,timestamp用于告知帧何时提供给解码器,单位为毫秒。Composition Time告诉渲染器视频帧显示的时间,因此compositionTime = (PTS - DTS) / .0。
总结如下:使用srs_librtmp拉流,拉取的数据为一个又一个的Tag Data,可通过type与宏值比较判断Tag Data是否为Video Tag Data。连接rtmp服务器拉流时收到的第一个Video Tag Data通常包含PPS和SPS信息。对于每个h编码的Video Tag Data,会多出4个字节的AVCPacketType和CompositionTime,其中CompositionTime用于B帧,这里暂时忽略它,我们仅支持P帧和I帧。Frame Type在h编码中只能是1或2,Frame Type == 1表示关键帧或包含PPS和SPS信息的Video Tag Data。CodecID在h编码中只能是活动介绍页面源码7(AVC)。当AVCPacketType == 0时,Video Tag Data包含SPS和PPS信息;当AVCPacketType == 1时,为帧数据。
获取PPS和SPS信息非常关键,如果不告知解码器,根本无法播放视频。我写了一段代码,虽然技术有限,但希望能帮助到您。
AVCPacketType为1表示Video Tag Body的内容是NALU。Frame Type为1表示NALU内容是关键帧,Frame Type为2表示NALU内容是非关键帧。NALU的开头的4个字节表示NALU的长度(nalu_length),nalu_length之后是一个字节的nalu header。
nalu header中nal_ref_idc表示优先级,范围在~(2进制),值越大表示越重要。值指示NAL单元的内容不用于重建影响图像的帧间图像预测。对于nal_unit_type为6、9、、、的NAL单元,H.规范要求NRI的值应该为0。对于nal_unit_type等于7、8(指示顺序参数集或图像参数集)的NAL单元,H.编码器应设置NRI为(二进制格式)。nal_unit_type表示nalu类型,SPS开头是0x(nal_ref_idc为3,nal_unit_type为7),PPS开头是0x(nal_ref_idc为3,nal_unit_type为8),关键帧开头是0x(nal_ref_idc为3,nal_unit_type为5),非关键帧开头是0x(nal_ref_idc为2,nal_unit_type为1)。nal_unit_type为5表示idr帧,idr帧具有随机访问能力,所以每个idr帧前需要加上sps和pps。startcode起始码。
H.原始码流由一个一个的NALU组成,其结构包括起始码(0x或0x,取决于编码器实现)和数据。具体何时使用3个字节的起始码,何时使用4个字节的起始码,这个我没有完全弄明白,资料中提到具体哪种开头取决于编码器实现。0x是NAL起始前缀码,解码器检测每个起始码,作为NAL的起始标识,当检测到下一个起始码时,当前NAL结束。同时H.规定,当检测到0x时,也可以表示当前NAL的结束。对于NAL中数据出现0x或0x时,H.引入了防止竞争机制,如果编码器检测到NAL数据存在0x或0x时(非起始码,而是真正的音视频数据),编码器会在最后个字节前插入一个新的字节0x,这样当遇到0x或0x时就一定是起始码了。解码器检测到0x时,把抛弃,恢复原始数据。因此,组装H的步骤如下:读取tag data并判断是否是video tag data,判断frameType和AVCPacketType,区分video tag data是AVCDecoderConfigurationRecord还是NALU,如果是AVCDecoderConfigurationRecord则解析PPS和SPS保存在内存中并加上startcode(我这里加的是0x),如果是NALU,则判断nal_unit_type(有些NALU的流比较奇怪,依然包含PPS、SPS信息,甚至还有SEI信息)。switch case根据不同的nal_unit_type来解析,并加上startcode。如果nal_unit_type == 0x,则是idr帧,需要加上PPS和SPS信息(即一个idr通常包含3个startcode,SPS一个PPS一个idr帧数据一个)。
以下是完整代码:
rtmpTo.h
rtmpTo.cpp
main.cpp
原文链接:blog.csdn.net/qq_...
SRS+SRT从“有”到“好用”的飞跃
好的用户体验是用户在使用产品时,感受不到产品的存在,就像毛坯房并不能拎包入住,需要通过装修、配套服务、交通等让其变得舒适。复杂性不会凭空消失,而是经过不断的学习、理解与改进,将其隐藏在配置命令和工具中。
SRT从无到有,背后是施维大神的辛勤努力。而SRT从有到好用,则得益于志宏大神的不懈追求。大神们之所以投入精力于SRT,原因之一是活跃在SRT用户群体中的热情用户,不断尝试和使用SRT,为SRT的完善提供了动力。
编译FFmpeg和SRT并非易事,尤其是解决依赖问题,如钻石依赖,任何一步的设置或版本出现问题,编译都可能失败。同时,FFmpeg和SRS在编译支持SRT时也面临挑战,这增加了复杂性,使得产品体验难以达到理想状态。
然而,好用的产品体验就是让用户在使用时感受不到复杂性,音视频项目尤其如此。复杂性不会消失,而是通过不断优化和改进,将其隐藏在配置命令中。这并不意味着之前的开发不够好,因为开源项目往往缺乏完善的研发、产品、文档和测试团队,这在一定程度上导致了不完善和复杂性。
对于开源的理解,目前仍停留在代码层面,代码在GitHub上开源并不能立即被开发者使用,就像毛坯房需要装修、配套服务等才能成为宜居之所。对于那些热衷于自己搭建RTMP服务器的人来说,不妨考虑使用SRS,它能提供更全面、更方便的解决方案。
SRT Docker是快速构建SRT全链路的方法,无需编译,直接启动即可。同样,直接使用SRT进行推流,点击链接即可播放,极大地简化了使用流程。如果需要从源代码编译SRT/SRS,可以使用Docker环境,因为依赖环境已配置好,减少了编译失败的风险。
使用SRS的开发Docker环境可以提供FFmpeg,且所有静态链接,包括SRT、x和AAC,减少了编译过程中的依赖问题。目前已有支持FFmpeg静态链接的Docker镜像,志宏大神对SRS中SRT的支持进行了优化,提高了产品的稳定性和兼容性。
本文旨在介绍SRS和SRT的发展历程、使用方法以及优化策略,希望能为开发者提供有价值的参考和帮助。SRS开源服务器,致力于提供更高效、更易用的音视频服务解决方案。
网易云音乐 RN 低代码体系建设思考与实践
在构建低代码平台时,Tango是一个用于快速构建低代码平台的低代码设计器框架,以源代码为中心,执行和渲染前端视图,为用户提供低代码可视化搭建能力。借助Tango构建的低代码工具或平台,可以实现源码进,源码出的效果,无缝与企业内部现有的研发体系进行集成。当前,Tango设计引擎部分已经开源,正在积极推进中,欢迎大家加入社区共同参与建设。
RN(React Native)作为主流的跨端方案,具有建全的社区生态,每周下载次数稳步上升,下载量相比5年前已翻倍,GitHub Star数量超过万。RN具有较低的上手成本,可以快速迁移React技术栈,减少客户端开发同学的编译时间,提高开发效率。同时,RN提供了丰富的组件库和API,支持动态更新,满足跨端、动态更新以及复杂业务需求的场景。在国内,动态更新能降低产品的试错成本,快速上线和修复线上问题。重构已久的RN新架构已经确定将在年正式推出,将为RN开启一个全新的阶段,带来了更好的启动性能和渲染机制、通信性能的提升。
云音乐在RN场景下的研发现状显示,RN具有众多优势,云音乐也有大量的RN需求。在需求迭代和研发投入的过程中,暴露了一些问题。基于C端场景的特点,云音乐在开发过程中的核心流程包括:准备开发环境、静态页面开发与还原视觉(交互)稿、进入业务开发阶段。然而,在实际操作中,云音乐遇到了DSL方案的局限性,即在面对灵活性高的移动端场景时,DSL无法满足业务需求,导致需要开发介入定制DSL或升级组件,增加了研发成本。为解决这些问题,云音乐引入了Tango,通过AST驱动提供源码为中心的RN在线搭建能力,支持快速交付,并提供标准化的线上研发流程。
在移动端搭建上,云音乐面临一系列问题,包括DSL方案的局限性、传统搭建平台的问题等。为解决这些问题,云音乐采用Tango提供的源码为中心的在线搭建能力,支持RN应用快速交付,并通过标准化的线上研发流程提升效能。此外,云音乐还构建了在线真机预览调试环境,解决了模拟器运行环境和实时画面传输问题,实现与现有RN研发生态的融合。
云音乐在构建在线真机预览调试环境时,考虑了多种方案,最终选用SRS流媒体服务器、OBS进行窗口捕获及推流,并利用WebRTC进行拉流。经过实践,实现了0.5s至2s内的平均响应速度。此外,云音乐还构建了基于Socket网关的云手机调度与通信交互方案,实现了高并发下的云手机分配与一致性的保证,为在线联调提供了必要的工具。
在与低码结合方面,云音乐通过Tango提供了多维度的可视化搭建模拟,包括节点选中效果、结构树可视化编排等。同时,云音乐也提供了双模式切换、源码模式下的开发体验增强、多形式的代码生成等能力,以降低从0搭建成本。此外,Tango低码生态建设旨在构建一个以源码为中心的完整低码研发生态体系,包括运行时框架、组件、数据资产沉淀与可视化编排等,以提升开发效率。
云手机的应用场景丰富,可以平替依赖物理手机的扫码类场景,远程联调客户端协议,查看应用程序在不同设备和屏幕尺寸上的显示效果,以及用于测试回归等。在低码平台的构建中,平衡点的寻找是一个持续探讨的问题,如何在通用性和贴合业务场景之间找到最佳平衡,以实现高内聚、低耦合的T型架构,是低码从业者需要不断思考和实践的。