GNOME Bugzilla – Bug 796991
GStreamer 1.0 version 1.8.1 splitmuxsink: A splitted video record file size remains in a size and not increase
Last modified: 2018-09-17 08:39:54 UTC
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.
The additional official bugfix to fix a splitmuxsink 32-bit overflow bug is at the following description: https://bugzilla.gnome.org/show_bug.cgi?id=770019
Could you please try with a newer version (1.14 or git master) to see if it's already fixed? There were many changes.
And also verify the your encoder (from third party gstreamer-imx) supports key frame request.
(In reply to Tim-Philipp Müller from comment #2) > Could you please try with a newer version (1.14 or git master) to see if > it's already fixed? There were many changes. Thank you for your kindly reply, but it seems it's not a simple task to update it to 1.14 or git master. You know we're using gstreamer on an ARM architecture platform. It needs to cross compile all the gstreamer stuff. We've tired to compile but failed because of too many 3rd party compenents involved. :-(
(In reply to Nicolas Dufresne (ndufresne) from comment #3) > And also verify the your encoder (from third party gstreamer-imx) supports > key frame request. Thank you, Nicolas! Sorry for my inocence on the key frame request feature. Could you give me some more information(Or maybe some document/URL stuff) on this feature? I'd rather to learn about it first and so I can explain clearly to NXP guys.
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 suppose maybe there's some system disk defragment operation in doing by system on backend.
After many deep investigation on this issue, we suppose this issue is something related with the file system.