方案要求
- 标注信息能够随着视频数据一起传输,混合在视频数据中
- 数据在解码前,就可以从视频数据中解析出来
传输协议
目前,主流摄像头的数据都是通过RTSP协议进行协商,然后通过RTP传输数据,使用RTCP进行流控。
应用层:RTSP(负责会话管理、控制播放等)
传输层:RTP(传输音视频流) + RTCP(监控传输质量)
网络层:UDP / TCP(底层传输协议)
RTP over TCP
每个 RTP 数据包前面会加上一个固定的 4 字节前导头 (Interleaved Frame Header),格式如下:
魔术字节 (Magic Byte):固定为 0x24,用于标识 TCP 流中嵌入的 RTP 包。
通道号 (Channel ID):通常有两个通道,一个用于 RTP 数据流(视频/音频数据),另一个用于 RTCP 控制数据。例如,视频的 RTP 数据可能在通道 0,RTCP 控制包可能在通道 1。
长度 (Length):16 位无符号整数,表示后续实际 RTP 数据包的长度(单位为字节)。
RTP协议
RTP数据包由两部分组成,一部分是RTP Heaeder,一部分是RTP body,RTP Header占用最少12个字节,最多72个字节;另一部分是RTP Payload,用来封装实际的数据负载。
RTP Header
参考:手撕RTSP协议系列(12)— RTP包格式
0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NALU
参考:RTP中H264封装NALU格式详细解析
需要注意的是,当 H.264 比特流被封装进 RTP 包时,起始码不会被包含在 RTP 载荷中,RTP负载直接就从NAL Header开始。
RTP 使用其他的机制来标识 NALU 的边界。例如STAP-A、STAP-B、STAP-C、MTAP、FU-A、FU-B。
像使用 STAP - A(Single - Time Aggregation Packet - A)来聚合多个小的 NALU,可以减少头部开销,提高带宽利用率。或者对于大的 NALU 采用 FU - A(Fragmentation Unit - A)进行分片,以适应有限的 MTU。
SEI
参考:SEI补充增强信息(全网最全SEI指南)
SEI(Supplemental Enhancement Information,补充增强信息)是H.264中的一种NAL单元类型,其主要功能是提供对解码过程非必要的额外信息,这些信息可以用来改善或辅助视频的显示、处理或传输,但即使没有这些信息,解码器也能够正确解码视频序列。
通过ffmpeg的BitStream Filter(码流过滤),在不做码流解码的前提下,对已经编码后的SEI做特定的修改。示例命令添加了类型为未注册的用户数据的SEI,其中uuid为"086f3693-b7b3-4f2c-9653-21492feee5b8",payload内容为"hello":
./ffmpeg -I oceans.h264 -c:v copy -bsf:v h264_metadata=sei_user_data='086f3693-b7b3-4f2c-9653-21492feee5b8+hello' oceans.sei.h264