[gst-devel] Resetting base time in part of running pipeline
Mark Nauwelaerts
manauw at skynet.be
Wed Nov 12 15:03:14 CET 2008
In case of option 3 mentioned below (which might well make sense), there are
already some elements that do either that or similar, see e.g.
http://gentrans.sourceforge.net/docs/head/gst-entrans-plugins/html/gst-entrans-plugins-stamp.html
or
http://gentrans.sourceforge.net/docs/head/gst-entrans-plugins/html/gst-entrans-plugins-shift.html
or
for that matter using "identity single-segment=true".
This latter one, and maybe also the former, do require paying some attention to
the segment (info/event) the element gets. In some cases, it may also be needed
(or sufficient) to put this re-timestamping element to NULL (during the
pad-blocking switch) to reset some state.
Mark.
Arnout Vandecappelle wrote:
> Hoi all,
>
> I have a pipeline running a live source, from which I tee off into a matroska
> filesink. I have implemented dynamic replacement of this filesink without
> interrupting the pipeline. Took a bit of trial-and-error to get the pad
> blocking right, but now this is working fine.
>
> However, the timestamps in the second and later files don't start from zero.
> That's pretty normal, since the live source is providing the buffer
> timestamps and is blissfully unaware of any changes in the pipeline.
> However, the result is that on some players, the playing will stall until so
> many seconds have elapsed and playing is in sync with the timestamps again.
>
> Therefore, I need to reset the buffer timestamps in the filesink branch so
> they start at zero. I see several ways to do this (none simple).
>
> * Simply set the pipeline's base time to 0. Unfortunately, this reset
> doesn't apply to any buffers already existing in the pipeline (e.g. in
> queues), so they'd have to be flushed out. I'd prefer to avoid loosing
> buffers.
>
> * Perhaps something can be done with latencies (which I haven't studied in
> detail). However, I expect also then some flushing will be required.
>
> * Create a new filter element that rebases buffer timestamps (a bit like
> videorate, but adding an offset rather than rounding to the framerate).
>
> I'd like to hear your suggestions about which path to choose. If it turns
> out to be the third one, I'll put it in bugzilla as a patch to -plugins-bad
> (although it fits more in -base).
>
> Regards,
> Arnout
More information about the gstreamer-devel
mailing list