[Bug 667352] [0.11] misc core API/bug comments/nitpicks
bugzilla at gnome.org
Tue Mar 27 15:04:41 PDT 2012
GStreamer | gstreamer (core) | 0.11.x
--- Comment #10 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-03-27 22:04:35 UTC ---
> > * seems like elements should be very careful these days to return FALSE when
> > receiving some event (e.g. a newsegment event in an unexpected format), since
> > upstream will keep trying to send it (if sticky, as many are) and fail hard
> > when "real data" is then being pushed (and the sticky event still was not
> > received properly). Maybe self-evident, but probably a problem here and there
> > for elements using an event return value for some hacks that might then need (a
> > query?) alternative (e.g. flacenc springs to mind).
> Refusing an event will now also generate an error when trying to push a buffer.
> I think this makes sense in the case of a segment event with a wrong format.
> Will check what hack flacenc does.
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
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.
More information about the gstreamer-bugs