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

Mark Nauwelaerts manauw at skynet.be
Thu Nov 13 16:21:18 CET 2008



Arnout Vandecappelle wrote:
> On Wednesday 12 November 2008 15:03:14 Mark Nauwelaerts wrote:
>> 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.
> 
>  Thanks for the input.  I've tried with identity, and it works (almost).
> 
>  The problem with all three of them is that you need to specify the offset 
> somehow: with the delay property (shift) or with a newsegment (stamp & 
> identity).  However, this offset is not available until the next buffer is 
> received.  I now use the stream position just before the dynamic element 
> replacement, but that's of course off by one buffer.

A buffer probe handler might retrieve this from the 'next buffer' and could send 
a newsegment (or whatever) based on it.

> 
>  I'll therefore implement a 'resettime' element (based on shift) and add it 
> to -bad.
> 
>  Two more questions:
>  * Any better name suggestions than 'resettime'?
>  * To trigger the reset, I was thinking of a write-only property 'reset'.  Is 
> that the right way to go?

Matters of taste;
* perhaps dynamicshift ? :)
* don't know about "right", but similar tricks are known to work ...

Mark




More information about the gstreamer-devel mailing list