hi,
I am using the following pipeline, on a TX1 to record video (and a variation for recording audio+video) using a custom application.
v4l2src device=/dev/video0 ! 'video/x-raw, width=(int)800, height=(int)600, format=(string)I420' ! omxh264enc profile=1 insert-sps-pps=true ! 'video/x-h264, stream-format=(string)byte-stream' ! h264parse ! splitmuxsink location=/home/nvidia/test-%02d.avi muxer=avimux max-files=5 send-key-frame-requests=true max-size-time=10000000000
When this pipeline is started for the first time, everything works as expected. But when this pipeline is stopped and started a few minutes later, the size of the video is zero initially and then it increases a few minutes later. if the pipeline is stopped while the size of the file is zero then the data is lost. In addition to that, the size of that file is much bigger than it supposed to, given the time contraints set (in max-size-time).
Setting splitmuxsink to debug, i get the following log when the file size increases from zero
0:12:10.385037335 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.197803428 total in_bytes 255911145
0:12:10.385085511 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1065:check_queue_length:<multiqueue:sink_0> Checking queue length len 2470 cur_max 2470 queued gops 0
0:12:10.385103428 2011 0x6cf230 INFO splitmuxsink gstsplitmuxsink.c:1102:check_queue_length:<smux> Multiqueue overrun - enlarging to 2471 buffers ctx 0x66c670
0:12:10.444341494 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.264531001 total in_bytes 255943565
0:12:10.444392223 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1065:check_queue_length:<multiqueue:sink_0> Checking queue length len 2471 cur_max 2471 queued gops 0
0:12:10.444408993 2011 0x6cf230 INFO splitmuxsink gstsplitmuxsink.c:1102:check_queue_length:<smux> Multiqueue overrun - enlarging to 2472 buffers ctx 0x66c670
0:12:10.506073144 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.331269688 total in_bytes 256045960
0:12:10.506116946 2011 0x6cf230 INFO splitmuxsink gstsplitmuxsink.c:1249:handle_mq_input:<multiqueue:sink_0> Have keyframe with running time +0:02:12.331269688
0:12:10.506142154 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1029:check_completed_gop:<smux> Collected GOP is complete. Processing (ctx 0x66c670)
0:12:10.506158925 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1065:check_queue_length:<multiqueue:sink_0> Checking queue length len 2472 cur_max 2472 queued gops 1
0:12:10.506175123 2011 0x6cf230 INFO splitmuxsink gstsplitmuxsink.c:1102:check_queue_length:<smux> Multiqueue overrun - enlarging to 2473 buffers ctx 0x66c670
0:12:10.506231112 2011 0x6cf000 INFO splitmuxsink gstsplitmuxsink.c:621:complete_or_wait_on_out:<multiqueue:src_0> Woken for new max running time +0:02:12.331269688
0:12:10.569088956 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.397999480 total in_bytes 256086580
0:12:10.569138227 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1065:check_queue_length:<multiqueue:sink_0> Checking queue length len 2228 cur_max 2473 queued gops 1
0:12:10.631903259 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.464735491 total in_bytes 256121557
0:12:10.631951227 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1065:check_queue_length:<multiqueue:sink_0> Checking queue length len 1923 cur_max 2473 queued gops 1
0:12:10.695171883 2011 0x6cf230 DEBUG splitmuxsink gstsplitmuxsink.c:1229:handle_mq_input:<multiqueue:sink_0> Buf TS +0:02:12.498099855 total in_bytes 256148710
In particular, when the log shows the line : Have keyframe with running time , the file is populated with data.
I read in a another thread ( RTP client not working if started after the server - Jetson TK1 - NVIDIA Developer Forums ) about a similar problem that gets resolved by setting: insert-sps-pps=true. In this way the codec can be forced to send keyframes. But I did not get that.
I have also set : send-key-frame-requests=TRUE , in splitmuxsink. Since, the version that comes with the TX1 does not support this property, I had to upgrade Gstreamer to version 1.9.2
splitmuxsink will not flush the buffer into the file, unless a keyframe comes in.
Any ideas why am I not getting keyframes at regular intervals from omxh264enc, after a restart. Is there another way to trigger it.
Thanks in advance.