GStreamer中的分段mp4

我有管道：

gst-launch-1.0 rtspsrc location=rtsp://ip/cam ! rtph264depay ! h264parse ! mp4mux fragment-duration=10000 streamable=1 ! multifilesink next-file=2 location=file-%03d.mp4

第一部分演奏得很好，其他部分演奏得不好。当我试图查看受损mp4的结构时，看到一个有趣的错误：

穆夫

一些数据

驼鹿

MDAT

驼鹿

MDAT

“一些数据”中最有趣的事情。没有标题数据，它们只是存在。按区块大小，我认为是MDAT。我找到块的大小并在其前面添加MDAT头。文件立即生效并开始播放。但是这首未知的曲子不能演奏，因为在它之前没有莫夫头球

问题在于mp4mux和qtmux。在GStreamer 1.1.0和1.2.2上测试。所有结果都是相同的

---

是否可以使用multifilesink不正确？

是否可以使用videotestsrc而不是rtsp复制此信息

尝试用“videotestsrc num buffers=！x264enc！mp4mux…”替换h264接收和卸载

这可能是一个bug，请将其归档，以便得到维护人员的适当注意

还有，你打算怎么玩

---

谢谢

如果您查看文档，您将找到答案：

无法使用此元素创建可独立播放的mp4文件，请改用splitmuxsink元素

所以，请使用，不要忘了在完成最后一个文件时发送EOS

更新

---

看起来在提出问题的时候，并没有类似于

splitmuxsink

谢谢的元素。我尝试使用videotestsrc，但结果相同。我不明白片段持续时间是如何与multifilesink一起工作的。通过vlc播放。也适用于使用ffmpeg进行转换的测试。受损的原子是在MOOV之后：从这里的快速尝试中，我可以看到有一个关于multifilesink不可查找的警告。这无疑是正确生成这些片段的一个问题。请提交一个关于您的场景的bug，以便修复此多文件接收器问题和/或与之相关的任何其他bug。@Vladimir

splitmuxsink

出现在中。是的，

splitmuxsink

是你的朋友。OP的管道然后减少到

gst-launch-1.0 rtspsrc位置=rtsp://ip/cam ! rtph264depay！h264parse！splitmuxsink location=文件-%03d.mp4

。无需指定mp4mux，它是

splitmuxsink

的默认值。