封装 H.264 视频为 FLV 格式并通过 RTMP 推流
flyfish
协议
RTMP (Real-Time Messaging Protocol)
RTSP (Real Time Streaming Protocol)
SRT (Secure Reliable Transport)
WebRTC
RTMP（Real Time Messaging Protocol）是一种用于实时音视频流传输的协议。它由Adobe公司开发，主要用于将音视频数据从客户端（如摄像头、编码器）推送到服务器（如流媒体服务器），再由服务器分发给众多观众。
封装格式：MP4、RMVB、FLV、AVI等
编码标准：H.264、MPEG-2等
视频像素数据：YUV420P、RGB、ARGB等
SPS和PPS
SPS (Sequence Parameter Set) - 序列参数集：
SPS包含了编码视频序列的全局参数，如图像尺寸、帧率、编码配置信息（如profile和level）、颜色空间信息等。这些参数在视频序列开始时发送，并在整个序列中保持不变，除非出现新的SPS。解码器需要这些信息来正确初始化解码过程。
PPS (Picture Parameter Set) - 图像参数集：
PPS提供了与单个图像或帧相关的参数，比如熵编码模式、去块滤波器参数等。每个PPS对应一个或多个图像，并跟随在SPS之后发送。与SPS一样，PPS在视频流中也是相对静态的，但在序列中可以改变。
封装 H.264 视频为 FLV 格式并通过 RTMP 推流步骤
1 提取 SPS 和 PPS
在处理 H.264 视频流之前，首先需要从视频数据中提取 SPS 和 PPS。这些参数通常在 H.264 数据流中的 IDR 帧（关键帧）中，可以通过解析 NAL 单元来获取。
2 封装 SPS 和 PPS 到 FLV
将提取到的 SPS 和 PPS 封装到 FLV 封装格式中。
创建一个FLV视频标签，设置其类型为视频（tag type = 9）。
将SPS和PPS组合成一个NAL单元，并在前面加上NALU头（通常是一个起始码，如0x00000001）。
将此NAL单元作为第一个视频标签的数据部分，设置适当的时间戳和帧类型标识。
3 发送
SPS 和 PPS 到 RTMP 服务器
一般情况下，在 RTMP 推流开始之前，需要先发送 SPS 和 PPS 数据给 RTMP 服务器，以告知接收端解码器关于视频流的信息。
对于每一个H.264视频帧，创建一个新的FLV视频标签。
每个视频帧也需要带有NALU头，并根据帧类型（如I帧、P帧、B帧）设置相应的帧类型标识。
设置正确的时间戳，确保视频播放的同步。
在RTMP协议中，视频数据（包括SPS、PPS、IDR帧、P帧、B帧等）被封装在FLV格式的视频标签（Video Tag）里。每个视频标签开始会有一个Header，描述了该标签的类型、数据长度和时间戳等信息，紧随其后的是实际的视频数据。这些视频数据单元（NALUs）是H.264编码的原始二进制数据
Frame
IDR (Instantaneous Decoding Refresh) 帧：
IDR帧是一种特殊的I帧，用于实现解码器的即时刷新。当解码器遇到IDR帧时，它会丢弃之前的所有参考帧，从IDR帧开始重新构建参考图像序列。IDR帧是解码独立的，确保了在IDR之后的视频帧不会引用IDR之前的任何帧，有利于错误恢复和随机访问。
I帧 (Intra-coded Frame)：
I帧是帧内编码帧，包含了完整画面的所有信息，可以独立解码，不需要参考其他帧。它是视频序列中的关键帧，通常用于场景切换或作为错误恢复点。
P帧 (Predictive-coded Frame)：
P帧是预测编码帧，它只存储相对于前一个已解码帧（通常是I帧或P帧）的变化信息。解码P帧时需要参考之前的帧，因此它依赖于过去的信息，能够实现较高的压缩效率。
B帧 (Bi-directional Predictive-coded Frame)：
B帧是双向预测编码帧，它利用前后两个已解码帧（可以是I帧、P帧或B帧）的信息进行预测，能够提供更高的压缩率。B帧的解码需要依据其前后帧，因此在编码顺序和解码顺序上可能有所不同，增加了编解码的复杂性，但提高了压缩效率。
GOP
GOP是一组连续的画面，始于一个I帧（关键帧），结束于下一个I帧之前，中间包含P帧（预测帧）和B帧（双向预测帧）。I帧是完整图像，可以独立解码
Slice
frame是视频中完整的图像单元，而slice是帧内进一步的逻辑分块
Slice是视频编码中对一帧图像进行逻辑划分的单元。在H.264/H.265编码中，为了提高编码效率和容错能力，一帧图像可以被分割成一个或多个slice。
每个slice包含了一组连续的宏块（Macroblocks），这些宏块可以独立进行解码，而不必等待整个帧的数据到达。这样的设计使得即使在网络不稳定或数据包丢失的情况下，也能减少错误传播的范围，因为一个slice的损坏不会影响到其他slice的解码。
Slice可以是不同的类型，比如I-slice（只包含I宏块的slice）、P-slice（包含P宏块的slice）或B-slice（包含B宏块的slice），并且可以在编码时根据需要灵活配置。
Slice的边界不一定遵循图像内容的自然边界，而是根据编码策略和网络传输需求来确定。
Access Unit Delimiter (AUD) 的作用
分隔符功能：AUD作为NAL单元（Network Abstraction Layer Unit）的一种类型，其nal_unit_type值为9，它的主要目的是作为一个标识符，用来标记一个访问单元（Access Unit, AU）的开始。一个访问单元通常包含构成一个完整解码图像所需的所有NAL单元，比如一个I帧、P帧或者B帧及其相关的补充信息（如SPS、PPS等）。在复杂场景下，一个视频帧可能被编码为多个NAL单元（slice），AUD帮助解码器识别这些NAL单元属于同一个图像帧。
同步点：AUD为解码器提供了同步点，特别是在数据流可能存在错误或需要随机访问的情况下，解码器能够通过AUD快速定位到下一个完整图像的起始位置，这对于实现快速 seek、错误恢复以及同步播放控制等操作至关重要。
辅助解码：虽然AUD不是解码过程中的必需部分（即缺少AUD，解码器依然可以根据其他NAL单元类型解码视频），但它简化了解码器的设计，因为它允许解码器无须复杂的解析逻辑就能区分不同图像帧的边界，尤其是在处理包含多个slice的帧时。
兼容性和标准化：在FLV封装格式中加入AUD，有助于保持与H.264标准的兼容性，确保视频内容可以在遵循标准的解码器上正确播放，同时也便于视频流在不同系统间交换和回放。
FLV Header
| Field | Type | Comment |
|---|---|---|
| Signature | 1 byte | 必须为’F’(0x46) |
| Signature | 1 byte | 必须为’L’(0x4C) |
| Signature | 1 byte | 必须为’V’(0x56) |
| (版本)Version | 1 byte | 通常为0x01 |
| TypeFlagsReserved | 5 bits | 必须为0 |
| TypeFlagsAudio | 1 bit | 表示是否含有音频 |
| TypeFlagsReserved | 1 bit | 必须为0 |
| TypeFlagsVideo | 1 bit | 表示是否含有视频 |
| DataOffset | 4 bytes | 文件头部的大小(从文件开始位置到body的偏移量),通常为9 |
| Field | Type | Comment |
|---|---|---|
| PreviousTagSize0 | 4 bytes | 总是0 |
| Tag1 | FLVTAG结构 | 第一个tag |
| PreviousTagSize0 | 4 bytes | 上一个tag的大小，包含了tag的头部。对FLV版本1来讲，它的值等于上一个tag的数据大小+11 |
| Tag2 | FLVTAG结构 | 第二个tag |
| … | … | … |
| PreviousTagSizeN - 1 | 4 bytes | 倒数第二个tag的大小 |
| TagN | FLVTAG结构 | 最后一个tag |
| PreviousTagSizeN | 4 bytes | 最后一个tag的大小 |
| Field | Type | Comment |
|---|---|---|
| Tag类型(TagType) | 1 bytes | 8：音频、9：视频、18：script数据 |
| 数据大小(DataSize) | 3 bytes | 数据字段的长度 |
| 时间戳(Timestamp) | 3 bytes | 毫秒为单位，第一个tag时，该值总是0 |
| 时间戳扩展(TimeStampExtended) | 1 bytes | 时间戳扩展为4bytes,代表高8位，很少用到 |
| 流ID | 3bytes | 总是0 |
| 数据(Data) | 音频、视频或script | 数据实体 |
