[Bug 699793] videomixer: resets its current segment when receiving a flush stop

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=699793
  GStreamer | gst-plugins-good | git

--- Comment #10 from Thibault Saunier <thibault.saunier at collabora.com> 2013-05-19 16:44:15 UTC ---
Pasting a small conversation about the subject (no conclusion reached):

<thiblahute> According to slomo (
https://bugzilla.gnome.org/show_bug.cgi?id=699793), videomixer is supposed to
always output segment of the form of [0, -1], but it will break gnl way of
calculating segment.base as what we do this next_segment.base =
gst_segment_to_running_time (segment.stop) - gst_segment_to_running_time
(segment.start). Is it wrong in GNL or should videomixer output a meaningful
value for segment.stop?
<__tim> thiblahute, it seems the only sane way to me to be able to acommodate
any number of inputs with the possibility of inputs being added/removed/updated
at any time
<__tim> thiblahute, though maybe you want a mode where it 'rebases' on top of a
specified master stream's segment or something
<__tim> don't know if what gnl does could or should be done differently
<thiblahute> __tim, I see, I am not sure adding such a mode would help a lot
and instead bring complexity to videomixer users. I am thinking gnl might be
able to calculate the base time differently.
<thiblahute> __tim, Hrm, thinking about it, in gnl it would be good enough if
we could make sure videomixer sets the stop time to the smallest stop time of
the various segment received on it sinkpads. Would that be a solution for you?
<__tim> I don't know. I haven't really thought properly about it, I'm just
thinking out loud really :)
<thiblahute> __tim, I see, If you get to some conclusion, I would be happy to
hear about it :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.