如何在GStreamer的RTP视频流中保留GstBuffer的buffer_offset

你遇到的buffer_offset丢失问题，本质是H.264编码（x264enc）和RTP打包（rtph264pay）过程中不会默认保留原始帧的buffer_offset属性——编码后的NAL单元与原始帧偏移无强制关联，RTP协议也未将该字段纳入默认payload。下面给你几个可靠的解决方案：

方案1：利用RTP自带的序列号 #

RTP协议每个数据包都有递增的序列号，接收端可通过这个序列号关联到帧级别（一个视频帧可能拆成多个RTP包，帧的最后一个包通常会置marker位）。

实现步骤： #

接收端管道无需修改，直接在rtph264depay的输出pad上挂探针提取RTP元数据：

import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst

Gst.init(None)

frame_counter = 0

def rtp_probe(pad, info):
    global frame_counter
    buffer = info.get_buffer()
    rtp_buf = Gst.RTPBuffer.new()
    if rtp_buf.map(buffer, Gst.MapFlags.READ):
        is_frame_end = rtp_buf.get_marker()
        if is_frame_end:
            frame_counter += 1
            print(f"完整帧序号：{frame_counter}，对应RTP结束序列号：{rtp_buf.get_seq()}")
        rtp_buf.unmap()
    return Gst.PadProbeReturn.OK

# 初始化接收管道后绑定探针
receive_pipeline = Gst.parse_launch("你的接收管道字符串")
depay = receive_pipeline.get_by_name("rtph264depay")
depay_src_pad = depay.get_static_pad("src")
depay_src_pad.add_probe(Gst.PadProbeType.BUFFER, rtp_probe)

方案2：自定义帧元数据（最可靠） #

在发送端给每个原始帧添加自定义元数据，接收端提取该元数据，完全不受编码和RTP打包影响。

发送端修改： #

1. 在videoconvert之后、x264enc之前添加identity元素用于挂探针：

<video src and some manipulation elements> !
queue ! 
videoconvert n-threads=2 qos=false !
identity name=frame_marker !
queue !
x264enc !
h264parse !
queue !
rtph264pay !
udpsink host=0.0.0.0 port=5000 sync=true

2. 给frame_marker的输出pad挂探针添加自定义帧ID：

import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst

Gst.init(None)

frame_id_counter = 0

def add_frame_id_probe(pad, info):
    global frame_id_counter
    buffer = info.get_buffer()
    # 添加自定义元数据
    meta = buffer.add_meta(Gst.MetaCustomAPI, None)
    struct = meta.get_structure()
    struct.set_value("frame-id", frame_id_counter)
    frame_id_counter += 1
    return Gst.PadProbeReturn.OK

# 初始化发送管道后绑定探针
send_pipeline = Gst.parse_launch("你的发送管道字符串")
marker_elem = send_pipeline.get_by_name("frame_marker")
marker_src_pad = marker_elem.get_static_pad("src")
marker_src_pad.add_probe(Gst.PadProbeType.BUFFER, add_frame_id_probe)

接收端修改： #

1. 在decodebin之后添加identity元素用于提取元数据：

udpsrc address=0.0.0.0 port=5000 caps=application/x-rtp,media=video,encoding-name=H264,payload=96 !
rtph264depay !
queue !
decodebin !
queue !
identity name=frame_reader !
<other manipulation elements and a sink>

2. 挂探针提取帧ID：

def extract_frame_id_probe(pad, info):
    buffer = info.get_buffer()
    # 查找自定义元数据
    meta = buffer.get_meta(Gst.MetaCustomAPI, None)
    if meta:
        struct = meta.get_structure()
        frame_id = struct.get_value("frame-id")
        print(f"收到帧ID：{frame_id}")
    return Gst.PadProbeReturn.OK

# 初始化接收管道后绑定探针
receive_pipeline = Gst.parse_launch("你的接收管道字符串")
reader_elem = receive_pipeline.get_by_name("frame_reader")
reader_src_pad = reader_elem.get_static_pad("src")
reader_src_pad.add_probe(Gst.PadProbeType.BUFFER, extract_frame_id_probe)

方案3：利用PTS转换为帧序号（适合固定帧率场景） #

如果你的视频是固定帧率，可将buffer的PTS（显示时间戳）转换为递增帧序号：

• 发送端记录第一帧的PTS，后续每帧用(当前PTS - 起始PTS) / 帧间隔计算序号
• 接收端用同样公式反推，前提是发送端和接收端时钟同步（GStreamer默认会处理）

注意事项： #

• 自定义元数据方案需要GStreamer 1.18+版本（默认支持MetaCustomAPI）
• 使用RTP序列号时，要处理丢包导致的序号不连续情况，可通过序号差值判断丢帧
• 探针操作要避免阻塞，否则会影响管道性能

内容的提问来源于stack exchange，提问作者Nitzanu