[Bug 796991] New: GStreamer 1.0 version 1.8.1 splitmuxsink: A splitted video record file size remains in a size and not increase

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796991

            Bug ID: 796991
           Summary: GStreamer 1.0 version 1.8.1 splitmuxsink: A splitted
                    video record file size remains in a size and not
                    increase
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: rickyqiqi at hotmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.