在 mp4 中使用 gstreamer h264 + aac 录制仅产生部分可播放的文件
Record with gstreamer h264 + aac in mp4 produces only partially playable file
我正在尝试在 gstreamer 中构建流媒体应用程序，其中 a) 从实时源捕获音频和视频 b) 在 h264 和 aac 中对其进行编码，c) 将其保存在 file.mp4
我正在使用以下管道在文件中记录：
gst-launch-1.0 -e --gst-debug=**:4 videotestsrc is-live=true \
! queue ! videoconvert \
! videorate silent=false \
! videoscale \
! "video/x-raw, width=1280, height=720, framerate=25/1" \
! queue ! x264enc speed-preset=3 tune=zerolatency bitrate=3800 key-int-max=0 \
! queue ! muxer.video_0 \
audiotestsrc is-live=true \
! audioconvert ! audioresample ! audiorate ! "audio/x-raw, rate=48000, channels=2" \
! queue ! faac bitrate=128000 rate-control=2 \
! queue ! muxer.audio_0 \
mp4mux name=muxer streamable=true \
! queue ! filesink location="/home/myenc/mystream.mp4" sync=false
Q/Problem:
如果我们 运行 短会话 e.a，给定的管道似乎没有问题。 ~1-2 小时左右。
但是当我们 运行 它更长一点时，记录文件在大约 ~4GB 的文件中被破坏了（等于物理 RAM！？）
例如：如果我们捕获 360p 1Mbit，则文件可播放至 4 小时，如果我们捕获 720p 4Mbit，则文件可播放至 1 小时。
有没有人遇到同样的问题或者有人可以重现它？
这是 qt/mp4mux 的正常行为，例如 'ensonic' 提到的 here 吗？
是否有解决方法？
经过大量测试后，我假设它与物理内存以及 mp4mux 的工作原理有关。
然而 and/or 从机器中移除额外的 RAM 对损坏的文件没有任何影响（仍然只能播放到 4GB）
任何指向正确方向的建议，示例，将不胜感激。
注：
-我能够生成的 4GB 后唯一可播放的录音文件是当我们根本不使用任何多路复用器时（又名 byte-stream=true filename.h264）
-或者我们使用 mpegtsmux，它不使用内存中的索引表
我试过的：
使用额外的队列并将其放入 before/after 个元素
在队列中使用泄漏 属性
使用不同的 audio/video 来源（decklinksrc、videotestsrc、audiotestsrc）
仅捕获视频，无音频
使用不同的音频编解码器 (mp3)
使用 qtmux|mp4mux
mp4mux：尝试 streamable=true，尝试 faststart=true，尝试 segmented=2000
正在使用 x264enc
使用 theoraenc+oggenc+oggmux 与 x264enc+faac
在具有相同硬件的两台不同机器上测试
信息:
OS: Ubuntu 14.04
Gstreamer：1.4.5（也用 1.3.90 测试过）
处理器：i5-3570 @ 3.4Ghz
内存：4GB（还测试了 2GB、8GB）
这个问题最初由 gstreamer-devel 邮件列表回答，谢谢) -> link
总结：
gstreamer 'qtmux'(mp4mux) 中存在一个错误，它生成的文件在 4GB 后无法播放。在 1.4.5 中手动应用补丁后，我的问题得到解决。
-错误描述：https://bugzilla.gnome.org/show_bug.cgi?id=741279
-补丁提交：http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=2505e343b1cb29541e60afa3418c21b08ded3981
我正在尝试在 gstreamer 中构建流媒体应用程序，其中 a) 从实时源捕获音频和视频 b) 在 h264 和 aac 中对其进行编码，c) 将其保存在 file.mp4
我正在使用以下管道在文件中记录：
gst-launch-1.0 -e --gst-debug=**:4 videotestsrc is-live=true \
! queue ! videoconvert \
! videorate silent=false \
! videoscale \
! "video/x-raw, width=1280, height=720, framerate=25/1" \
! queue ! x264enc speed-preset=3 tune=zerolatency bitrate=3800 key-int-max=0 \
! queue ! muxer.video_0 \
audiotestsrc is-live=true \
! audioconvert ! audioresample ! audiorate ! "audio/x-raw, rate=48000, channels=2" \
! queue ! faac bitrate=128000 rate-control=2 \
! queue ! muxer.audio_0 \
mp4mux name=muxer streamable=true \
! queue ! filesink location="/home/myenc/mystream.mp4" sync=false
Q/Problem:
如果我们 运行 短会话 e.a，给定的管道似乎没有问题。 ~1-2 小时左右。 但是当我们 运行 它更长一点时，记录文件在大约 ~4GB 的文件中被破坏了（等于物理 RAM！？） 例如：如果我们捕获 360p 1Mbit，则文件可播放至 4 小时，如果我们捕获 720p 4Mbit，则文件可播放至 1 小时。
有没有人遇到同样的问题或者有人可以重现它？
这是 qt/mp4mux 的正常行为，例如 'ensonic' 提到的 here 吗？
是否有解决方法？
经过大量测试后，我假设它与物理内存以及 mp4mux 的工作原理有关。 然而 and/or 从机器中移除额外的 RAM 对损坏的文件没有任何影响（仍然只能播放到 4GB）
任何指向正确方向的建议，示例，将不胜感激。
注：
-我能够生成的 4GB 后唯一可播放的录音文件是当我们根本不使用任何多路复用器时（又名 byte-stream=true filename.h264）
-或者我们使用 mpegtsmux，它不使用内存中的索引表
我试过的：
使用额外的队列并将其放入 before/after 个元素
在队列中使用泄漏 属性
使用不同的 audio/video 来源（decklinksrc、videotestsrc、audiotestsrc）
仅捕获视频，无音频
使用不同的音频编解码器 (mp3)
使用 qtmux|mp4mux
mp4mux：尝试 streamable=true，尝试 faststart=true，尝试 segmented=2000
正在使用 x264enc
的 tune=zerolatency 属性
使用 theoraenc+oggenc+oggmux 与 x264enc+faac
在具有相同硬件的两台不同机器上测试
信息:
OS: Ubuntu 14.04
Gstreamer：1.4.5（也用 1.3.90 测试过）
处理器：i5-3570 @ 3.4Ghz
内存：4GB（还测试了 2GB、8GB）
这个问题最初由 gstreamer-devel 邮件列表回答，谢谢) -> link
总结：
gstreamer 'qtmux'(mp4mux) 中存在一个错误，它生成的文件在 4GB 后无法播放。在 1.4.5 中手动应用补丁后，我的问题得到解决。
-错误描述：https://bugzilla.gnome.org/show_bug.cgi?id=741279
-补丁提交：http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=2505e343b1cb29541e60afa3418c21b08ded3981