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

[rickyqiqi]

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.

[igorpadykov]

Hi Ricky

one can try latest L4.9.88 official nxp bsps using sect.7.3.3 Video encoding

attached Linux Guide and Demo Image

https://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_MX6QDLSOLOX&appType=license&location=null&... 

more documentation can be found on

i.MX Software|NXP 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[rickyqiqi · Accepted solution]

After many deep investigation on this issue, we suppose this issue is something related with the file system (The issue was not reproduced again after we changed the file system of the video file storage disk from EXT4 to NTFS-3G).

[rickyqiqi]

An additional informat about this issue: We suppose this problem maybe something related to file operation failure/timeout(maybe waited too long time). Because everytime this issue occured, the disk is about full(but we're sure there's enough space(at least 5% disk space left) for next file write. We're using a 128GB disk. We implemented a backend feature in our C++ application to delete an oldest file everytime disk space remaining arrrives 5% left and keep deleting another oldest file once 10 seconds until disk space remaining is more than 20%.). We suppose maybe there's some system disk defragment operation in doing by system on backend. And it maybe affect in gstreamer's file operation.