[gst-devel] Resetting base time in part of running pipeline

[Mark Nauwelaerts]

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