1.SRS(simple-rtmp-server)流媒体服务器源码分析--RTMP消息play
2.SRS流媒体服务器——单机环境搭建和源码目录介绍
3.流媒体客户端RTMP拉流保存h264(flv保存为h264)
4.音视频开源项目ZLMediaKit 的流媒安装及使用介绍
5.分析流媒体服务器源码:Rtmp发布流程的SRS解析
6.RTSP流媒体服务器的搭建与测试《带源码》
SRS(simple-rtmp-server)流媒体服务器源码分析--RTMP消息play
本章内容梳理了SRS在接收到RTMP信息后如何进行转发的过程。在此过程中,体源首先进行代码梳理,码流媒体作者也在源码熟悉阶段,源码可能尚未完全梳理完接受到RTMP后信息如何处理、编程缓存以及转发给直播用户等内容。流媒青蛙tv源码
SRS源码中的体源Play流程如下:
1. 进入play流程:本章内容直接从SrsRtmpConn::stream_service_cycle()方法开始梳理。
2. 在接受流程中,码流媒体客户类型为SrsRtmpConnFMLEPublish “fmle publish”,源码而在转发流程中,编程客户类型为SrsRtmpConnPlay。流媒
3. 在/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、快进快退状态切换等,mstcpip.h源码都需要重新送出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单元的linux 应用源码下载内容不用于重建影响图像的帧间图像预测。对于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_...
音视频开源项目ZLMediaKit 的安装及使用介绍
ZLMediaKit是一个功能强大的开源流媒体服务器,特别适合实时音视频传输和处理应用,如直播、视频会议和监控。它支持RTSP、RTMP、HLS和HTTP-FLV等协议,具有低延迟和高并发处理能力,且能动态转码,并跨平台运行。 要开始使用,首先从GitHub地址github.com/xia-chu/ZLMe...下载源代码。编译安装步骤适用于Linux环境,运行时可通过其HTTP API进行管理。API接口包括控制流媒体播放、获取状态信息、统计信息,以及配置服务器参数等,如:启动/停止流媒体:通过发送HTTP请求来控制。
查看状态和统计:获取服务器连接数、ip在线转换源码流状态和带宽使用情况等。
配置参数:如设置网络端口、转码设置和录制选项。
录制与截图:支持控制服务器的录制和截图功能。
实时监控:通过HTTP API监控服务器运行和日志。
此外,HTTP API还支持通过UDP或TCP进行推流,例如循环播放视频,对于点播,ZLMediaKit支持通过mp4文件实现,例如rtsp://.../record/test.mp4,通过HTTP访问文件进行点播。 在Linux下,音频设备的管理也很关键,可以使用aplay、pactl等命令查看和配置音频设备。而服务的推拉流,包括设备向服务器推流和从服务器拉流,也是通过API和相应的命令来操作的。 最后,当遇到端口占用问题时,可以使用lsof和netstat命令在Linux中查找占用情况,以便进行相应的操作。ZLMediaKit的详细文档和更多视频教程可以在mirrors/xia-chu/zlmediakit/GitCode中找到。分析流媒体服务器源码:Rtmp发布流程的SRS解析
Rtmp发布流程在SRS服务器中主要通过单线程多协程模型来实现,以简化线程管理和数据同步。以下是关键步骤的解析:
SRS基于state-threads协程库工作,每个协程在单线程内独立执行,无需考虑线程安全问题。程序启动后,通过SrsStreamListener监听并处理TCP连接,创建SrsTcpListener和SrsReusableThread进行并发处理。
当接收到客户端连接时,会根据连接类型创建不同的SrsConnection,如RtmpConn。SrsRtmpConnFMLEPublish负责处理推流至服务器,会进入publishing函数,其中创建SrsPublishRecvThread协程,接收和处理客户端的消息。
消息处理中,视频数据会经过缓存H序列头、HLS分发和消费者分发等步骤。每个消费者有自己的SrsMessageQueue,队列大小由配置文件中的"queue_length"设置,队列满时旧消息会被丢弃,但关键的序列头不会被删除,避免影响客户端解码。
总结来说,SRS的Rtmp发布流程通过高效的单线程协程设计,保证了数据的缓存和分发,同时通过策略性丢包避免了可能导致花屏的问题。
RTSP流媒体服务器的搭建与测试《带源码》
搭建与测试RTSP流媒体服务器,通过C++实现,支持Linux和Windows编译环境,使用VLC客户端进行测试,功能包括RTSP的多种操作、SDP生成、RTP打包和TS文件解析,附带源码分析文档。 新增功能包括: 别名功能:通过替换真实的文件名和路径,以更友好、更短的URL发布资源,增强用户体验。 内容缓存:在多台服务器间传输多媒体文件,提升客户播放内容品质,节约传输成本,优化内容交付路径。 定制日志:灵活定义信息捕捉规则与时间,支持默认模板或自定义模板,便于系统报告生成。 SLTA功能:模拟直播传输代理,支持多种流媒体格式,提供更强大的发布方式,实现流媒体直播体验。 RTSP缓存指示:控制哪些内容应被缓存在Helix Universal Server,提供更大缓存灵活性。 冗余服务:为内容发布提供等级选择,确保在RealOne Player断开后,可切换至另一服务器连接,保证播放连续性。 Windows Media流媒体支持:通过MMS协议或HTTP协议向Windows Media Player传输流媒体,支持与Windows Media Encoder的连接,实现多格式流媒体发布。 MPEG流媒体支持:发布MPEG-1、MPEG-2、MP3及MPEG-4格式内容,确保多种音频与视频格式的兼容性。 智能流:在保证带宽的前提下,使用智能流优化Real音频或Real视频广播,确保客户端接收合适的码率。 RealOne Player统计:增强客户统计状态,返回更详细信息,利用TurboPlay功能优化播放体验。 搭建网络直播电视,支持多种流媒体格式,如音频文件(RealAudio、Wav、Au、MPEG等)、视频文件(RealVideo、AVI、QuickTime等)及其他类型内容,通过Helix Producer将不支持的文件转换为可支持的格式。 提供多种服务模式,包括点播、直播与模拟直播,满足不同场景需求。Linux环境下安装配置,包括域名或IP地址绑定、加载点配置、服务器连接控制、访问控制与服务器监控,确保系统稳定运行。 RTSP流媒体服务器通过避免视频文件被浏览器通过HTTP下载,优化了内容传输效率。建议在中小型视频点播服务中使用RAID 5,以提升数据安全性和读取速度,同时控制成本。提供丰富文档、问题解答、学习资源、资料视频与源码分享,支持C/C++、Linux、Nginx、golang等技术栈学习与实践。每日开源:一个巨硬的产品级嵌入式流媒体库
哈喽,我是老吴。
今天分享一个比较复杂的开源项目:live 是一个开源的流媒体库,用于实现实时流媒体的传输和处理。它提供了一套跨平台的 C++ 类库,帮助快速构建高效、可靠的流媒体服务器和客户端应用程序。
live的代码量庞大,约9w行代码。如果专注于核心逻辑,代码量缩减到约8K行。使用live,你可以收获高效可靠的流媒体库,了解产品级的C++项目设计,掌握音视频基础知识,甚至获得基于select()的C++事件循环库。live在媒体播放器、流媒体服务器、视频监控系统等领域应用广泛,如VLC、FFmpeg、GStreamer均使用live实现流媒体的接收和播放。
live基于C++,语法相对简单,适合专注于学习C++类设计和编写专业的C++软件。为了理解源码,需要补充多媒体、流媒体的理论知识。通过阅读和运行相关应用,加深对理论知识的理解。
编译live库后,会生成4个静态库:libBasicUsageEnvironment.a和libUsageEnvironment.a用于实现事件循环、上下文管理、任务管理等;libliveMedia.a负责多媒体流化,包括音视频编解码、流媒体协议实现;libgroupsock.a负责网络IO功能,核心是TCP、UDP的读写。简单示例是RTP传输MP3音频,涉及server和client两个程序。
server程序的核心逻辑包括准备运行环境、设置数据来源、设置数据目的地。TaskScheduler用于任务管理,基于select()实现事件循环。BasicUsageEnvironment用于上下文管理。数据流化本质是网络传输,Source和Sink分别表示数据源和目的地,本例中Source是MP3FileSource,Sink是MPEG1or2AudioRTPSink。client端程序同样初始化Source和Sink。
RTP协议简介,RTP(Real-time Transport Protocol)是一种用于实时传输音频和视频数据的网络传输协议,基于UDP,用于在IP网络上传输实时媒体数据。RTP协议设计目标是提供低延迟、高效率的传输,以满足实时应用需求。主要特点包括时间戳、序列号、负载类型、NACK反馈和RTCP(Real-time Transport Control Protocol)等。
关键问题是如何实现数据一帧帧流化?关注点不是具体音视频格式解析或特定协议实现,而是live对音视频流化的整体框架。通过示例分析,live本质上将音视频数据逐帧解码,通过RTP协议经网络发送。live封装了多种数据Source和Sink,但无需详细了解每个概念。仍以RTP传输MP3数据为例,分析live的工作流程。
首先,需要对相关类的关系有大概概念:MediaSource是所有Source的父类,各种具体音视频Source基于其派生;MediaSink是所有Sink的父类,派生出FileSink、RTPSink等众多Sink类。Sink类最关键的成员函数是startPlaying(),用于使用Source对象获取帧数据,然后发送至网络。
RTP传输MP3的主要逻辑包括准备就绪后调用MediaSink::startPlaying()启动数据流化,在packFrame()调用Source对象的getNextFrame()。getNextFrame()最终调用MP3FileSource的doGetNextFrame(),负责MP3音频解码,解码完成后,回调afterGettingFrame(),正常时调用sendPacketIfNecessary()发送数据,并添加至事件循环调度器中。一段时间后,MultiFramedRTPSink的sendNext()被调用,推动新一帧数据传输,直到Source中的所有帧数据被消费。
live如何创建RTSP服务器?通常RTP协议与RTSP协议结合使用,对外提供RTSP服务器服务。RTSP提供控制实时流媒体传输和播放的标准化方式,可以控制播放、暂停、停止、快进、后退等功能。添加几行代码即可创建RTSP服务器。RTSP服务器封装实现RTSP服务,类似HTTP协议,是文本协议。服务器包括接受客户端连接、读取客户端数据、解析和处理数据的操作。
总结,live是一个开源的多媒体流媒体库,支持常见流媒体协议,提供高效可靠的流媒体传输功能,适用于构建流媒体服务器和客户端应用程序。使用live需要熟悉C++编程和网络编程知识,官方提供丰富示例代码,帮助快速熟悉库的使用方法。