Resetting base time in part of running pipeline
Locked
Resetting base time in part of running pipeline
 
|
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 -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: D206 D44B 5155 DF98 550D 3F2A 2213 88AA A1C7 C933 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Resetting base time in part of running pipeline
|
|
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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Resetting base time in part of running pipeline
|
|
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. 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? Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: D206 D44B 5155 DF98 550D 3F2A 2213 88AA A1C7 C933 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Resetting base time in part of running pipeline
|
|
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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Resetting base time in part of running pipeline
|
|
On Thursday 13 November 2008 16:21:18 Mark Nauwelaerts wrote:
> > 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. Writing (copying!) a plugin is simpler :-) > > 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 ? :) Nah. > * don't know about "right", but similar tricks are known to work ... Great! Done! For the sake of the list archives, in case the patch doesn't make it into -bad: you can find it at in bugzilla #561224 http://bugzilla.gnome.org/show_bug.cgi?id=561224 Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: D206 D44B 5155 DF98 550D 3F2A 2213 88AA A1C7 C933 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |