[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