视频流从入门到放弃（第五篇）：SRS、ZLMediaKit、Nginx-RTMP 到底是什么？如何搭建自己的直播平台？
🏗️ 视频流从入门到放弃（第五篇）：SRS、ZLMediaKit、Nginx-RTMP 到底是什么？如何搭建自己的直播平台？关键词：SRS · ZLMediaKit · Nginx-RTMP · 流媒体服务器 · 直播架构 · RTMP · HLS · WebRTC🚀 开头刚接触直播的时候，我有个疑问：既然 FFmpeg 能推流：FFmpeg → RTMP → 播放器不就完了吗？为什么还需要 SRS、ZLMediaKit、Nginx-RTMP 这些流媒体服务器？后来真正做项目才发现：FFmpeg 是工具，而流媒体服务器才是整个直播系统的核心。没有流媒体服务器：主播 × 10000 观众基本跑不起来。一、流媒体服务器到底干什么？很多新人理解为：主播 → 视频 → 观众结束。实际上，流媒体服务器承担：接收推流协议转换转码录制鉴权CDN 分发集群调度例如主播推 RTMP，用户看 HLS，服务器需要做：RTMP → 转换 → HLS否则用户根本看不了。二、为什么不能直接 FFmpeg → 用户？假设主播 8 Mbps，10000 观众。主播直接发：8 Mbps × 10000 = 80 Gbps，普通服务器直接去世。所以必须：主播 → 流媒体服务器 → 观众主播只上传一次。三、Nginx-RTMP 是什么？最老牌方案之一。本质是 Nginx + RTMP 模块。配置示例：rtmp { server { listen 1935; application live { live on; } } }启动后，rtmp://ip/live/test 即可推流。四、Nginx-RTMP 优缺点优点缺点简单、轻量、部署方便功能少、维护较少、WebRTC 支持弱现在新项目基本很少选。五、SRS 是什么？全称：Simple Realtime Server国内直播圈传奇项目，很多公司最初直播系统就是用 SRS 起家的。特点：RTMP、HLS、HTTP-FLV、WebRTC 全部支持，配置简单。六、SRS 架构OBS → RTMP → SRS → RTMP → HTTP-FLV → HLS → WebRTC一套搞定。七、HTTP-FLV 是什么？很多人没听过，其实就是 FLV + HTTP。特点：比 HLS 延迟低，一般 1~3 秒。架构：主播 → RTMP → SRS → HTTP-FLV → 观众国内直播平台曾经大量使用。八、为什么国内喜欢 HTTP-FLV？CDN 支持好成本比 WebRTC 低很多延迟 1~3 秒，秀场直播、游戏直播已经够用九、ZLMediaKit 是什么？国内另一个神级项目，特点是 性能极高、协议极多。支持：RTMPRTSPRTPGB28181HLSHTTP-FLVWebRTC尤其在安防监控、国标 28181 领域，几乎是霸主。十、SRS 和 ZLMediaKit 怎么选？这是面试常问。场景推荐直播、短视频、秀场、语聊房SRS（生态成熟、文档友好、直播经验丰富）监控、摄像头、国标 28181ZLMediaKit（RTSP、GB28181 能力太强）十一、直播平台真实架构很多新人以为：OBS → SRS → 观众结束。实际上生产环境：主播 → 接入层 → SRS 集群 → 转码集群 → CDN → 观众中间可能还有：录制系统、审核系统、推荐系统、聊天系统、礼物系统。十二、流媒体服务器为什么需要转码？主播可能上传 1080P 8 Mbps，但用户用 4G 网络看不了。于是服务器生成多档位：1080P → 720P → 480P → 360P用户自动切换，这就是 ABR（自适应码率）。十三、什么是 ABR？自适应码率。例如网络变差，播放器自动降档：1080P → 720P → 480P避免卡顿。这也是为什么有时候画质突然糊了——播放器在救你。十四、百万观众直播架构面试高频题：如何设计百万级直播平台？答案：不会用一个 SRS 扛 100 万，而是分层架构：主播 → 源站 SRS → 边缘 SRS → CDN → 用户类似 MySQL 主从的思路。十五、Java 后端在直播系统里干什么？很多 Java 程序员最关心的问题。Java 基本不处理视频。视频处理由 SRS、FFmpeg、ZLMediaKit 负责。Java 负责：用户系统直播间系统聊天系统礼物系统订单系统审核系统推荐系统例如用户点击“进入直播间”，Java 返回：{ "roomId": 1001, "playUrl": "https://xxx/live.m3u8" }播放器再去拉流。十六、直播系统全景图 Java 业务系统 ┌─────────────────────────────┐ │ 用户服务 聊天服务 礼物服务 │ │ 订单服务 审核服务 推荐服务 │ └──────────────┬──────────────┘ │ ▼ Redis │ ▼ 主播 → OBS → RTMP → SRS → FFmpeg 转码 → CDN → 播放器 → 观众📝 面试高频题Q1：FFmpeg 和 SRS 区别？FFmpeg = 工具SRS = 流媒体服务器Q2：为什么需要流媒体服务器？协议转换、转码、分发、鉴权、录制。Q3：SRS 和 ZLMediaKit 怎么选？直播 → SRS监控 → ZLMediaKitQ4：Java 负责处理视频吗？一般不负责，主要负责业务逻辑。Q5：直播平台为什么需要 CDN？降低源站压力。📌 总结如果只记一句话：FFmpeg 是螺丝刀，SRS/ZLMediaKit 是工厂，CDN 是物流网络。真正的直播系统：视频处理 = 流媒体服务器业务逻辑 = Java 服务大规模分发 = CDN理解这一层之后，你已经超过大部分只会调用播放器 API 的开发者了。🔮 下一篇预告《视频流从入门到放弃（第六篇）：直播间万人在线，弹幕和礼物到底是怎么实现的？》下一篇进入 Java 后端最熟悉、也是面试最爱问的部分：WebSocket 为什么能支撑弹幕IM 服务怎么设计礼物连击如何实现在线人数怎么统计Redis 在直播系统中的作用千万级消息推送架构这一篇开始，就从“流媒体”进入“直播业务架构”了。👍 觉得有用？欢迎点赞、收藏、转发，让更多人一起入门视频流！
视频流从入门到放弃（第三篇）：RTMP、HLS、WebRTC 谁才是真正的直播之王？
🎬 视频流从入门到放弃（第三篇）：RTMP、HLS、WebRTC 谁才是真正的直播之王？关键词：RTMP · HLS · WebRTC · 直播协议 · 低延迟直播 · CDN · 推流 · 拉流🚀 开头刚接触直播时，我以为：直播协议 = 传视频的方法后来做项目才发现：协议选错了，整个系统都可能重做。例如：你做的是 视频会议，结果用了 HLS。 用户说：“我说完话，5秒后你才听到。”你做的是 万人直播，结果用了 WebRTC。 服务器直接爆炸。所以：直播协议不是技术选型，而是业务选型。今天把最常见的三个协议讲透：RTMP · HLS · WebRTC一、先搞懂一个问题直播协议到底在解决什么？其实就一个事：如何把主播的视频，快速送到观众手机看似简单，实际上要解决：延迟丢包带宽并发跨平台兼容于是诞生了各种协议。二、RTMP 是什么？全称：Real Time Messaging Protocol最早是 Adobe Flash 时代的产物。当年几乎所有直播（YY、斗鱼、虎牙）都是 RTMP。流程：主播 → RTMP推流 → 流媒体服务器 → RTMP拉流 → 观众三、RTMP 为什么火？因为 低延迟。通常 1~3 秒 即可观看，对于十年前已经很厉害了。并且基于 TCP，优点是可靠，丢包自动重传，画面质量稳定。四、RTMP 为什么快死了？因为 Flash 死了。2017年后，Chrome、Safari、Edge 开始放弃 Flash。 2020年 Flash 正式停止支持。结果：浏览器无法直接播放 RTMP。于是 RTMP 变成了 推流协议，而不是播放协议。现在最常见的用法：OBS → RTMP → 服务器依然主流。五、HLS 是什么？全称：HTTP Live Streaming，由苹果推出。核心思想：不实时传，而是切片。例如一个直播流被切成：1.ts 2.ts 3.ts 4.ts ...然后生成一个 index.m3u8 播放列表。用户下载 m3u8 获得列表，再逐个下载 ts 文件。本质：直播 = 不停下载小视频六、为什么 HLS 兼容性无敌？因为它本质就是 HTTP。而互联网最擅长 HTTP：所有 CDN 天然支持所有浏览器天然支持（Safari 直接支持，其他通过播放器支持）所以现在很多直播平台的架构：RTMP推流 → 服务器 → 转HLS → 用户播放七、为什么 HLS 延迟高？因为切片。例如每个 TS 2秒，播放器可能缓存3片：2秒 × 3 = 6秒再加上网络、CDN、缓冲，最终 10秒+ 非常正常。很多大型赛事甚至 20~30秒 延迟。八、什么是 LL-HLS？苹果发现 HLS 太慢，于是推出 Low Latency HLS。核心：把 2秒切片 变成 200ms 小分片。延迟从 10秒+ 降到 2秒左右。但仍然打不过 WebRTC。九、WebRTC 是什么？全称：Web Real-Time Communication，Google 主导。目标：浏览器直接实时音视频。典型场景：腾讯会议ZoomGoogle Meet飞书会议在线教育连麦直播十、WebRTC 为什么这么快？核心：不用等。RTMP：缓存HLS：切片WebRTC：实时发送延迟 100ms~500ms，很多时候甚至 200ms 左右，已经接近电话。十一、WebRTC 为什么能做到这么低？因为大量黑科技。UDPRTMP：TCPWebRTC：UDPUDP 不重传，丢了直接丢，所以速度极快。十二、WebRTC 里的 NACKUDP 虽然快，但会丢包。于是 WebRTC 增加了 NACK 机制：发现关键包丢失时请求重发，普通包直接忽略。兼顾速度与质量。十三、WebRTC 里的 FECForward Error Correction（前向纠错）。简单理解：提前发送冗余数据。例如发送 ABC 的同时发送校验信息，即使 B 丢了也可能恢复，减少重传。十四、为什么万人直播不用 WebRTC？因为 贵，非常贵。假设主播 8Mbps，10000 观众，服务器需要 80Gbps 带宽，直接爆炸。而且 WebRTC 连接是长连接，CPU 压力巨大。十五、为什么 HLS 适合万人直播？因为 CDN。主播 8Mbps，服务器只上传一次，之后 CDN 缓存，全国节点分发。即使 100万 观众也能扛。十六、直播平台真实架构很多新人以为抖音 = WebRTC，实际上根本不是。典型架构：主播 ↓ RTMP / WebRTC ↓ 接入层 ↓ 转码集群 ↓ CDN ↓ HLS / FLV ↓ 普通观众连麦用户：WebRTC普通观众：HLS / FLV这才是现实。十七、三大协议对比项目RTMPHLSWebRTC延迟1~3秒5~30秒100~500ms底层TCPHTTPUDPCDN友好一般极强较差浏览器支持差极强极强实时互动一般很差最强万人直播一般最强很差视频会议不适合不适合最适合十八、面试高频题Q1：RTMP 为什么逐渐退出播放端？答：Flash 死亡，浏览器不支持。Q2：为什么 HLS 延迟高？答：切片、缓存、CDN 导致。Q3：为什么 WebRTC 低延迟？答：UDP、实时传输、不依赖切片。Q4：为什么万人直播不用 WebRTC？答：带宽成本高，连接数压力大。Q5：直播平台为什么同时支持多个协议？答：不同用户需求不同：互动用户 → WebRTC普通观众 → HLS / FLV十九、一张图看懂三大协议 延迟 WebRTC │ 0.2s │ 0.5s │ 1s │ RTMP │ 3s │ 5s │ HLS │ 30s ▼ 实时性降低📌 总结如果只记一句话：没有最好的直播协议，只有最适合业务的协议。现实项目里：视频会议 = WebRTC万人直播 = HLS + CDN主播推流 = RTMP所以面试官问“RTMP、HLS、WebRTC 怎么选？” 不要回答“WebRTC 最好”，而应该回答：根据业务场景选择：实时互动优先 WebRTC，大规模分发优先 HLS，推流侧仍以 RTMP 为主。这才是真正的工程答案。🔮 下一篇预告《视频流从入门到放弃（第四篇）：FFmpeg 是什么？为什么所有流媒体项目都绕不开它？》下一篇开始进入实战工具：FFmpeg 到底是什么ffmpeg 命令为什么像天书转码到底在干什么MP4 转 HLS 的全过程CPU 转码 vs GPU 转码为什么一台转码服务器一天烧掉几百块电费这一篇看完，你就能正式开始玩流媒体了。👍 觉得有用？欢迎点赞、收藏、转发，让更多人一起入门视频流！
视频流从入门到放弃（第一篇）：视频流到底是什么？为什么总卡？
🎬 视频流从入门到放弃（第一篇）：视频流到底是什么？为什么总卡？关键词：直播 · 点播 · RTMP · HLS · WebRTC · 转码 · CDN · 拉流 · 推流 · 视频卡顿📖 前言前几天朋友问我：“不就是播放个视频吗？为什么搞直播的公司要养那么多后端？”我当时愣了一下。仔细想想，好像很多后端程序员都写过： 然后觉得：视频播放，不就结束了吗？直到真正接触直播系统、短视频系统、语音房、赛事直播后才发现：一个看似简单的视频播放，背后可能经过了：📷 摄像头采集 → 🔧 视频编码 → 📤 推流 → 🔄 转码 → 🌍 CDN分发 → 📥 拉流 → 💻 解码 → ▶️ 播放几十个环节。任何一个环节出问题，用户看到的可能就是：❌ “卡了。” ❌ “黑屏了。” ❌ “怎么声音和画面对不上？”今天我们不聊代码。 先搞懂最核心的问题：🤔 视频流到底是什么？一、什么是视频流？很多人以为：视频 = 文件，比如 movie.mp4。但实际上，视频的本质是：一张张连续播放的图片 + 声音数据比如：1秒钟30张图片 Frame1 → Frame2 → Frame3 → ... → Frame30当它们以 30 FPS 的速度快速播放，人眼就会认为：它在动。这就是视频。二、为什么视频文件那么大？我们来算一笔账：参数数值分辨率1920 × 1080颜色深度24位 (RGB)单帧大小1920 × 1080 × 3 ≈ 6 MB30帧/秒180 MB/s1分钟10 GB+😱 吓人吧？如果不压缩，一部电影几百GB，根本传不动。 所以，视频行业的第一件事就是：压缩。三、什么是编码（Codec）？编码器的作用很简单：原始视频 → [压缩] → 可传输视频常见的编码标准有：✅ H264最经典，几乎所有设备支持优点：兼容性极强缺点：压缩率一般✅ H265同样画质，体积减少 30%~50%优点：省带宽缺点：部分设备支持一般✅ AV1新一代编码，压缩率更高缺点：编码非常耗CPU，很多平台仍在普及中四、什么是码率（Bitrate）？这是面试最爱问的问题。很多人以为：1080P 就一定清晰 ❌ 真正决定清晰度的是：码率举个例子视频分辨率码率A1080P500 kbpsB720P4000 kbps在很多情况下：B 比 A 清晰。码率的本质：每秒传输多少数据。 例如 4 Mbps 表示每秒传输4兆比特。五、什么是推流？直播开始时，主播手机的工作流程：摄像头 → 编码 → 上传上传到服务器的过程就叫 推流（Push）。比如用 OBS 推到：rtmp://live.xxx.com/live/10001服务器开始接收视频数据。六、什么是拉流？用户观看直播时，从服务器获取视频流的过程叫 拉流（Pull）。完整的流程：主播 → [推流] → 流媒体服务器 → [拉流] → 观众七、为什么视频会卡？这是最重要的问题。很多人第一反应是“服务器垃圾”，其实不一定。🔴 原因1：网络带宽不够视频码率：4 Mbps用户网速：2 Mbps结果：下载速度 < 播放速度，缓冲区耗尽 → 卡顿🔴 原因2：丢包发送100个包，收到95个，丢了5个直播对丢包尤其敏感🔴 原因3：服务器带宽打满10000人观看，每人4 Mbps总带宽：40 Gbps普通服务器直接爆炸 → 必须上CDN🔴 原因4：客户端解码跟不上尤其是4K、60FPS、H265老手机CPU直接冒烟 → 掉帧🔴 原因5：关键帧太少编码器使用 I帧、P帧、B帧如果关键帧间隔太长，丢包后恢复极慢 → 画面卡住八、直播和点播有什么区别？很多新人容易混淆。🎬 点播（VOD）例子：爱奇艺、腾讯视频、优酷本质：视频已存在，用户直接读取文件特点：允许缓冲、快进、暂停，延迟不重要📡 直播（Live）例子：游戏直播、体育赛事、视频会议特点：边生产边观看要求：低延迟九、RTMP、HLS、WebRTC 到底是什么？这是面试高频题。协议延迟优点适用场景RTMP1~3秒延迟低推流常用HLS5~30秒兼容性强苹果生态、点播WebRTC100~500ms实时音视频王者视频会议、在线教育、连麦Zoom、Google Meet 的核心底层就是 WebRTC。十、一张图看懂视频流┌──────────┐ │ 📷 摄像头采集 │ └────┬─────┘ │ ▼ ┌──────────┐ │ 🔧 H264编码 │ └────┬─────┘ │ ▼ ┌──────────┐ │ 📤 RTMP推流 │ └────┬─────┘ │ ▼ ┌──────────────┐ │ 🖥️ 流媒体服务器 │ └────┬─────────┘ │ ▼ ┌──────────────┐ │ 🔄 转码(H264/H265)│ └────┬─────────┘ │ ▼ ┌──────────┐ │ 🌍 CDN分发 │ └────┬─────┘ │ ▼ ┌──────────┐ │ 📥 用户拉流 │ └────┬─────┘ │ ▼ ┌──────────┐ │ 💻 解码播放 │ └──────────┘📌 总结如果只记住一句话：视频流本质上就是“持续产生并持续传输的视频数据”。而视频为什么会卡，通常逃不开这几点：⚠️ 网络带宽不足⚠️ 网络丢包⚠️ 服务器带宽瓶颈⚠️ 转码性能不足⚠️ 客户端解码能力不足⚠️ CDN分发异常理解了这些基础概念，后面再学：FFmpegSRS / ZLMediaKitNginx-RTMPWebRTCCDN直播架构设计就不会一上来就被各种名词砸晕了。🔮 下一篇预告《视频流从入门到放弃（第二篇）：H264 到底是怎么把 10GB 视频压成 100MB 的？》我们将彻底讲透：I帧、P帧、B帧GOP关键帧运动估计为什么H264能压缩几十倍为什么转码服务器那么烧CPU这一篇开始，正式进入流媒体核心世界。👍 觉得有用？欢迎点赞、收藏、转发，让更多人一起入门视频流！