1.【音视频开源项目】ZLMediaKit 的源码安装及使用介绍
2.ZLMediaKit 服务器源码解读---RTSP推流拉流
3.RTSP流媒体服务器的搭建与测试《带源码》
4.unimrcpclient源码分析mrcp components
5.obsrtsp视频流转化为rtmp视频流?
6.解决FFmpeg播放RTSP推送的H265码流报错问题
【音视频开源项目】ZLMediaKit 的安装及使用介绍
ZLMediaKit是一个功能强大的开源流媒体服务器，特别适合实时音视频传输和处理应用，源码如直播、源码视频会议和监控。源码它支持RTSP、源码RTMP、源码照片换底色源码HLS和HTTP-FLV等协议，源码具有低延迟和高并发处理能力，源码且能动态转码，源码并跨平台运行。源码 要开始使用，源码首先从GitHub地址github.com/xia-chu/ZLMe...下载源代码。源码编译安装步骤适用于Linux环境，源码运行时可通过其HTTP API进行管理。源码API接口包括控制流媒体播放、源码获取状态信息、统计信息，以及配置服务器参数等，如:启动/停止流媒体：通过发送HTTP请求来控制。
查看状态和统计：获取服务器连接数、流状态和带宽使用情况等。
配置参数：如设置网络端口、转码设置和录制选项。
录制与截图：支持控制服务器的录制和截图功能。
实时监控：通过HTTP API监控服务器运行和日志。
此外，HTTP API还支持通过UDP或TCP进行推流，例如循环播放视频，对于点播，ZLMediaKit支持通过mp4文件实现，例如rtsp://.../record/test.mp4，通过HTTP访问文件进行点播。 在Linux下，音频设备的管理也很关键，可以使用aplay、pactl等命令查看和配置音频设备。而服务的推拉流，包括设备向服务器推流和从服务器拉流，也是android recovery 源码通过API和相应的命令来操作的。 最后，当遇到端口占用问题时，可以使用lsof和netstat命令在Linux中查找占用情况，以便进行相应的操作。ZLMediaKit的详细文档和更多视频教程可以在mirrors/xia-chu/zlmediakit/GitCode中找到。ZLMediaKit 服务器源码解读---RTSP推流拉流
RTSP推流与拉流在ZLMediaKit服务器源码中有着清晰的解析过程和处理逻辑。数据解析通过回调到达RtspSession类的onRecv函数，进而进行分包处理，头部数据与内容分离。根据头部信息判断数据包类型，rtp包与rtsp包分别由onRtpPacket和onWholeRtspPacket函数处理。
RTSP处理过程中，解析出的交互命令被分发至不同的处理函数。对于rtp包处理，数据封装成rtp包后，执行onBeforeRtpSorted函数进行排序，排序后的数据放入缓存map，最终回调到RtspSession的onRtpSorted函数。这里，回调数据进入RtspMediaSourceImp成员变量，该变量指向RtspDemuxer解复用器，用于H等视频格式的解复用。
在H解复用器中，rtp包经过一系列处理后，由HRtpDecoder类的decodeRtp函数转化为H帧数据，最终通过RtpCodec::inputFrame函数分发至代理类。代理类在处理H帧数据时，分包并添加必要参数（如pps、sps信息），然后通过map对象将数据传递给多个接收者。
处理完H帧后，数据将流转至编码阶段。在RtspMediaSourceImp中，H帧数据被传递至MultiMediaSourceMuxer编码类。在编码过程中，数据通过RtspMuxer的inputFrame接口进入编码器HRtpEncoder，最后被打包成rtp包，准备分发。c clock源码
总结而言，RTSP推流过程主要包含数据解析、视频解复用与编码三个关键步骤。在拉流阶段，通过鉴权成功后获取推流媒体源，利用play reader从缓存中取出rtp包并发送给客户端。
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，以提升数据安全性和读取速度，同时控制成本。提供丰富文档、问题解答、学习资源、opensns 源码下载资料视频与源码分享，支持C/C++、Linux、Nginx、golang等技术栈学习与实践。unimrcpclient源码分析mrcp components
配置样例包含六个部分。
函数unimrcp_client_components_load主要负责这六个组件的加载，下面详细解析各个组件的加载过程。
加载resource组件时，其结构体mrcp_resource_t定义在mrcp_resource.h，字符串使用apt_str_table_item_t（定义在mrcp_resource_loader.c），mrcp_resource_loader_t和mrcp_resource_factory_t分别位于mrcp_resource_loader.c和mrcp_resource_factory.c。构造mrcp_resource_loader内部是mrcp_resource_factory_t *factory，factory通过mrcp_resource_factory_create构建，参数为MRCP_RESOURCE_TYPE_COUNT的第5个值，整型值为4。
加载sip-uac组件时，mrcp_sofia_client_config_t结构体（mrcp_sofiasip_client_agent.c）应用于sofia sip协议栈。默认端口和名称设定如下：config->local_port = DEFAULT_SIP_PORT; 默认端口为，config->user_agent_name = DEFAULT_SOFIASIP_UA_NAME; 默认agent name为UniMRCP SofiaSIP，config->origin = DEFAULT_SDP_ORIGIN; 默认sdp origin为UniMRCPClient。IP地址配置通过unimrcp_client_ip_address_get（unimrcp_client.c）实现，可配置为“auto”或“iface”。然后使用mrcp_sofiasip_client_agent_create（mrcp_sofiasip_client_agent.c）创建sofiasip_client。
加载rtsp-uac组件时，指代MRCPv1版本的uac组件。rtsp_client_config_t结构体（mrcp_unirtsp_client_agent.h）用于配置。组件加载通过unimrcp_client_rtsp_uac_load函数完成。
加载media-engine组件时，配置项仅包含realtime_rate。unimrcp_client_media_engine_load函数负责加载此组件。mpf_engine_t结构体（mpf_engine.c）用于创建mpf_engine，使用mpf_engine_create函数。
加载rtp-factory组件时，mpf_rtp_config_t结构体（mpf_rtp_descriptor.h）包含可配置项。unimrcp_client_rtp_factory_load函数用于加载此组件，并通过mpf_rtp_termination_factory_create（mpf_rtp_termination_factory.c）创建相应的工厂。
obsrtsp视频流转化为rtmp视频流?
要将obsrtsp视频流转化为rtmp视频流，首先需确认操作平台。对于Windows系统用户，直接利用官方工具可能有限制或不便。可考虑使用第三方工具作为替代方案，一款推荐的工具是github.com/daniulive/StreamCopier。
StreamCopier是一款功能强大的视频流转换工具，支持将rtsp视频流转换为rtmp格式。使用StreamCopier时，只需按照以下步骤操作：
1. 首先，确保在计算机上安装了StreamCopier。通常情况下，可以通过GitHub下载源代码并使用命令行或IDE进行编译，或寻找已编译的二进制文件。
2. 打开StreamCopier，通过命令行界面输入rtsp视频流的URL和rtmp服务器的URL。请确保rtmp服务器的URL格式正确，并且提供足够的带宽以支持视频流的传输。
3. 根据提示配置视频流的参数，例如音频和视频的编码格式、分辨率、帧率等。这些设置应根据实际需求进行调整，以确保转换后的视频流质量和兼容性。
4. 点击开始按钮，StreamCopier将自动开始转换视频流。转换过程中，可能需要一段时间，具体取决于视频流的大小和网络状况。转换完成后，即可通过rtmp服务器进行直播或分发。
总之，将obsrtsp视频流转化为rtmp视频流，通过使用StreamCopier等工具，Windows系统用户能够轻松实现视频流格式的转换。请根据实际需求选择合适的工具和参数设置，以确保转换过程顺利并达到期望的视频质量。
解决FFmpeg播放RTSP推送的H码流报错问题
RTSP，实时流传输协议，常用于传输视频流。许多流媒体平台，如B站的ijkplayer，都是基于FFmpeg的FFplay内核。我曾分享过关于使用RTSP推送H码流的文章，包括本地拉流和编码时的推流显示。然而，当尝试使用FFplay处理RTSP推送的H码流时，遇到了报错"illegaltemporal ID in RTP/HEVC packet"。
这个错误提示指向了H的NALU Header中的temporal ID问题。FFmpeg的源码检查了这个值，如果为0，会报错。H标准规定temporal ID不能为0，因此这个检查是合理的。问题可能出在RTP封装过程，而非原始码流，因为本地H码流的NALU Header值并不是0。
为了解决这个问题，我深入研究了RTP封装H裸流的原理，发现在HSource.cpp的HandleFrame函数中，处理NALU数据时忽略了起始码。修正这一逻辑后，成功用FFplay播放了RTSP推送的H视频，尽管与VLC的播放效果相比稍有卡顿。FFplay播放的命令行参数包括指定窗口名称和分辨率。
总结来说，通过问题定位和源码解析，我解决了FFplay在处理RTSP H码流时的报错，实现了本地H视频的正确播放。这个过程对理解FFmpeg工作原理和RTSP封装有帮助。
海康大华等摄像头RTSP低延迟(小于毫秒)网页播放完全解决方案！
在浏览器中实现播放RTSP实时视频流，需要考虑多种方案以实现低延迟、低成本的多路稳定播放。首先，浏览器插件方案在IE及Chrome 以下版本的浏览器中是主流选择，使用ActiveX播放控件或NPAPI播放插件，可直接调用本地原生程序播放，充分利用硬件解码和硬件加速渲染，实现良好效果。VLC作为开源跨平台多媒体播放器，支持IE、Chrome及Firefox低版本浏览器插件，移动端兼容性也非常好。然而，此方案需要额外安装VLC客户端软件，并对某些场景不适用。
其次，先转码再转流方案需要架设视频流转码服务器，利用ffmpeg转码串流成RTMP，然后前端使用VideoJS播放Adobe Flash Player。然而，基于Chromium内核的浏览器自年起全面取消了对Flash Player的支持，VideoJS因此失效。当前方案使用flv.js实现，要求服务端先把RTSP视频流转换为flv，然后通过Web Socket或WebRTC推送到前端，前端再转换为Video所支持的MP4播放。这种方案导致RTSP视频流需要经过两次转码，画面延迟时间大幅增加，且长期使用服务器端转码和转流对CPU、内存、网络带宽压力大，成本高，播放高分辨率视频流时经常出现花屏、卡顿现象。此方案要求浏览器支持流媒体扩展特性(MSE)，无法利用本机硬件加速实现解码和渲染播放，适用于移动端网页播放。
第三，先转流再转码方案通过Streamedian公司的免插件播放器Html5 RTSP Player实现。此方案需要架设Web Socket视频流转发服务器，前端连接到服务器后，服务端不断转发RTSP视频流给前端JS处理库，后端库再转换为Video所支持的MP4播放。此方案不支持IE浏览器，画面延迟高达数秒，首屏显示慢，无法利用本机硬件加速，CPU占用高，播放时存在花屏、卡顿现象，体验差。此方案要求浏览器支持流媒体扩展特性(MSE)，适用于单源播放，多路播放时服务器压力大，且兼容性较差，不适合作为商业用途。
扩展程序方案，如基于Chrome浏览器的PPAPI插件技术的VXG RTSP Player，不适用于IE、Firefox等浏览器，且谷歌已宣布将在年6月终止对NaCl、PNaCl和PPAPI API的支持，无讨论价值。双内核方案，如采用Chrome扩展程序IETab实现，存在大规模自主可控部署难问题，IE内核环境下播放控件控制困难，IE兼容性差，用户体验差，维护升级麻烦。
最后，Wasm方案采用Chrome等高版本浏览器支持的Wasm标准技术，实现RTSP视频流通过ffmpeg的Wasm版软解码为Video支持的MP4播放。Wasm不支持硬件解码，多路播放时终端电脑的CPU和内存占用高，性能差。此方案适用于需要支持H编码的场景，要求浏览器支持流媒体扩展特性(MSE)，实际应用案例较少。
升级方案集中在实现不转码并充分利用终端电脑硬件加速特性的外接系统。这种系统需要在浏览器网页中实现一个内嵌到网页中的播放窗口，前端可控制播放窗口，并随浏览器窗口操作联动。播放窗口为本地原生程序，采用高性能C++语言开发，利用硬件加速，前端通过Web Socket连接播放窗口并发送JSON命令控制播放。市场上已有类似实现的软件，如猿大师中间件，提供全兼容性，包括低版本Chrome和IE浏览器，提供了类似ActiveX控件的安全机制。某视频监控大厂发布的版本采用QT框架，联动效果差，程序包大，未提供前端自动升级和安全调用机制。免插件方案中，外接程序的安全性可通过验证并开放源代码打消顾虑，部署和升级压力小，整体效果优于IE中的ActiveX控件。
综上所述，本文提供了一个稳定可靠、兼容性好、低延迟且可同时稳定播放多路RTSP的低成本半开源技术方案，特别适用于高分辨率RTSP播放。选择技术实施方案时，需考虑满足客户刚性需求、降低总成本、保证兼容性和稳定性，并确保技术方案不会因浏览器升级而失效。此方案适用于机场、地铁站、交管局等场景，实现低延迟、低成本的多路稳定播放。
