AnsweredAssumed Answered

GStreamer 1.0 version 1.8.1 splitmuxsink: A splitted video record file size remains in a size and not increase

Question asked by Ricky Gong on Aug 18, 2018
Latest reply on Sep 22, 2018 by Ricky Gong

Hi Everybody:

We're using NXP IMX6Q to develop a video recorder similar product. Everything is ok except that occasionally video recording blocks(the video record file size remains in a size and will not increase any more). We're confused on it and trying to find a way to fix it. 

We're using yocto-L4.1.15_2.0.0-ga with image recipe imx6qsabresd fsl-image-qt5 as the board's software platform. And we used it's gstreamer 1.8.1 (with an additional official bugfix to fix a splitmuxsink 32-bit overflow bug: gstreamer/gst-plugins-good - 'Good' GStreamer plugins ) to implement the video record application. The application used such like similar C++ code like this gstreamer command:

"DEV_VIDEO_264="/dev/video3"
DEV_AUDIO="hw:1,0"
FN="/mnt/edisk/record-"$(date +%Y%m%d_%H%M%S)"-%05d.mp4"


gst-launch-1.0 -e v4l2src device="${DEV_VIDEO_264}" do-timestamp=true \
! queue flush-on-eos=true silent=true leaky=0 max-size-buffers=0 max-size-time=0 max-size-bytes=0 \
! h264parse disable_passthrough=true \
! queue flush-on-eos=true silent=true leaky=0 max-size-buffers=0 max-size-time=0 max-size-bytes=0 \
! mux. alsasrc device="${DEV_AUDIO}" \
! audioconvert \
! imxmp3enc bitrate=128 \
! queue \
! mux.audio_0 \
splitmuxsink location="${FN}" reserved-max-duration=3000000000000000000 reserved-moov-update-period=1000000000 max-size-time=900000000000 mp4mux=mp4mux name=mux"

 

We suppose there's a known issue bug on this problem and someone has already known it(A splitted video record file size remains in a size and will not increase any more.) It occurs occationally on one of an on-recording splitted record file. And also no new splitted record file will be created anymore after that. So we submit this issue out and hope someone can give us some suggestions.

Outcomes