教程技术博客文档【免费下载链接】YCBlogs技术博客笔记大汇总包括Java基础线程并发数据结构Android技术博客等等常用设计模式常见的算法网络协议知识点部分flutter笔记还包括平时开发中遇到的bug汇总当然也在工作之余收集了大量的面试题长期更新维护并且修正持续完善……开源的文件是markdown格式的转载请注明出处谢谢项目地址https://gitcode.com/gh_mirrors/yc/YCBlogs点击查看免费下载本篇技术指南以仓库文档 net/16.看直播流程.md 为主体围绕视频到底是怎么从主播摄像头一路传到观众屏幕这一核心问题系统梳理视频编码、NALU 封装、RTMP 推流/拉流、流媒体分发与解码播放的完整链路。读完你将掌握视频压缩的原理与帧类型、H.264 码流结构、RTMP 握手与 Chunk 分块机制以及流媒体 CDN 的部署形态能看懂直播场景下的网络协议设计与常见性能问题。01. 三个名词系列先给视频技术定个位无论是直播还是点播本质都是对视频数据的传输。视频人人都爱看但视频技术里的名词实在太多这里先列出三个名词系列建立整体印象名词系列一文件格式AVI、MPEG、RMVB、MP4、MOV、FLV、WebM、WMV、ASF、MKV。其中 RMVB、MP4 最常见——这是视频装在什么文件里即封装容器格式。名词系列二编码标准H.261、H.262、H.263、H.264、H.265。这一系列普通人很少听说但它是视频压缩的核心要重点关注 H.264。名词系列三MPEG 家族MPEG-1、MPEG-2、MPEG-4、MPEG-7。MPEG 好像听说过但后面的数字代表什么又熟悉又陌生。先回答一个基础问题视频是什么其实就是快速播放一连串连续的图片。每一张图片称为一帧Frame。只要每秒钟帧数足够多、播放足够快比如每秒 30 帧人眼就分辨不出这是独立图片——这就是帧率FPSFrames Per Second。每一帧由像素组成假设分辨率为 1024×768这个像素数不算多每个像素由 RGB 三色组成每种颜色 8 位共 24 位。来算一笔账看每秒钟的视频有多大每秒数据量 30 帧 × 1024 × 768 × 24 bit 566,231,040 bit 70,778,880 Byte ≈ 67.5 MB/s如果是一分钟呢约 4,246,732,800 Bytes已经接近 4 个 GB。这个数据量完全无法存储和传输——硬盘很快会满带宽也远远不够用。解决办法就是编码用尽量少的 bit 保存视频同时保证播放时画面仍然精美。编码本质是一个压缩过程。这条数据量爆炸 → 必须压缩的推导逻辑也是理解后续所有直播技术的前提。02. 视频和图片为什么能压缩四大冗余特性之所以能对视频流中的图片进行压缩是因为视频和图片天然存在以下特点冗余类型含义压缩思路空间冗余图像相邻像素之间有较强相关性相邻像素往往是渐变的而非突变的没必要每个像素都完整保存可以隔几个保存一个中间的用算法计算出来时间冗余视频序列的相邻图像之间内容相似连续图片不是突变的可以根据已有图片进行预测和推断只记录变化部分视觉冗余人的视觉系统对某些细节不敏感允许丢失一部分人眼不易察觉的数据编码冗余不同像素值出现的概率不同概率高的用较少字节、概率低的用较多字节类似霍夫曼编码Huffman Coding的思路编码算法非常复杂且多种多样但所有编码过程本质相似先利用空间冗余压缩单帧内的数据再利用时间冗余压缩帧与帧之间的数据最后通过熵编码如 Huffman、CABAC压缩符号本身的表示。围绕这些原理仓库中 net/01.请求网络过程梳理.md 从应用层、传输层到网络层逐层描述了数据包在互联网上的完整旅程而直播视频的压缩数据也要经历同样的分层封装与传输。03. 视频编码的两大流派ITU 与 MPEG 的统一编码标准不能各搞一套否则开发视频播放的人会累死。视频编码有两大流派流派一ITUInternational Telecommunications Union国际电信联盟的 VCEGVideo Coding Experts Group。既然是电信组织最初做视频编码主要侧重传输。名词系列二H.26x 系列就是这个组织制定的标准。流派二ISOInternational Standards Organization的 MPEGMoving Picture Experts Group。ISO 旗下 MPEG 原本主要做视频存储比如编码后保存在 VCD、DVD 中后来也慢慢侧重视频传输。名词系列三MPEG 系列就是这个组织制定的标准。后来ITU-T国际电信联盟电信标准化部门与 MPEG 联合制定了 H.264 / MPEG-4 AVC这是直播场景中最需要重点关注的编码标准。经过编码之后生动活泼的一帧帧图像就变成了一串串看不懂的二进制。这个二进制可以放进一个文件里按照一定格式保存起来——这就是名词系列一封装格式。所谓封装格式就是规定前几个字节是什么含义、后几个字节是什么含义数据部分存放编码结果的容器规范。04. 如何看直播视频推流、接流、转码、拉流与分发编码好的二进制不仅存在文件里也可以通过某种网络协议封装后放在互联网上传输这时候就可以进行网络直播了。整个直播体系包含以下几个环节推流Publish网络协议把编码好的视频流从主播端推送到服务器。接流接收服务器上运行着相同协议的服务端接收这些网络包从中取出视频流这个过程称为接流。转码Transcode服务端对视频流进行一定处理例如从一个编码格式转成另一种格式。因为观众的客户端千差万别转码可以保证所有观众都能看到直播。拉流Play流处理完毕后等待观众的客户端来请求视频流观众客户端请求的过程称为拉流。分发Distribution如果有大量观众同时观看一个直播都从同一台服务器拉流压力太大因此需要一个视频分发网络把视频预先加载到就近的边缘节点大部分观众从边缘节点拉取视频降低源站服务器压力。解码播放Decode Play观众客户端将视频流拉下来后需要解码——即编码过程的逆过程把二进制重新转变成一帧帧图片在客户端播放出来。分发网络的具体形态在仓库文档 net/14.CDN是什么东西.md 中有详细展开CDN 系统分为边缘节点、区域节点、中心节点多层缓存用户就近访问不命中再逐级向上回源如同电商的分布式仓储体系。05. 编码过程详解I 帧、P 帧、B 帧与 NALU 结构5.1 视频序列的三种帧如果每张图片都完整编码数据量依然巨大因此会将视频序列分成三种帧I 帧Intra-coded frame关键帧包含完整的图片只需本帧数据即可完成解码。P 帧Predictive frame前向预测编码帧表示这一帧与之前一个关键帧或 P 帧的差别。解码时需要把之前缓存的画面叠加本帧定义的差别生成最终画面。B 帧Bi-directional frame双向预测内插编码帧记录本帧与前后帧的差别。解码 B 帧不仅要取得之前的缓存画面还要解码之后的画面通过前后画面数据与本帧数据叠加得到最终画面。可以看出I 帧最完整B 帧压缩率最高。压缩后帧的序列通常按照 IBBP 的间隔出现这就是时序编码的基本思想。5.2 一帧的空间划分片、宏块、子块在一帧中画面被分成多个片Slice每个片又分成多个宏块Macroblock每个宏块再分成多个子块Sub-block。这样把一张大图分解成一个个小块方便进行空间上的编码——块与块之间可以独立或参考预测配合空间冗余特性实现压缩。5.3 NALU为网络传输而生的码流结构尽管时空非常立体地组成了一个序列最终还是要压缩成一个二进制流。这个流是有结构的由一个个NALUNetwork Abstraction Layer Unit网络提取层单元组成。设计成这种格式就是为了传输——网络上默认传输的是一包包数据因此码流也分成一个个单元。每个 NALU 的结构为| 起始标识符Start Code | NALU 头Header | Payload数据 |起始标识符标识 NALU 之间的间隔NALU 头主要配置 NALU 的类型Payload承载 NALU 的实际数据。在 NALU 头中最核心的内容是类型NAL Type常见的两种类型是NAL Type名称含义0x07SPSSequence Parameter Set序列参数集包含一个图像序列的所有信息如图像尺寸、视频格式等0x08PPSPicture Parameter Set图像参数集包含一个图像的所有分片的相关信息如图像类型、序列号等在传输视频流之前必须先传输这两类参数否则无法解码。为了保证容错性每一个 I 帧前面都会重新传一遍这两个参数集合。如果 NALU Header 中的类型是 SPS 或 PPS则 Payload 中存放的是真正的参数集内容如果类型是帧则 Payload 中存放的是真正的视频数据一帧一帧存放。由于一帧内容较多每个 NALU 保存的是一个片Slice。对于每一片到底是 I 帧、P 帧还是 B 帧在片结构里也有一个 Header里面有类型后面跟着片的内容。这样整个码流格式就出来了一个视频 → 拆分成一系列帧 → 每帧拆分成一系列片 → 每片放在一个 NALU 中 → NALU 之间通过特殊起始标识符分隔 →在每一个 I 帧的第一片前面插入单独保存 SPS 和 PPS 的 NALU最终形成一个长长的 NALU 序列。06. 推流如何把数据流打包传输到对端RTMP 协议有了 NALU 码流是否就能直接在网上传输开始直播了还不行。还需要把这个二进制流打包成网络包进行发送这里使用RTMPReal-Time Messaging Protocol协议这就是第二个过程——推流。6.1 建立连接TCP 连接 RTMP 连接RTMP 基于 TCP因此首先要建立 TCP 连接。关于 TCP 的可靠性机制可参见仓库文档 net/06.TCP详细基础介绍.md三次握手建立连接、序列号解决乱序、ACK 确认保证不丢包、滑动窗口做流量控制。在 TCP 连接的基础上还需要建立一个 RTMP 连接——在程序里调用 RTMP 类库的Connect函数显式创建连接。RTMP 之所以需要单独的连接是因为双方要商量两件事版本号如果客户端、服务器版本号不一致则不能工作时间戳视频播放中时间非常重要后续数据流互通时常要携带时间戳差值因此一开始双方就要知道对方的时间戳。为沟通这些事情需要发送六条消息客户端发送C0、C1、C2服务器发送S0、S1、S2。握手过程如下客户端发送 C0 表示自己的版本号不必等待对方回复然后发送 C1 表示自己的时间戳服务器收到 C0 后才返回 S0 表明自己的版本号如果版本不匹配可以断开连接服务器发送完 S0 后不必等待直接发送自己的时间戳 S1客户端收到 S1 后发送确认对方时间戳的 ACKC2服务器收到 C1 后发送确认对方时间戳的 ACKS2握手完成。客户端 服务器 |--- C0 (版本号) -------------------| |--- C1 (时间戳) -------------------| |-- S0 (版本号) --------------------| |-- S1 (时间戳) --------------------| |--- C2 (确认S1时间戳) -------------| |-- S2 (确认C1时间戳) --------------|握手之后双方互相传递一些控制信息例如Chunk 块大小、窗口大小等。真正传输数据时还需要创建一个流Stream然后通过这个 Stream 来推流publish。6.2 RTMP 消息封装NALU → Message → Chunk推流过程就是把 NALU 放在Message里发送这个 Message 也称RTMP Packet 包。发送时需要注意去掉 NALU 的起始标识符因为这部分对 RTMP 协议没有用将SPS 和 PPS 参数集封装成一个 RTMP 包先行发送然后再发送一个个片的 NALU。关键机制在于RTMP 收发数据并不是以 Message 为单位的而是把 Message 拆分成 Chunk 发送而且必须在一个 Chunk 发送完成之后才能开始发送下一个 Chunk。每个 Chunk 都带有Message ID表示它属于哪个 Message接收端按照这个 ID 将 Chunk 组装成 Message。前面连接时设置的Chunk 块大小就是指这个 Chunk。将大消息拆成小块再发送可以在低带宽情况下减少网络拥塞。下面是一个具体分块例子假设一个视频消息的长度为 307Chunk 大小约定为 128于是拆分为三个 ChunkChunkType说明承载数据第 1 个Type0Chunk 头完整Timestamp1000Length307消息类型9视频Stream ID12346128 字节 Data第 2 个Type3头和第一个一样不再重复发送头128 字节 Data第 3 个Type3剩余长度 307 − 128 − 128 51 字节51 字节 DataMessage: 总长 307 字节, 类型 9 (视频), Stream ID 12346, Timestamp 1000 Chunk1 [Type0, 完整头] ---------- 128 字节 Chunk2 [Type3, 复用头] ---------- 128 字节 Chunk3 [Type3, 复用头] ---------- 51 字节其中Chunk Type0 表示 Chunk 头完整Chunk Type3 表示头部与上一个 Chunk 一样不再重复发送从而节省开销。就这样数据源源不断地到达流媒体服务器。6.3 大规模分发中心层 边缘层当大量观众通过 RTMP 协议从流媒体服务器拉流时如果都去同一个地方拉取服务器压力会很大而且用户分布在全国甚至全球都去统一地点下载时延也会很长因此必须引入分发网络边缘层部署在全国各地、横跨各大运营商与用户距离很近中心层流媒体服务集群负责内容转发也负责转码服务例如把 RTMP 协议的码流转换为 HLS 码流智能负载均衡系统根据用户地理位置信息就近选择边缘服务器为用户提供推流/拉流服务。这一分发架构与 net/14.CDN是什么东西.md 中描述的 CDN 分层缓存体系一致边缘节点无法命中时向区域节点、中心节点逐级回源。该文档还特别指出流媒体数据量大、回源压力大因此多采用主动推送模式把热点数据提前推到边缘节点而非静态页面的未命中再拉取模式同时流媒体 CDN 常提供预处理服务如转码成不同码流、对视频分片让用户按带宽选择超清、标清、流畅等清晰度。6.4 关于直播实时性的延伸为什么很多直播用 UDP 自研协议仓库文档 net/07.UDP详细基础介绍.md 对直播场景的协议选择做了重要补充RTMP 基于 TCP而 TCP 的严格顺序传输要求前一个包收到后才能确认下一个。对直播而言老的视频帧丢了其实也就丢了就算重传回来用户也不在意他们要的是新帧如果一直等待就会卡顿所以直播实时性比可靠性更重要宁可丢包也不要卡顿。此外网络不好时 TCP 会主动降低发送速度这对直播是致命的。因此很多直播应用基于 UDP 实现了自己的视频传输协议在应用层做重传与拥塞处理。这解释了为什么大型直播系统在 RTMP/HLS 之外还会大量采用基于 UDP 的私有协议如 QUIC 类方案来保障低时延。07. 拉流观众的客户端如何看到视频接下来看观众的客户端通过 RTMP 拉流的过程客户端通过 RTMP 协议从边缘节点拉取码流先读到的是 H.264 的解码参数即SPS 和 PPS之后持续收到一个个 Chunk接收端按 Message ID 将 Chunk 组装成 Message再还原为 NALU将 NALU 组成的一个个帧交给解码器解码解码出的帧交给播放器播放——一个绚丽多彩的视频画面就出来了。可以看到拉流正是推流的逆过程RTMP 分块传输 → 组装 Message → 提取 NALU → 依赖 SPS/PPS 参数解码 → 按 I/P/B 帧关系还原画面 → 播放。整个过程中CDN 边缘节点承担了绝大部分流量源站与中心层只负责转码与兜底分发。08. 小结一条完整的直播链路回顾全文直播链路可归纳为四个关键环节编码压缩视频名词多但万变不离其宗编码两大流派ITU 与 MPEG最终达成一致通过时间、空间的各种算法压缩数据H.264/MPEG-4 AVC 是直播最核心的编码标准NALU 组织压缩好的数据为了传输组成一系列 NALU按照帧和片依次排列每个 I 帧前携带 SPS/PPS 参数集保证可解码RTMP 打包排列好的 NALU 在网络传输时按 RTMP 包格式包装RTMP 包再拆分成 Chunk 传输Chunk Type3 复用头部以减少开销分发与拉流推送到流媒体集群的视频流经过转码和 CDN 边缘分发客户端通过 RTMP 协议拉取还原为 NALU解码成视频帧进行播放。如果继续深入这个话题建议配套阅读仓库中以下关联文档直播分发依赖的 CDN 体系见 net/14.CDN是什么东西.mdRTMP 底层 TCP 的可靠性、流量控制与拥塞控制见 net/06.TCP详细基础介绍.md直播实时性痛点与基于 UDP 的自研协议背景见 net/07.UDP详细基础介绍.mdHTTP 2.0 多路复用与 QUIC 的演进同样影响直播传输见 net/15.案例看新闻流程.md。赞分享教程技术博客文档【免费下载链接】YCBlogs技术博客笔记大汇总包括Java基础线程并发数据结构Android技术博客等等常用设计模式常见的算法网络协议知识点部分flutter笔记还包括平时开发中遇到的bug汇总当然也在工作之余收集了大量的面试题长期更新维护并且修正持续完善……开源的文件是markdown格式的转载请注明出处谢谢项目地址https://gitcode.com/gh_mirrors/yc/YCBlogs点击查看免费下载相关推荐如何快速上手todo.txt5分钟掌握核心格式规则如何快速上手todo.txt5分钟掌握核心格式规则 todo.txt是一款轻量级的任务管理工具它采用纯文本格式存储任务让你无需依赖复杂软件即可高效管理待办流放之路Build规划终极指南PathOfBuilding三步搞定天赋与伤害计算流放之路Build规划终极指南PathOfBuilding三步搞定天赋与伤害计算 天赋点加了又删、装备取舍全凭感觉是你玩流放之路最磨人的两件事。PathOf桌面应用如何快速实现iOS直播推流RTMP协议与GPUImage滤镜的完整指南如何快速实现iOS直播推流RTMP协议与GPUImage滤镜的完整指南 在移动直播应用开发中实现流畅的视频推流和实时美颜滤镜是提升用户体验的关键。TimLi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考