[Bug 667352] [0.11] misc core API/bug comments/nitpicks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667352
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #13 from Wim Taymans <wim.taymans at gmail.com> 2012-03-28 15:03:27 UTC ---
(In reply to comment #12)
> (In reply to comment #10)
> > It probably tries to push a BYTE newsegment with a non-0 start to see if
> > downstream is seekable. There may be one or two more elements that do this. It
> > used to be the only way.
> > 
> > This should be replaced with s downstream SEEKABLE query. If the query is not
> > handled (FALSE return value), we should also assume downstream is not seekable
> > in master/0.11.
> 
> Could probably be done somehow on element level, the tricky part here is what
> should be the default behaviour for a passing downstream SEEKABLE query.  An
> option might be to have it passed by default, and to have GstCollectPads2
> return FALSE to it which would prevent it from being answered positively by a
> filesink typically following a muxer.
> 
> ----
> 
> Btw, this also shows that (a.o. ?) gst_pad_push_event currently has a flaw;
> consider some sticky event sent downstream (which it does not like; i.e.
> returns FALSE), then that FALSE is never returned to the sender (i.e. eaten by
> core due to a pretty hard res = TRUE in there).

This is intentional, the sticky events all return TRUE when they could be
stored on a srcpad. The reason is that a boolean value is not enough
information to decide what goes on. It eventually works out because the
dataflow will error out after a while (If there is dataflow, see below). 

We're now in a situation where the result of pushing an event is not useful
anymore. If you get FALSE, you know something is definitely wrong, if you get
TRUE, you don't know, the event could be stored on a non-linked pad and will be
pushed later.

> 
> Even if that one is handled, a related problem might remain.  That is, if one
> event does not make it properly downstream, push_sticky currently makes
> evens_foreach give up on the following events, so a subsequent EOS might never
> make it through anymore (which is typically part of some error handling loop
> cleanup/shutdown).  One might say "so be it" but an EOS passing by does help to
> avoid "hanging cases" and allows for "graceful degradation" (e.g. muxer
> metadata etc).

Maybe it could continue pushing the EOS (and only the EOS because the other
events might not make sense without the previous events).

There is a bigger problem, though. If you have a pad with only a sticky EOS
event and you link that to a sink. The sticky EOS will never be pushed because
there is no streaming thread anymore to push 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.