RTMP视频流的帧格式分析

RTMPReal-Time Messaging Protocol是基于 TCP 的协议其底层传输的数据实际上封装了 FLVFlash Video格式的 Tag。在 RTMP 流中数据被切分成一个个 Chunk块进行发送。为了让你深入理解我将模拟抓取一个真实场景一个主播正在推流内容包含一段 H.264 视频和 AAC 音频。以下是详细的分析1. RTMP Chunk Header包头分析无论音频还是视频数据包的最外层都是 RTMP Chunk Header。假设数据(Hex):03 00 00 00 00 00 04 05 00 00 00详细解析:03:Format (2 bit) Chunk Stream ID (6 bit)。Format0表示这是一个完整的 Chunk Header包含时间戳、长度、类型等全部信息。CSID3表示块流 ID 为 3。00 00 00:Timestamp (3 bytes)。时间戳为 0通常是流的第一个包。00 00 04:Message Length (3 bytes)。消息体长度为 4 字节这是一个极小的包通常用于发送握手后的配置信息。05:Message Type ID (1 byte)。类型为 5表示Audio Data如果是 9 则是 Video Data。00 00 00:Stream ID (4 bytes)。流 ID 为 0。2. 音频包详细分析AAC 音频在 RTMP 中有两种主要的包类型AAC Sequence Header配置信息和AAC Raw Data声音数据。示例场景发送 AAC 配置信息这是推流开始后发送的第一个音频包解码器需要它来知道采样率、声道数等。假设 Payload 数据(Hex):AF 00 11 90 56 E5(注意不包含上面的 Chunk Header这里是 Tag Body 的内容)详细格式解析:AF:Sound Format Info (1 byte)高 4 位1010(10):Sound Format AAC。高 3-2 位11(3):Sample Rate 44 kHz。高 1 位1(1):Sample Size 16-bit。高 0 位1(1):Sound Type Stereo (立体声)。总结: 44100Hz, 16位, 立体声 AAC。00:AAC Packet Type (1 byte)00AAC Sequence Header(AudioSpecificConfig)。01 AAC Raw Data (真正的音频帧)。分析: 这里00说明这是配置包告诉播放器如何初始化解码器。11 90 56 E5:AudioSpecificConfig Data (4 bytes)这是 AAC 的 ADTSAudio Data Transport Stream头部信息去掉同步字后的紧凑格式。通常包含 Profile (如 LC)、Sampling Frequency Index、Channel Configuration 等信息。播放器会将这部分数据提取出来构建解码器上下文。示例场景发送真实的音频帧假设 Payload 数据:AF 01 [后面跟随一长串 AAC 压缩数据]AF: 同上音频格式信息。01:AAC Packet Type 1。表示后面的数据是裸的 AAC ES (Elementary Stream) 数据不包含 ADTS 头因为 RTMP/FLV 已经在配置包里定义了格式这里为了节省带宽不再重复发送头部。3. 视频包详细分析H.264 视频在 RTMP 中也分两种AVC Sequence Header(SPS/PPS) 和AVC NALU(I帧/P帧/B帧)。示例场景发送 AVC 配置信息 (SPS/PPS)这是推流的第一个视频包没有画面只有元数据。假设 Payload 数据(Hex):17 00 00 00 00 01 67 42 ...(注为了演示清晰简化了数据长度)详细格式解析:17:Frame Type Codec ID (1 byte)高 4 位0001(1):Frame Type Keyframe (IDR 帧)。1: Keyframe (I帧)2: Inter frame (P帧/B帧)3: Disposable inter frame…低 4 位0111(7):Codec ID AVC。7 H.264 (AVC)12 H.265 (HEVC)含义: 这是一个关键帧的配置包。00:AVCPacket Type (1 byte)00AVC Sequence Header。01 AVC NALU unit。分析: 这里00表示这是包含 SPS 和 PPS 的配置包。00 00 00:Composition Time (3 bytes)仅在 Packet Type 为 1 时有意义。这里因为是 Header通常为 0。01 ...:DecoderConfigurationRecord Data这里存储的是 ISO BMFF 格式的 AVCDecoderConfigurationRecord。它包含ConfigurationVersion、AVCProfileIndication、ProfileCompatibility、AVCLevelIndication、LengthSizeMinusOne通常为 3表示 NALU 长度用 4 字节表示。紧接着是SPS (Sequence Parameter Set)和PPS (Picture Parameter Set)的数据。示例场景发送关键帧数据 (I-Frame)假设 Payload 数据:17 01 00 00 1D 00 00 00 01 67 42 ...(注实际长度字段取决于配置)详细格式解析:17:Frame Type Keyframe (1),Codec ID AVC (7)。01:AVCPacket Type AVC NALU (1)。表示这是真正的视频画面数据。00 00 1D:Composition Time (3 bytes)。表示解码时间戳与显示时间戳之间的偏移量 (PTS - DTS)。假设值为 29ms0x001D意味着这个帧应该比解码时间晚 29ms 显示B帧常用但在纯 I/P 帧流中通常为 0。00 00 00 01:NALU Start Code (4 bytes)(虽然 FLV 通常使用 Length 字段但在分析底层 H.264 码流时常见 Start Code但在 RTMP Tag Body 内部通常是 [长度][数据] 的结构)。修正在 FLV 结构中这里应该是NALU Length。如果 LengthSizeMinusOne3这里就是 4 字节长度。假设 Length 00 00 00 1C(28 字节)。67 ...:NALU Data。67(十进制 103) 代表 NALU 类型为 SPS (非关键 IDR)。但这里如果是 I 帧通常会包含 SPS/PPS如果 IDR 周期性插入配置或者类型65(IDR slice)。实际数据结构示例循环[4 Bytes: Length] [1 Byte: NALU Header] [N Bytes: Payload][4 Bytes: Length] [1 Byte: NALU Header] [N Bytes: Payload]4. 总结对比表字段位置音频包 (AAC)视频包第一个字节AF(Sound FormatAAC, 44k, Stereo, 16bit)17(Frame TypeKeyframe, CodecAVC)第二个字节00(Seq Header) 或01(Raw Data)00(Seq Header) 或01(NALU)后续字节AAC AudioSpecificConfig 或 Raw ES Data3字节 CompTime DecoderRecord 或 NALU Units核心点记忆配置包 是必须先发送的包含了解码必需的表头信息。音频 AAC00类型是头01类型是去掉 ADTS头的裸流。视频 AVC00类型是 SPS/PPS 头01类型是 NALU 单元。Composition Time只在视频01类型中有意义用于音画同步中的补正。希望这个详细的数据包分析能帮你理解 RTMP 流的内部结构