Reset timestamp mpegtsmux

Angel Martin amartin at vicomtech.org
Wed Jul 3 23:20:55 PDT 2013


So, as concluded here:
http://gstreamer-devel.966125.n4.nabble.com/Resetting-base-time-in-part-of-running-pipeline-td970032.html

The only solution is set offset of a pad for GST 1.0 or to include a
custom plugin in the middle to retimestamp the buffers?

I have developed the second one and it works. But I'd prefer a
"standard" solution with regular plugins. Any other idea?

2013/6/28 Angel Martin <amartin at vicomtech.org>:
> Dear all,
>
> I am developing a RTP server over OSSBuild (Gstreamer 0.10 Windows)
>
> The stream hosts a H.264+TS video created from a appsrc with a multiudpsink.
>
> I have a tee to generate 2 paths, 1 mpegtsmux for streaming and 1
> mp4mux for local file storage.
>
> I would like to restart mpegtsmux timestamps everytime I change mp4mux
> destination file to get coherent timestamps. The different mp4 files
> have a reseted timestamp starting from 0 in the VLC (ok for my
> purposes) because I: block the pad; move to NULL state mp4mux and
> filesink; unlink them; create new ones; link again; and move to state
> PLAYING. I suppose that I can not do the same for the streaming bin
> because I would disconnect VLC remote players.
>
> In someway is the same scenario explained here:
> http://gstreamer-devel.966125.n4.nabble.com/Resetting-base-time-in-part-of-running-pipeline-td970032.html
> But I do not have the elements "shift" or "stamp" in the 0.10. In
> version 1.0 gst_pad_set_offset fixes it. But I'd like to now if there
> is a solution for that in 0.10 to reset timestamps.
> A possibility is to include the custom resettime element.
>
> I have explored the following possibilities:
>
> 1) Move the pipeline to READY
>
> 2) new_segment for the pipeline element
>
> 3) new_segment for the appsrc pad
>
> 4) new_segment for the caps_src before the mpegtsmux
>
> 5) new_segment for the mpegtsmux sink
>
> 6) switch "do-timestamp" of appsrc to "false" and set myself the time
> buffer (http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/videotestsrc/gstvideotestsrc.c?h=0.10)
>   GST_BUFFER_TIMESTAMP (outbuf) = src->timestamp_offset + src->running_time;
>   GST_BUFFER_OFFSET (outbuf) = src->n_frames;
>   src->n_frames++;
>   GST_BUFFER_OFFSET_END (outbuf) = src->n_frames;
>   if (src->rate_numerator) {
>     next_time = gst_util_uint64_scale_int (src->n_frames * GST_SECOND,
>         src->rate_denominator, src->rate_numerator);
>     GST_BUFFER_DURATION (outbuf) = next_time - src->running_time;
>   } else {
>     next_time = src->timestamp_offset;
>     /* NONE means forever */
>     GST_BUFFER_DURATION (outbuf) = GST_CLOCK_TIME_NONE;
>   }
>  checking right timestamps with:
> g_printerr("timestamp %" GST_TIME_FORMAT "\n",
> GST_TIME_ARGS(GST_BUFFER_TIMESTAMP (buf)));
> (http://gstreamer-devel.966125.n4.nabble.com/Trying-to-reset-the-pipeline-whithout-closing-it-td3814702.html)
> However mpegtsmux seems to use running-time instead of taking the
> stream-time from the buffers.
>
> Any tip or idea?
>
> I have already check these links without sucess:
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-clocks.html
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-time-overview.html


More information about the gstreamer-devel mailing list