封装 H.264 视频为 FLV 格式然后推流

封装 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

FLV Body

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的大小

FLV 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	数据实体