能否用共享内存跨GStreamer管道共享编码视频？及管道无输出排查

管道存在的核心问题 #

• Caps不匹配：主管道输出的是video/x-h265,profile=main,width=1920,height=1080,framerate=30/1，但消费管道硬指定了width=1280,height=1080，直接导致数据无法通过caps协商，消费端接收不到任何数据，这是文件为0字节的核心原因。
• 冗余元素干扰：主管道已经完成h265parse处理，消费端重复添加该元素可能干扰流结构识别，虽不致命但无必要。
• MP4容器初始化依赖：MP4mux需要关键帧才能完成文件头初始化，若消费端启动时未捕获到关键帧，也会导致文件无法正常写入，但这是次要问题，核心仍为caps不匹配。

修正后的管道示例 #

主（生产者）管道（无需修改） #

# Primary (producer)
gst-launch-1.0 -e \
videotestsrc ! 'video/x-raw,width=1920,height=1080,framerate=30/1' \
! videoconvert \
! x265enc ! 'video/x-h265,profile=main' \
! h265parse \
! shmsink socket-path=/tmp/foo shm-size=2000000 wait-for-connection=false sync=true

次（消费者）管道（修正后） #

# Secondary (consumer)
gst-launch-1.0 -e \
shmsrc socket-path=/tmp/foo do-timestamp=true is-live=true \
! 'video/x-h265,profile=main' \
! mp4mux \
! filesink location=output.mp4 sync=false

说明：仅指定必要的profile属性，让GStreamer自动协商分辨率、帧率等参数，同时设置sync=false避免短期抓取场景下的时钟同步阻塞。

共享内存共享H265流的思路完全可行 #

用shmsink+shmsrc共享编码后的H265流非常适合你这种「长期生产者+短期消费者」的场景，本地传输效率远高于网络协议。只需注意以下几点：

• 严格保证生产者与消费者的caps匹配，或让消费者只指定通用属性，依赖自动协商；
• 消费者启动时，确保生产者已在输出流（最好包含关键帧），若生产者已运行一段时间，消费者可能需等待下一个关键帧才能开始写入；
• 根据视频分辨率适当调整shm-size，1920x1080的H265帧设置2000000字节足够，大帧场景可适当调大。

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