方案要求
- 标注信息能够随着视频数据一起传输，混合在视频数据中
- 数据在解码前，就可以从视频数据中解析出来
传输协议
目前，主流摄像头的数据都是通过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