GNOME Bugzilla – Bug 755999
gstharness: add gst_harness_set_single_segment
Last modified: 2018-11-03 12:29:56 UTC
Created attachment 312589 [details] [review] implementation with test "borrowed" from gstidentity, single-segment allows testing continuous timestamping even when multiple segments are involved, without having to do the "segment-math" manually.
Can you also provide a test that uses it? To get an idea how it makes things easier and is used :)
Review of attachment 312589 [details] [review]: ::: libs/gst/check/gstharness.c @@ +259,1 @@ case GST_EVENT_SEGMENT: What about resetting the segment on FLUSH_STOP? @@ +265,3 @@ + if (clock) { + priv->running_time_offset = gst_clock_get_time (clock) - + gst_element_get_base_time (h->element); Why are you taking the clock here as an offset? That doesn't really make much sense IMHO, it should just output the current running time as is without offsetting. Is identity doing the same?
(In reply to Sebastian Dröge (slomo) from comment #1) > Can you also provide a test that uses it? To get an idea how it makes things > easier and is used :) You mean in addition to the test I already provided?
Yes, an actual test that does not test GstHarness but some element functionality :)
You are getting greedy... ;) It would be interesting to discuss the clock offset based on what is happening in that test though. If you introduce a demuxer into a running pipeline, and want that stream to sync on the clock, would it not be exactly that that is happening: treat the arrival time of the default segment as an offset added on to every following timestamp to have the demuxers buffers relevsnt to the running time of the pipeline?
Created attachment 320982 [details] [review] updated patch
Created attachment 321082 [details] [review] patch
Created attachment 364753 [details] [review] harness: fix up single segment mode some more Adds handling of GAP events, and removes GstClock stuff. I think this is roughly how this should work. But it breaks your unit test of course, because it tests for the addition of the clock running time. I don't understand your test, or the scenario you want to test exactly. Maybe you want to push a segment event with an offset in the test?
If you add a demuxer to an already-running pipeline then it depends a bit on the pipeline what needs to be done IMHO: 1) If demuxer input is in TIME format like from a live input (mpeg-ts or asf over RTP; mpeg-ts-over-udp, etc.) then the demuxer should produce output buffers on ~ the same running time line as the input buffers. So no problem. 2) If demuxer input is e.g. from a file, the demuxer will produce output timestamps from running time 0, in which case you need to offset those manually to the current or desired running time, otherwise the beginning or all of the output will get dropped when synced against. Or maybe you want to do something entirely different here and I'm just confused because you use the same single-segment terminology but want something else than what identity does for the same thing.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/130.