你的问题本质是GStreamer内存对象的生命周期管理不当——直接复用从Appsink获取的Buffer内存时，没有正确维持内存的引用计数，导致要么内存提前被回收（后续帧显示绿屏），要么内存被重复释放（触发断言错误）。下面是具体的原因分析和最佳实现方案：

问题原因拆解 #

1. 绿帧问题：当你从Appsink调用pull_sample()拿到Buffer后，这个Buffer的所有权属于GStreamer的内存池。如果没有增加引用计数，当Sample对象被销毁后，Buffer的引用计数归零，内存会被立即回收。后续你复用这个内存时，访问的是已释放的内存空间，就会显示绿帧。
2. 断言错误：添加sleep(0.05)只是延缓了内存回收的时机，但当内存池最终回收原Buffer时，你插入到新Buffer的内存块已经失效，此时GStreamer尝试释放已销毁的VA-API图像资源，就会触发gst_vaapi_image_unmap的断言失败。

最佳实现方案 #

方案1：使用Buffer.copy_region实现无拷贝共享内存 #

这是最简洁且符合GStreamer内存模型的方式——通过copy_region并指定NO_COPY标志，创建一个共享原Buffer内存的新Buffer，GStreamer会自动维护内存的引用计数，确保内存不会被提前释放。

# 从appsink拉取样本
sample: Gst.Sample = self.__sink.pull_sample()
src_buffer: Gst.Buffer = sample.get_buffer()

# 创建共享原内存的新Buffer，NO_COPY标志表示不做内存拷贝
new_buf = Gst.Buffer.copy_region(
    src_buffer,
    Gst.BufferCopyFlags.NO_COPY,
    0,  # 起始偏移
    src_buffer.get_size()  # 复制长度（整个Buffer）
)

# 推送新Buffer到appsrc
ret = self.__src.push_buffer(new_buf)
# 无需手动管理引用计数：GStreamer会在新Buffer被处理完成后自动减少引用，当计数归零时回收内存

方案2：显式管理Buffer的引用计数 #

如果你需要更精细的内存控制，可以手动增加原Buffer的引用计数，确保内存在Appsrc处理完成前不会被回收：

sample: Gst.Sample = self.__sink.pull_sample()
self.__buffer: Gst.Buffer = sample.get_buffer()

# 增加引用计数，阻止内存池提前回收该Buffer
self.__buffer.ref()

# 获取内存块并插入到新Buffer
shared_memory = self.__buffer.get_all_memory()
new_buf = Gst.Buffer.new()
new_buf.insert_memory(-1, shared_memory)

# 推送Buffer到appsrc
ret = self.__src.push_buffer(new_buf)

# 注意：不要在这里调用self.__buffer.unref()！
# 新Buffer持有shared_memory的引用，当新Buffer被处理完后，会自动减少shared_memory的引用计数
# 当原Buffer的所有引用都被释放时，内存才会被回收

额外注意事项 #

1. 避免不必要的内存映射：如果只是为了复用内存，不要调用buffer.map()——映射会占用系统的映射资源，且如果忘记unmap，可能会导致内存泄漏或断言错误。如果确实需要访问原始内存，务必在不再需要时调用buffer.unmap(map_info)，且要确保在内存被回收前完成unmap。
2. 匹配Caps格式：确保Appsrc的Caps（如video/x-raw,format=NV12,...）与Appsink输出的Buffer格式完全一致，否则会导致格式不兼容的错误。如果不确定格式，可以从Sample的Caps中获取并设置给Appsrc：

   src_caps = sample.get_caps()
   self.__src.set_caps(src_caps)
   

3. Appsrc的配置优化：设置appsrc的block=true是合理的，但可以考虑开启emit-signals=true并连接need-data信号，以更高效地控制数据流，避免阻塞问题。

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