GStreamer结合interpipe录制RTSP H.264流为MP4的异常排查

项目基本情况 #

• 核心功能目标：开发视频应用，接收RTSP摄像头输出的H.264视频流，在无转码的前提下实现流的实时显示与MP4格式存储，当前测试场景为固定5秒录制时长
• 架构选型依据：后续规划接入更多摄像头，需支持运行时动态切换待录制的摄像头源、暂停/恢复录制流程，因此选用gst-interpipe组件实现独立管线间的跨管线通信

当前管线实现 #

整套功能拆分为三条独立运行的GStreamer管线：

• 拉流源管线（负责从摄像头拉取RTSP流）：
  rtspsrc location=rtsp://192.168.0.61:8554/quality_h264 latency=0 ! rtph264depay ! h264parse ! video/x-h264,stream-format=avc ! queue ! interpipesink name=cam1
• 实时显示管线（负责画面预览）：
  interpipesrc allow-renegotiation=true name=src listen-to=cam1 is-live=true ! h264parse ! queue ! decodebin ! autovideoconvert ! d3dvideosink sync=false
• 录制存储管线（负责写入MP4文件）：
  interpipesrc allow-renegotiation=true name=src listen-to=cam1 is-live=true ! h264parse ! queue ! mp4mux ! filesink location=test.mp4

录制流程现有实现 #

• 开辟独立线程等待10秒后，向录制管线发送EOS事件，发送逻辑为gst_element_send_event(m_pipeline, gst_event_new_eos())，其中m_pipeline指向录制存储管线实例
• 当管线总线收到GST_MESSAGE_EOS消息后，将录制管线状态切换为NULL
• 已通过pad探针验证：EOS事件可正常被filesink的sink pad接收

异常现象与交叉测试结果 #

• 核心故障：生成的MP4文件无法正常播放，固定录制时长场景下，每次运行应用生成的文件大小存在明显波动，按照固定录制时长的测试基准，该文件大小波动属于明确流程故障
• 对照测试1：使用完全一致的管线，通过gst-launch命令运行并添加-e参数时，可生成正常播放的MP4文件
• 对照测试2：将录制管线中的mp4mux替换为matroskamux时，生成的MKV文件可正常播放且文件大小符合预期，但存在时间戳异常：播放器显示视频起始时间为10秒而非0点

当前待验证的排查疑点 #

• 是否需要在将buffer送入mux器前调整时间戳
• MP4文件无法正常播放是否为未完成容器头/尾写入导致（已确认当前流程仅执行了发送EOS的操作）
• interpipe组件的使用是否为异常诱因

开发环境基线 #

Windows 10 x64系统下部署GStreamer 1.18.2版本，目标为定位现有故障、获取应用架构优化建议

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