Multifilemux messages and presicion

Krutskikh Ivan stein.hak at gmail.com
Wed May 25 17:35:23 UTC 2016


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

2016-05-24 21:29 GMT+03:00 Krutskikh Ivan <stein.hak at gmail.com>:

> Hi everyone
>
> 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.
>
> 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.
>
> Simple test pipeline:
>
> gst-launch-1.0 -m rtspsrc location=rtsp://192.168.15.102/av0_0 latency=0
> ! rtph264depay  ! mpegtsmux  ! multifilesink next-file=5
> location=/tmp/test/%05d.ts max-file-duration=3000000000 aggregate-gops=true
> post-messages=1
>
> 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.
>
> On message bus I get:
>
> Получено сообщение #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;
>
> Получено сообщение #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;
>
> 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).
>
> ffmpeg thinks different. My app calculates fragment durations with both
> multipart timestamp and ffprobe format duration. Here's what I get:
>
> Connection to base OK!
> oper
> backup
> backup
> Cleanup thread starting
>
> /tmp/VKO-2/00000.ts
> FFprobe duration  3.098689
> Timestamp duration 3.112220846
>
> /tmp/VKO-2/00001.ts
> FFprobe duration  3.048089
> Timestamp duration 3.001455997
>
> /tmp/VKO-2/00002.ts
> FFprobe duration  3.022633
> Timestamp duration 3.003895173
>
> /tmp/VKO-2/00003.ts
> FFprobe duration  3.042733
> Timestamp duration 3.000683485
>
> /tmp/VKO-2/00004.ts
> FFprobe duration  3.018056
> Timestamp duration 3.003237973
>
> 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.
>
> 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.
>
> What can I do in this situation?
>
> Thanks in advance!
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160525/7c03cada/attachment.html>


More information about the gstreamer-devel mailing list