关于视频流媒体服务器的学习记录
前言
由于有时候做的小demo里面会有视频功能的实现，而且基本是借助阿里云和七牛云等等这种第三方平台来实现和管理视频功能，但是只知道用第三方平台是远远不够的。毕竟也是计算机行业的一员，虽然比较菜，但正因为菜才要去不断的学习。
那今天就稍微对这方面的点做一个总结记录，文章中大部分是网上我所找到的内容。其次，这些观点以及解释肯定有不完善的地方，所以还请一些大佬看到后可以及时指正，毕竟我是初学者，非常感谢！
关于两者的区别
网上普遍的回答
流媒体服务器
流媒体是指以流的方式在网络中传送音频、视频和多媒体文件的媒体形式。
而相对于以前由于网速问题，下载后观看的网络播放形式而言，流媒体的典型特征是把连续的音频和视频信息压缩后放到网络服务器上，用户边下载边观看，而不必等待整个文件下载完毕。
由于流媒体技术的优越性，该技术广泛应用于视频点播、视频会议、远程教育、远程医疗和在线直播系统中。流媒体服务器是流媒体系统的核心组成，是向用户提供视频服务的关键平台。
其主要功能是连接端到端，对媒体内容进行采集、推流、转码、传输和分发，流媒体应用系统的主要性能体现都取决于媒体服务器的配置和部署
视频服务器
视频服务器是对视音频数据进行压缩、存储及处理的专用嵌入式设备.
视频服务器采用MPEG4或MPEG2等压缩格式，在符合技术指标的情况下对视频数据进行压缩编码，以满足存储和传输的要求。
视频服务器可以对视音频数据进行压缩、存储及处理，以满足存储和传输的要求，它在远程监控及视频等方面都有广泛的应用。
主要是对音视频的编解码处理，所以很多视频服务器产品也叫做视频编解码器
关于需要了解的相关问题
一、流式传输
是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。
二、流式传输分类
有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以 减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系
三、软件
播放器（Player），用来播放流媒体的软件。
服务器（Server），用来向用户发送流媒体的软件。
编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件
四、协议
既然有了视频这种流数据在网络上的传输，那就必定有网络协议去规范它
- RTP（Realtime Transport Protocol）实时传输协议：是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同 步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠 的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
- RTCP（Realtime Transport Control Protocol）实时传输控制协议：是实时传输协议（RTP）的一个姐妹协议，负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数 量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈 和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
- RTSP（Real Time Streaming Protocol）实时流协议：专为娱乐和通信系统的使用，以控制流媒体服务器。该协议用于创建和控制终端之间的媒体会话。媒体服务器的客户端发布VCR命令，例如播放，录制和暂停，以便于实时控制从服务器到客户端（视频点播）或从客户端到服务器（语音录音）的媒体流。流数据本身的传输不是RTSP的任务。大多数RTSP服务器使用实时传输协议（RTP）和实时传输控制协议（RTCP）结合媒体流传输
- RTMP是Real Time Messaging Protocol（实时消息传输协议）：是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的一个专有协议。
- 默认使用TCP端口1935的纯粹（plain）协议。
- RTMPS，通过一个TLS/SSL连接传输RTMP。
- RTMPE，使用Adobe自有安全机制加密的RTMP。虽然实现的细节为专有，但该机制使用行业标准的密码学原函数。
- RTMPT，用HTTP封装以穿透防火墙。RTMPT通常在TCP端口80和443上使用明文请求来绕过大多数的公司流量过滤。封装的会话中可能携带纯粹的RTMP、RTMPS或RTMPE数据包。
- RTMFP, 使用UDP而非TCP的RTMP，取代RTMP Chunk Stream。Adobe Systems开发了安全的实时媒体流协议包，可以让最终用户直接地相互连接（P2P）。虽然RTMP的主要动机是成为一个播放Flash视频的协议，但它也用于其他一些应用程序，如Adobe LiveCycle Data Services ES
- HLS （Http Live Strea m ing）是由Apple公司定义的用于实时流传输的协议，它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的扩展 M3U (m3u8) 播放列表文件，用于寻找可用的媒体流。HLS只请求基本的HTTP报文，与实时传输协议（RTP）不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流
如何实现
一种是直接使用第三方的流媒体服务器，另一种就是自己直接搭建一个这样的服务器
相关实现技术
SRS（Simple RTMP Server）：SRS定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。SRS提供了丰富的接入方案将RTMP流接入SRS，包括推送RTMP到SRS、推送RTSP/UDP/FLV到SRS、拉取流到SRS。SRS还支持将接入的RTMP流进行各种变换，譬如将RTMP流转码、流截图、转发给其他服务器、转封装成HTTP-FLV流、转封装成HLS、转封装成HDS、录制成FLV。SRS包含支大规模集群如CDN业务的关键特性，譬如RTMP多级集群、源站集群、VHOST虚拟服务器、无中断服务Reload、HTTP-FLV集群、Kafka对接。此外，SRS还提供丰富的应用接口，包括HTTP回调、安全策略Security、HTTP API接口、RTMP测速。
SRS在源站和CDN集群中都得到了广泛的应用Applications是国产优秀流媒体服务器，在Github上开源， 可在 Linux 机器各主流系统上部署，操作简单
- 相关官网内容：
WebRTC：名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。
FFmpeg：是一个开放源代码的自由软件，可以运行音频和视频多种格式的录影、转换、流功能[1]，包含了libavcodec——这是一个用于多个项目中音频和视频的解码器库，以及libavformat——一个音频与视频格式转换库。
2021年9月1号补：可以参考一下这篇文章：【秒懂音视频开发】04_Windows开发环境搭建
RED5：Red5是一个采用Java开发开源的Flash流媒体服务器。它支持：把音频（MP3）和视频（FLV）转换成播放流； 录制客户端播放流（只支持FLV）；共享对象；现场直播流发布；远程调用。Red5使用RSTP作为流媒体传输协议，在其自带的一些示例中演示了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本功能。
开源地址：
Darwin Streaming Server：为苹果公司视频流解决方案的开源版本。
easyDarwin：国内基于Darwin Streaming Server二次开发的流媒体服务器，有中文支持网站。
具体实现
以下完全没有打广告的嫌疑，纯属个人浏览到的文章。
-
目标用于搭建内网流媒体服务器支持视频的点播：[https://www.cnblogs.com/shenfeng/p/nginx_rtmp_streaming_server.html]
-
Nginx流媒体服务器搭建:[https://cloud.tencent.com/developer/article/1763519?from=article.detail.1609679]
-
CentOS7下搭建Jellyfin个人流媒体服务器：【https://cloud.tencent.com/developer/article/1695210?from=article.detail.1763519】
-
一个关于做这方面技术的博主【https://www.cnblogs.com/EasyNVR/】
我个人是并没有去具体实现，所以尚未对分享的文章可靠性做具体预估，但个人觉得应该不会存在很大的问题，而且网上一搜基本是这几种方式。
相关技术内容了解
一、基于HTTP方式的FLV直播
近几年直播行业火爆，开源的直播软件解决方案有SRS（Simple-RTMP-Server）和nginx-rtmp-module，前者是国人发起的一个优秀的开源项目，目前国内很多公司都使用它作为直播解决方案，由C++编写；后者依赖Nginx，以第三方模块的方式提供直播功能，由C编写。SRS采用多线程方式，性能优秀，经受住了众多场景的考验，但是SRS3已经闭源（更正：是有一段时间闭源了，现在又开源了）；nginx-rtmp-module是采用多进程方式，Nginx的性能优秀，但是据网友测试，nginx-rtmp-module的性能不如SRS，并且nginx-rtmp-module的作者已经很久没有更新版本了，支持的功能也有限，例如不支持HTTP方式的FLV直播，而这是国内直播行业普遍采用的方式；再如推流不支持upstream，无法分布式部署功能；还有饱受诟病的播放响应延迟时间很长的问题（即俗称的不能秒播）等。
我在nginx-rtmp-module的基础上实现了基于HTTP方式的FLV直播功能，支持GOP缓存，减少播放响应延迟时间；支持流式和Transfer-Encoding: chunked两种HTTP响应格式；修复nginx-rtmp-module没有listen配置项时，推流失败的问题；解决nginx-rtmp-module已知的bug，见nginx-http-flv-module，欢迎下载测试和修复bug。有问题或者建议，可以加Q群：711969608详聊。目前已经有厂商准备将本模块商用，目前已知有6家，其中一家是华为，目前都还在测试中，有厂商陆续反馈过不少bug，修复后功能已经越来越稳定，在此表示感谢。目前还存在的问题是高并发情况下，群断连接会造成Nginx崩溃和无规律的CPU使用率暴增，最近加班比较多，来不及修复这些问题，后续会不定时更新github。
二、基于Nginx的媒体服务器技术
国内应用比较多的开源流媒体服务器nginx-rtmp-module一直存在功能少、集群化难度大等问题。在LiveVideoStack线上分享中，PingOS 开源项目组开发工程师、UCloud RTC研发工程师朱建平详细介绍了基于nginx-rtmp-module的PingOS流媒体服务器在http-flv、http-ts、hls+、多进程、转推、回源以及集群化部署方面的技术实现细节。
文章链接：https://cloud.tencent.com/developer/article/1609679?from=article.detail.1182120
最后
这是一次简单的技术内容了解，希望以后可以更进一步去看到更加准确，更加优秀，更加方便的技术，也希望自己可以在闲余时间尝试一些关于这方面技术的实现。