FFmpeg FFplay框架分析
超详细的ffmpeg.c框架分析
一步一步搭建流媒体服务器的详细步骤
1、应用场景
目前，流媒体领域的应用场景非常多。由于网络服务的升级，越来越多的行业开始使用音视频交互作为最快的沟通工具。相信当5G真正普及时，更多的传统行业将利用流媒体实现快速升级，提高生产效率。目前视频交互、远程教育医疗、直播等，这些行业都采用了流媒体技术，带来了产业的腾飞。
直播主要功能
主要功能如下。这些功能当中，有直播、录音等，还有其他技术，包括聊天通讯、礼物兑换、直播列表、房间、系统设置等。这些技术有的需要后端支持，有的则需要后端支持。需要前端显示。如果你想成为一名CTO 或系统架构师，这些都是必备技能。
直播平台系统架构图
注：专业CDN一般都有专线。集群一般是构建在内网，分布式一般是指部署在外网。
如果架构分层的话，可以分为接入层、数据访问层、接口层和业务服务层。接入层包括PC客户端、H5、微信接入。接入层连接WEB和APP。数据接入层主要使用Nginx进行负载均衡和API网关，提供各种服务，包括日志管理、权限控制、监控管理、流量监控、路由服务、支付服务等。接口层包括第三方API和接口服务和后台管理，比如推送服务、拉取服务、CDN服务，以及一些用户后台、用户管理等。推流服务主要功能包括视频直播、录播、录屏、边缘加速、数据分布和交互。后端服务包括直播管理、录播管理、转码管理、支付管理、订单管理、流量管理、内存监控、短信邮件管理、会员管理等。业务服务层主要包括各种需求相关的服务，例如如用户服务、讲师服务、直播服务等，以及一些账号、收费、讲师等相关业务需求。最后就是穿梭于各层的公共组件，比如支付组件、登录注册、短信组件等。总体来说，这些东西很复杂，但是如果你想成为一名CTO，技术的广度和深度都是基本的。希望这两张图能够成为我们共同发展的“蓝图”。
注：一些认证、防盗链机制、Token机制都可以参考阿里云。
简化版直播框架
简化后的直播框架如下。流媒体端主要包括音视频采集、音视频处理、音视频编码、音视频推送等。流媒体端主要包括音视频解码、音视频同步、音视频播放等。音视频采集在不同平台上有不同的解决方案。然后送入音视频处理，音频如混音、降噪等，视频如水印、美化等，这些都是非常重要的。如果音频不消除噪音，主播不美化，用户体验会很差。音视频编码，指定编码成不同格式，然后封装推送到流媒体服务器。流媒体方面，主要任务是解封装、音视频解码、音视频同步、音视频播放。其中音视频解码、同步、播放在不同平台上有不同的解决方案。
直播流程及技术栈
采集流方面，常用的框架有FFmpeg框架、X264框架、open264框架、fdk-aac框架、librtmp框架、OpenGL框架、OpenCV框架等。 FFmpeg框架通常可以使用提供的接口进行解封装、编码、解码和流式传输。使用该方法时，需要注意的是缓冲区较难控制。 X264框架一般用于视频编码，层次比较低。视频编码也采用openh264框架，效率更高。 fdk-aac框架一般用于音频编码，比较底层。 librtmp框架用于音频和视频流，也比较底层。 OpenGL框架一般用于视频渲染和视频处理，比如滤镜处理。效果也很好，是常用的解决方案之一。 OpenCV框架一般用于视频处理，也可以用于解码等操作。 OpenCV也调用了FFmpeg的某些函数，是常用的解决方案之一。
在流媒体服务器中，一般流媒体服务器都有数据分发、实时转码、截图、录像等功能，数据分发包括一些CDN。屏幕截图可以应用于封面。录制视频一般用于视频查看或回放。常用的服务器有nginx+rtmp_module、SRS（这也是常见的方案之一，使用协程框架，效率很高）、Red5（这是java版本）。
播放端一般有视频拉取、解码、渲染、聊天交互功能。常用的框架有FFmpeg框架、ijkPlayer框架、OpenGL框架、SDL框架等。可以直接使用FFmpeg框架进行解码。 ijkPlayer是Bilibili基于FFplay的全套开源二次打包框架。 OpenGL框架（win和android都有）一般用于视频处理和渲染。 SDL框架（多用于win端）一般用于渲染。
常用的推送测试工具连接地址：
ffmpeg：https://www.ffmpeg.org/download.html
OBS工作室：https://obsproject.com/download
常用拉力测试工具连接地址：
ffplay: https://www.ffmpeg.org/download.html
cutv flash 播放器：www.cutv.com/demo/live_test.swf
虚拟LC
ijkplayer : 是一个基于FFmpeg 的开源Android/iOS 视频播放器。
具有以下优点：
API易于集成。
可以定制编译配置，方便控制安装包大小。
支持硬件加速解码，更省电。
简单易用，指定串流URL并自动解码播放。
缺点：
无法满足部分玩家的定制化需求。
高延迟。
因此，根据优点和确定性选择合适的选项。
压力测试工具
SRS自带一个工具：st-load
流媒体服务器简介
SRS：国人开发的一个优秀的开源流媒体服务器系统。
BMS：也是一个流媒体服务器系统，但是不开源。它是SRS的商业版本，比SRS有更多的功能。
nginx：免费的开源网络服务器，也常用于配置流媒体服务器。只需集成Rtmp_module即可。
Red5：是一个用java编写的稳定的开源rtmp服务器。
CDN
CDN的全称是Content Delivery Network，即内容分发网络。 CDN是在现有网络上构建的智能虚拟网络。它依托部署在各地的边缘服务器，利用中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，减少网络拥塞。提高用户访问响应速度和命中率。 CDN的关键技术主要包括内容存储和分发技术。
CDN网络包含的功能实体包括内容缓存设备、内容交换机、内容路由器、CDN内容管理系统等。内容缓存是CDN网络节点，位于用户接入点。它是为最终用户提供内容的设备。它可以缓存静态Web内容和流媒体内容，并实现内容的边缘传播和存储，以便用户就近访问。
内容交换机位于用户访问集中点，可以在单点均衡多个内容缓存设备的负载，对内容进行缓存负载均衡和访问控制。
内容路由器负责将用户请求路由到适当的设备。内容路由通常通过负载均衡系统来实现，动态平衡各个内容缓存站点的负载分布，为用户请求选择最佳的访问站点，提高网站的可用性。内容路由器可以根据多种因素进行路由，包括站点与用户的接近程度、内容可用性、网络负载、设备状况等。负载均衡系统是整个CDN的核心。负载均衡的准确性和效率直接决定了整个CDN的效率和性能。内容管理系统负责整个CDN的管理。它是一个可选组件，用于内容管理，例如内容注入和发布、内容分发、内容审核、内容服务等。
总结起来，CDN主要有以下几个功能：
(1)节省骨干网带宽，减少带宽需求；
（2）提供服务器端加速，解决用户访问量大导致的服务器过载问题；
(3)服务提供商可以利用Web Cache技术将用户访问过的网页和对象缓存在本地，这样访问相同的对象不需要占用骨干网的出口带宽，提高了用户相应的时间要求。访问互联网页面；
（4）可以克服网站分布不均匀的问题，降低网站建设和维护的成本；
（5）减少“通信风暴”的影响，提高网络访问的稳定性。
CDN关键技术
内容发布
它使用索引、缓存、流分割和多播（Multicast）等技术将内容发布或传送到距离用户最近的远程服务点（POP）。内容分发包括从内容源到CDN边缘缓存的过程。从实现上来说，主流的内容分发技术有两种：PUSH和PULL。
PUSH是一种主动分发技术。通常，PUSH由内容管理系统发起，将内容从源或中央媒体资源库分发到各个边缘的Cache节点。分发协议可以使用Http/ftp等。通过PUSH分发的内容一般都是热点内容。这些内容通过PUSH的方式预先分发（Preloaded）到边缘缓存，可以提供有针对性的内容。 PUSH分发要考虑的主要问题是分发策略，即什么时候分发什么内容。一般来说，内容分发可以由CP（内容提供商）或CDN内容管理员手动确定，也可以通过智能的方式确定，即所谓的智能分发，即根据用户访问统计和预定义的内容分发。规则决定内容分发的过程。 PULL是一种被动分发技术，PULL分发通常由用户请求驱动。当用户请求的内容在本地边缘缓存上不存在（未命中）时，缓存启动PUL方法，从内容源或其他CDN节点实时获取内容。在PULL模式下，内容按需分发。
内容路由
是一种全面的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制平衡多个远程POP上的用户请求，使用户请求从最近的内容源收到响应。
CDN负载均衡系统实现CDN的内容路由功能。它的作用是将用户请求引导到整个CDN网络中最好的节点。最佳节点的选择可以基于多种策略，如距离最近、节点负载最轻等。负载均衡系统是整个CDN的核心。负载均衡的准确性和效率直接决定了整个CDN的效率和性能。通常负载均衡可以分为两个级别：全局负载均衡（GSLB）和本地负载均衡（SLB）。全局负载均衡的主要目的是将用户请求引导到整个网络中最近的节点（或区域）。因此，邻近判断是全局负载均衡的主要功能。本地负载均衡一般局限于一定区域，其目标是在特定区域内找到最合适的节点提供服务。因此，CDN节点的健康状况、负载状态、支持的媒体格式等运行状态是本地负载均衡做出决策的主要依据。
内容存储
对于CDN系统，需要考虑两个方面的内容存储问题。一是内容源的存储，二是Cache节点中内容的存储。
对于内容源的存储，由于内容规模较大（通常达到几TB甚至几十TB）、内容吞吐量大，通常采用NAS、SON等海量存储架构。 Cache节点的存储是Cache设计中的一个关键问题。需要考虑的因素包括功能和性能。功能包括支持各种内容格式以及支持部分缓存；性能包括支持的容量、多文件吞吐量、可靠性和稳定性。
其中，多种内容格式的支持需要存储系统根据不同文件格式的读写特点进行优化，以提高文件内容读写的效率。特别适合读写流媒体文件。部分缓存能力意味着流媒体内容可以以不完整的方式存储和读取。缓存需求的部分原因在于用户访问行为的随机性，因为许多用户不会完整观看整个流媒体节目。事实上，许多用户访问单个流媒体节目的时间不超过10 分钟。因此，部分缓存能力可以大大提高存储空间利用率，有效提高用户请求的响应时间。然而，部分缓存可能会导致内容碎片问题，需要良好的设计和控制。
缓存存储的另一个重要因素是存储可靠性。目前，大多数存储系统都采用独立磁盘冗余阵列（RAID）技术来实现可靠存储。但是，不同的设备使用不同的RAID 方法。
内容管理
通过内部和外部监控系统获取网络组件的状态信息，测量内容发布的端到端性能（如丢包、延迟、平均带宽、启动时间、帧率等），以确保网络处于最佳运行状态。
广义的内容管理涵盖内容发布、注入、分发、调整、交付等一系列流程。这里的内容管理重点是内容进入Cache点后的内容管理，称为本地内容管理。本地内容管理主要在ODN节点（由多个CDN Cache设备和SLB设备组成）上进行。本地内容管理的主要目标是提高内容服务的效率，提高本地节点的存储利用率。通过本地内容管理，可以在CDN节点实现内容感知调度。通过内容感知调度，可以避免用户被重定向到没有内容的Cache设备，从而提高负载均衡的效率。本地内容管理还可以有效实现ODN节点上内容的存储共享，提高存储空间利用率。
关于CDN，也很复杂。下面这张图可以简单说明一下。
采集端业务逻辑
（1）客户端一般会先创建房间，并请求创建直播地址。
(2)流媒体服务器向采集端返回直播流地址。
(3)采集端获取直播流地址，将编码封装后的码流推送至流媒体服务器。
注：不同采集端生成的地址不同且不固定。
播放逻辑
(1)玩家侧向业务服务器查询房间列表。
(2)业务服务器向播放端返回房间列表和播放地址。这通常是自动生成的。
（3）播放器获取地址后，即可拉取流媒体服务器内容。
推拉模块
(1)流媒体端，一般包括音视频采集、同步、编码、复用、发送等。
(2)流媒体方面，一般包括音视频解封装、解码、同步、显示等。
注意：
(1) 在流端，将实时监控编码后的队列数据。当网络不好时，视频队列会丢弃所有非I帧或一组GOP以减少延迟。取出音频队列数据，然后重新解码、重新采样，比如变速播放、减少延迟。
(2)在流媒体侧，实现数据加密，通常是在编码之后。如果先加密再编码，数据量太大。
(3)直播一般不使用B帧或减少B帧。为什么？由于B帧会增加延迟时间，解码B帧需要参考I帧和P帧，因此需要对B帧进行缓存。如果B帧越多，缓存时间就会越长，因此延迟就会越大。
缓冲控制
(1)确定延迟时间
要确定实时采集图像与图像回放显示的时间差，通常使用手机同时拍摄采集图像和回放图像，看看延迟时间差。如下图：
一般情况下，当网络抖动较大、数据积累导致GOP缓存过多时，降低延迟实际上意味着实时改变缓存的大小。
(2) 第一帧以秒为单位开始
如果CDN节点数量增加，则需要更多时间。秒级打开的第一帧将考验直播CDN的组网方式、网络覆盖范围以及传输协议的优化程度。一般情况下，第一帧会在几秒内打开。服务器需要预先缓存一组GOP。当客户端发起拉取请求时，服务器会将缓存的GOP 组发送给客户端。这样完整的GOP组保证了客户端收到的第一帧是I帧，可以实现首帧开秒。但由于服务器提前缓存了，所以会出现播放延迟。两者是冲突的，所以在设计的时候需要考虑妥协。
战略
预热：提前拉取热门直播。
集群：通过CDN内容分发和调度就近共享数据。
(3)卡顿
卡顿通常发生在流媒体端、CDN 内部或客户端。设计时最好能够统计出冻结的次数或持续时间。
根据上面的分析，延迟、首屏、滞后的本质都涉及到缓冲控制。
质量控制
推送端、CDN、播放端都会有相应的监控。通过分析，选择合适的策略。
CDN监控
具体指标如下：
连接建立时间、首帧时间、缓冲区大小、帧率、码率、帧丢失等
流媒体端和播放端监控：
DNS解析时间、连接建立时间、首帧时间、缓存大小、帧率、码率、丢帧、码率、卡顿率、失败率等。
滞后原因分析
滞后的原因一般包括音视频不同步、视音频丢失、图像质量低、帧率低、时间戳异常、采集丢帧、采集端发送到编码端的帧不完整等。
解决方案一般包括增加带宽、优化编码参数、调整资源、修复时间戳增量、使用动态缓冲区等。
故障排除滞后
(1)网络滞后
观察是整个网络卡还是局部卡。如果整个网络卡住，检查上行带宽（整个网卡也可能出现流量异常，如码率过高），如果局部卡住，检查下行带宽。因此，流媒体端和播放端普遍存在这种卡顿的可能。
(2)推流卡住
推送路径监控
是否经常掉线。
是不是流媒体端推送速度不够？
内部上传速度不够？
常见原因
流媒体端的网络问题。例如ping 流点和speedtest 来测量速度。
连接推点不合理。可能是调度问题，或者dns配置不正确或者localdns不正确。
内部链接问题。检查丢失的数据包。
节点处于高负载状态（cpu、内存、io、带宽、机房带宽等）。
(3) 流式传输和延迟
部分地区滞后较大
常见原因：
丢包。
高负载（cpu、内存、io、带宽、机房带宽）。
节点覆盖。
关于播放异常分析
(1)时间戳问题
时间戳跳跃。
音频和视频之间存在很大差距。
如何验证？
您可以播放原码流来验证是否是原码流问题或者播放异常。
(2)声音异常
由于网络抖动，没有声音。
(3)黑屏
元数据正常吗？如果元数据读取不正确，就会出现黑屏问题。
是否有视频序列头。例如，使用工具检查SPS、PPS和SEI是否被解析。
用户评论
凝残月
这个流媒体服务器架构的文章写得真好，对技术小白也很有帮助，学到了很多！
有15位网友表示赞同！
荒野情趣
流媒体服务器架构这块儿还是第一次接触，这篇文章分析得挺到位，谢谢分享。
有8位网友表示赞同！
龙吟凤
看了这篇文章，对流媒体服务器架构有了更深的理解，感觉之前的疑惑都解开了。
有11位网友表示赞同！
窒息
流媒体服务器架构的应用分析，这个标题就很有深度，文章内容也不负所望。
有9位网友表示赞同！
伱德柔情是我的痛。
刚刚接触流媒体行业，这篇文章对我帮助很大，感谢作者！
有16位网友表示赞同！
神经兮兮°
流媒体服务器架构，这个概念听起来好高大上，现在终于明白了。
有6位网友表示赞同！
沐晴つ
文章中提到的流媒体服务器架构优化方法，我打算在实际工作中试一试。
有16位网友表示赞同！
逃避
流媒体服务器架构的应用分析，这个话题太实用了，强烈推荐给同行们。
有15位网友表示赞同！
可儿
看了这篇文章，我对流媒体服务器架构有了全新的认识，受益匪浅。
有9位网友表示赞同！
眉黛如画
流媒体服务器架构，这个文章标题就让我眼前一亮，内容更是精彩。
有15位网友表示赞同！
站上冰箱当高冷
文章对流媒体服务器架构的介绍很详细，不过感觉还是有点复杂，需要多看几遍。
有15位网友表示赞同！
作业是老师的私生子
流媒体服务器架构的应用分析，这个方向很有前景，我要赶紧学习一下。
有16位网友表示赞同！
志平
作者对流媒体服务器架构的讲解很到位，但感觉文章中的一些细节可以再完善一下。
有16位网友表示赞同！
回忆未来
这篇文章让我对流媒体服务器架构有了更深入的了解，准备在我的项目中应用一下。
有12位网友表示赞同！
等量代换
流媒体服务器架构的应用分析，这个话题太实用了，尤其是对于我这个新手来说。
有5位网友表示赞同！
执念，爱
文章中提到的流媒体服务器架构问题，我在实际工作中也遇到过，感谢作者分享解决方法。
有17位网友表示赞同！
孤廖
流媒体服务器架构的应用分析，这个文章让我对整个行业有了更全面的了解。
有10位网友表示赞同！
oО清风挽发oО
这篇文章对流媒体服务器架构的讲解很专业，希望作者能继续分享更多相关内容。
有5位网友表示赞同！
伪心
流媒体服务器架构，这个话题真的很有挑战性，这篇文章给了我很多启示。
有15位网友表示赞同！