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格式的安卓ps源码数据或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、lol金牌代理源码检查环境变量配置是否生效

       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型架构，是低码从业者需要不断思考和实践的。