<div dir="ltr">Ok, now I use file modification time to define the end of recording. It kind of better for my needs. But I would like to bump my question non the less<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-24 21:29 GMT+03:00 Krutskikh Ivan <span dir="ltr"><<a href="mailto:stein.hak@gmail.com" target="_blank">stein.hak@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi everyone<br><br></div>I want to use multifilesink element of gstreamer to record portions of video from mjpeg/h264/h265 ip cams for both persistent and on-demand recording.<br><br></div><div>I use gstreamer message bus to get veryfy the duration of recorded files and mux them afterward to cold storage with ffmpeg. Right now I have troubles with precision of those messages.<br><br></div><div>Simple test pipeline:<br><br>gst-launch-1.0 -m rtspsrc location=rtsp://<a href="http://192.168.15.102/av0_0" target="_blank">192.168.15.102/av0_0</a> latency=0 ! rtph264depay ! mpegtsmux ! multifilesink next-file=5 location=/tmp/test/%05d.ts max-file-duration=3000000000 aggregate-gops=true post-messages=1<br><br></div><div>So I want to store a set of 3 second long .ts files in ram and concat them later in one mp4 file to persistent storage.<br><br></div><div>On message bus I get:<br><br>Получено сообщение #256 от элемента «multifilesink0» (element): GstMultiFileSink, filename=(string)/tmp/test/00000.ts, index=(int)0, timestamp=(guint64)3116261661, stream-time=(guint64)3116261661, running-time=(guint64)3116261661, duration=(guint64)18446744073709551615, offset=(guint64)18446744073709551615, offset-end=(guint64)18446744073709551615;<br><br>Получено сообщение #257 от элемента «multifilesink0» (element): GstMultiFileSink, filename=(string)/tmp/test/00001.ts, index=(int)1, timestamp=(guint64)6141265420, stream-time=(guint64)6141265420, running-time=(guint64)6141265420, duration=(guint64)18446744073709551615, offset=(guint64)18446744073709551615, offset-end=(guint64)18446744073709551615;<br></div><div><br></div><div>First of all, timestamp, stream_time, running-time are the same number and as I assumed they mean time of pipeline running in nanoseconds. duration is always the same no matter how I change max-file-duration. Ok, I thought that duration of fragment can be calculated as (timestamp_current_file - timestamp_last_file). <br><br>ffmpeg thinks different. My app calculates fragment durations with both multipart timestamp and ffprobe format duration. Here's what I get: <br><br>Connection to base OK!<br>oper<br>backup<br>backup<br>Cleanup thread starting<br><br>/tmp/VKO-2/00000.ts<br>FFprobe duration 3.098689<br>Timestamp duration 3.112220846<br><br>/tmp/VKO-2/00001.ts<br>FFprobe duration 3.048089<br>Timestamp duration 3.001455997<br><br>/tmp/VKO-2/00002.ts<br>FFprobe duration 3.022633<br>Timestamp duration 3.003895173<br><br>/tmp/VKO-2/00003.ts<br>FFprobe duration 3.042733<br>Timestamp duration 3.000683485<br><br>/tmp/VKO-2/00004.ts<br>FFprobe duration 3.018056<br>Timestamp duration 3.003237973<br><br></div><div>This doesn't look to different, but when I concat those small files in 2 minutes interval I get a duration mismatch of 1-4 seconds or more when GOP size is bigger.<br><br></div><div>For h264/h265 I can go with ffprobe although It's kinda ugly. But with mjpeg I cannot find a suitable streaming muxer witch would tell me the exact duration of video. Both multipartmux and matroskamux fail to do so.<br><br></div><div>What can I do in this situation?<br><br></div><div>Thanks in advance!<br></div><div><br><br><br></div></div>
</blockquote></div><br></div>