大家好，关于rtmp流媒体服务器搭建很多朋友都还不太明白，今天小编就来为大家分享关于搭建流媒体推流的知识，希望对各位有所帮助！
一、Nginx-rtmp 直播媒体实时流实现
Nginx-rtmp直播媒体实时流实现概览
在构建一个IPCamera项目服务器过程中，为了解决P2P穿透和NAT设备限制问题，以及IPv4资源的限制，选择了主流的RTMP协议作为服务器转发方案。这个过程中，Nginx的rtmp插件被选为实现实时流转发的核心工具。
文章首先介绍了项目的需求，包括自建RTMP流媒体服务器和利用云厂商服务，以及为了支持非流媒体数据传输而设计的媒体转发服务。接着，通过详细步骤展示了如何从GitHub和编译Nginx-rtmp-module，并配置Nginx.conf以支持RTMP协议。
文章还提及了Nginx-rtmp模块的HTTP异步通知回调功能，通过SpringBoot搭建HTTP服务接收RTMP回调，以及客户端如何通过i*cast.的推流软件进行推流。Nginx-rtmp的鉴权方法，包括自定义auth函数或通过HTTP回调状态码进行验证，也在文中有所涉及。
尽管本文没有详述RTMP鉴权的具体实现，但提示了涉及数据库的房间号功能和初步的HTTP请求判断逻辑。最后，文章提到了Windows环境的便利*，并分享了一些相关配置说明、参考资源和Nginx-RTMP的Windows二进制。
二、搭建流媒体推流***拉流服务***RTMP***RTSP***HLS***HTTP***FLV***
流媒体技术是一种通过实时传输媒体数据以供在线观看的技术，它支持多种媒体类型，如音频、视频、文本等，并能在用户观看时即时播放，无需等待整个文件完成，大大节省了存储空间。在构建流媒体服务时，我们通常需要考虑兼容不同传输协议，如RTMP、RTSP、HLS和HTTP-FLV。
为了实现流媒体的推流和拉流，服务器搭建是关键。常见的方案包括使用Nginx，通过添加nginx-rtmp-module或-flv-module。nginx--flv-module功能更全面，适合处理HTTP-FLV类型的流媒体。具体安装和配置过程需要参考相关文档，如[待完成]。
推流方面，可以选择OBS Studio来推流Windows上位机的屏幕数据，或者使用ffmpeg将本地视频推送到服务器。拉流包括RTMP、RTSP、HTTP-FLV和HLS-M3U8，测试时可以通过网络URL验证是否正常播放。
在选择播放器时，Video.js是通用的开源选项，它兼容HTML5和Flash，适合大多数场景，但可能与部分摄像机不兼容。Bilibili的flv.js提供FLV到MP4的转换，适用于HTML5环境，而dplayer.js则提供了swf播放器的解决方案。
总的来说，搭建流媒体服务涉及到协议选择、服务器配置、推流和拉流操作，以及针对不同浏览器的播放器适配，确保视频流的流畅播放是关键。在实际应用中，根据项目需求和浏览器兼容*选择合适的工具和技术是必不可少的。
三、CentOS7下使用SRS搭建流媒体服务器
本地服务器配置：使用 CentOS7 Linux系统（版本：3.10.0-1160.66.1.el7.x86_64），IP为 192.168.30.22。将服务器角色定位为使用 SRS（Simple Realtime Server）搭建流媒体服务器。SRS支持 RTMP、HTTP-FLV、HLS、WebRTC协议。推流端设备采用 ffmpeg+ OBS软件进行流媒体推送，拉流端则可以使用 VLC播放器或在网页中嵌入 SRS自带的播放器。测试场景设计为通过 ffmpeg测试 RTMP推流功能，然后分别使用 VLC和 SRS播放器进行流媒体拉取。
所需资料与工具：
：pan.baidu./s/1x5DyST...（提取码：e*x）
参考网站与资源：
GitHub：ossrs/srs（SRS源码）
SRS官网：ossrs./（SRS官方网站）
GitHub Wiki：ossrs/srs/wi...（SRS起步知识与文档）
SRS：如何用 NGINX搭建 HLS分发集群（：qq.）（关于使用 NGINX与 SRS集成搭建 HLS分发集群的教程）
ffmpeg官方：ffmpeg./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、检查环境变量配置是否生效
1.9、Windows下安装 VLC和 OBS播放器
2、SRS流媒体服务搭建：
2.1、获取 SRS源码：
-通过官网
-通过 GitHub使用翻墙软件（推荐）
-在国内码云使用 gitee./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官方网站）
四、如何快速搭建一个完整的移动直播系统
移动直播行业的火热会在很长一段时间内持续，通过和各行业的整合，从而成为具有无限可能*的行业。主要因为以下三个原因：
第一，移动直播的UGC生产模式比PC端的直播更明显，人人都有设备，随时随地开播，完全顺应了互联网时代的开放*原则，能刺激更多人去创造和传播优质内容。
第二，网络带宽和速度在逐渐提高，网络成本在逐渐下降，为移动直播提供一个极佳的发展环境。文字、声音、视频、游戏等都会在移动直播中呈现，创造出更加丰富的用户体验。直播可以以SDK的形式接入到自己的应用中，比如，教育领域中的课后辅导完全可以以直播的形式开展业务、电商也可借助直播让用户挑选商品，促进销售。
第三，一个与VR/AR技术相结合的移动直播为整个行业的未来提供了新的发展空间。VR/AR直播能够让用户身临其境，带动主播与观众更贴切真实的互动，大大提高平台的用户参与度。
当下，有技术实力和流量优势的互联网从业者都不愿错过直播这个风口，如何快速搭建一个直播系统成了大家关心的问题，我想和大家分享下我的经验。我从事于一家直播产品开发商，我们的产品为了快速赶上市场，并没有自己完全去自己做，而是使用了趣拍云服务提供的直播SDK。
从业者都知道，一个完整直播产品应该包含以下环节：推流端（采集、前处理、编码、推流），服务端处理（转码、录制、截图、鉴黄），播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。下面我就一一讲述下直播SDK在各个环节所做的工作。
一、移动直播推流端需要做哪些工作？
直播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。
1、采集
移动直播SDK通过手机摄像头和麦克风采集音视频数据。其中，视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。采集到的原始音视频的体积是非常大的，需要经过压缩技术处理来提高传输效率。
2、前处理
在这个环节主要处理美颜、水印、模糊等效果。美颜功能几乎是直播的标配功能。我们调研中发现太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。
美颜实际上是通过算法去识别图像中的皮肤部分，对皮肤区域进行色值调整。通过颜色对比找到皮肤区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持iOS和Android，支持自己写算法实现自己最理*的效果。GPUImage内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了。
3、编码
为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积，现在比较常用的视频编码是H.264。在音频方面，比较常用的是用AAC编码格式，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。
相较于之前的H.264，2012年诞生的H.265编解码标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。像阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。
H264和H265个模块技术差异：
另外，硬件编码已经成为移动直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在iOS平台上硬件编码的兼容*比较好，可以采用，但在Android平台上，MediaCodec编码器针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。
4、推流
要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1_3秒，对于移动直播这种实时*要求非常高的场景，RTMP也成为移动直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。
当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，*能非常有保障。当然，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅*和稳定*。
二、服务端处理需要做哪些工作？
要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。
1、截图、录制、水印
像阿里云等云服务商都提供了实时转码技术，将用户推流码率较高（比如720P）实时转化成较低清晰度（比如360P）的流以适应播放端的需求。如果要自己搭建实时转码系统，这个成本是极高的，一台8核设备只能实时转10路流，如果一个正常的直播平台有1000路流，就需要100台设备，加上后期的运维成本，一般公司就吃不消了。
2、鉴黄
2016年4月14日，文化部查出了*、虎牙、YY、熊猫TV、六间房、9158等涉嫌提供含宣扬**、暴力、*犯罪的网络直播平台，被列入查处名单。政府介入管制有利于直播行业打造健康的生态，进入良*发展。这也意味着为了安全直播产品鉴黄成了必需环节，使用技术手段去鉴黄是移动直播平台必然采用的方案。
市面上提供鉴黄服务的方案主要有两种，第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值。典型的企业有阿里（绿网）、图谱科技，他们目前都支持传入视频，经过服务端分析返回结果。通常由业务系统接入鉴黄服务，根据鉴黄结果对直播流进行控制，如切断直播流、封禁账号等。第二种是和CDN结合，对直播流进行分析，识别结果分为色情、疑似色情、*和正常，业务系统根据识别结果控制直播流。典型的企业是Viscovery，这套方案的优点是实时*保证比较好，缺点是必须部署到CDN或自己的机房，使用成本相对高一些。
还有像趣拍云服务这种一站式直播解决方案提供商，他们的做法是，用户只需在控制台对鉴黄服务进行配置就可以针对每个应用、每一路直播流进行实时审核。在控制台中，趣拍视频云服务实时将鉴黄结果返回，用户可以查看色情直播和违规界面的截图，同时可以对直播流进行控制，切断问题直播流。该服务商还提供了短信、邮件和站内信功能，避免漏掉任何一个非法视频，给平台造成损失，我们就使用了这种方式。
三、播放器端需要做哪些工作？
在播放器端如何做到秒开，直播过程中保证画面和声音清晰度的同时，稳定、流程、无卡顿的直播流量，这些工作都需要播放器端配合服务端来做优化，做到精确调度。
1、拉流
拉流实际是推流的逆过程。首先通过播放端获取码流，标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议，开源软件和开源库都支持的比较好，如开源的librtmp库，播放端只要支持flashPlayer的就能非常简单的播放RTMP直播，直播延迟一般在1_3秒。HLS是苹果提出的基于HTTP的流媒体传输协议，HTML5可以打开播放，通过、QQ等软件分享出去，用户也可以观看直播，可以说移动直播，HLS拉流协议是必须支持的，缺点是延迟通常大于10秒。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议，也不用担心被Adobe的专利*，直播延迟同样可以做到1_3秒。
各拉流协议的差异：
我们使用的趣拍视频云服务的直播拉流技术提供了以上三种格式，满足不同业务场景的需求，如对即时*要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放；对于有回放或跨平台需求的，推荐使用HLS。当然，三种协议是可以同时使用的，分别用到自己的场景就可以了。
2、解码和渲染
拉流获取封装的视频数据后，必须通过*解码、渲染后才能在播放器上播放。它是编码的逆过程，是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩，所以在提取后的原始数据，并非原始采样数据，存在一定的信息丢失。因此，在视频体积最小的情况下通过各种编码参数保留最好的原始画面，成为了各视频公司的核心机密。
考虑对高清的支持，解码肯定还是要选择硬解码的。前面介绍过，iOS系统由于硬件比较单一、比较封闭，支持的比较好，Android系统由于平台差异非常大，编解码要完全兼容各平台还需要很多工作要做。
四、移动直播中的交互系统
移动直播中最常见的交互有聊天室（弹幕）、点赞、打赏和礼物等，交互系统涉及消息的实时*和互动*，在技术实现上大多是使用IM的功能来实现的。对于在线人数比较多的房间，弹幕消息量是非常大，主播与用户其实都看不过来，为了缓解服务器压力，在产品策略需要做一些必要的优化。
1、聊天室
移动直播中的弹幕交互是用户和主播互动的主要方式，实际上就是IM中的聊天室功能。聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。
2、礼物系统
礼物系统更是绝大多数移动直播平台的标配了，它是这些平台主要的收入来源。送礼物的形式也增强了用户和主播之间的互动交流，也是主播依赖平台的最主要原因。
礼物的收发在技术实现上也是用聊天室接口做的，通常采用IM中的自定义消息实现，当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。
以上就是我们在使用了第三方SDK服务后总结出来的直播产品经验，希望能帮助到创业者和从业者们。