[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 #12 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-03-28 11:30:06 UTC ---
(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).

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

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