[Bug 729124] multiqueue: avoid signaling overrun on the first segment

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=729124
  GStreamer | gstreamer (core) | unspecified

--- Comment #5 from Thiago Sousa Santos <thiagossantos at gmail.com> 2014-04-28 17:18:53 UTC ---
(In reply to comment #4)
> (From update of attachment 275359 [details])
> While the bug and analysis is correct, this seems like a rather awkward way of
> fixing it somehow :) Also can't the same situation on a segment update, i.e. if
> you already have a src segment but got a new one, didn't apply it yet and get a
> buffer that fills it all up?

Yes, it could happen, but if you have a segment on your source pad and you
receive either another segment or a buffer with a timestamp that makes it full
you really have some 'data' inside the single queue to make it full. Even if
this data is actually an indirect representation of a gap in the stream. One
can argue that this is not really data, but I can see valid points either way.

This patch fixes the situation where multiqueue would assume this gap would
exist just because the default time for the source pad without any received
data would be 0. In this case I can't see any way where this would be correct.

-- 
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.