[gst-devel] recent wave of element additions
in7y118 at public.uni-hamburg.de
Fri Jun 25 08:27:04 CEST 2004
I'm a bit afraid by the recent wave of element additions. The main issue here
is maintainability, QA and completeness of those elements.
We have a lot of elements in both plugins and the core that are poorly
maintained (if at all), because they are rarely used. And then if somebody
starts using them, he figures out they are broken. Good examples here are
aggregator, which is a core element that is broken since 0.7.x and shout2send,
which just segfaulted until this release. The next problem is that lots of
elements are incomplete, especially wrt event handling. This is especially bad
because the default action is to pass on the event unmodified, which leads to
event handling looking as if it works while in reality it doesn't.
Most of the time people writing a plugin only it to do one particular job,
like playback a gst-launch line. Noone will ever send an event there so it's
not an issue. So I can understand why nobody would bother implementing it in
that case. I have nothing against such plugins per se but I'd prefer people
not putting them in our release-quality code and especially not in the core
unless there's a big amount of applications wanting it so it justifies
Just for the record, here's what I've found from glancing over recent
- audiorate doesn't handle events, so for example audiorate->in_offset may
appear grossly wrong after a discont.
- audiorate uses g_warning instead of debugging messages
- audiorate doesn't use GstAudioFilter
- videodrop and videorate seem like duplication
- videorate doesn't use GstVideoFilter
- videorate doesn't handle events, so seeks by default units (number of
frames) go wrong
- videorate uses debugging output, but has no category.
- videobox uses gst_buffer_new_and_alloc instead of gst_pad_alloc_buffer
- videobox doesn't handler events, like navigation
- videobox isn't subclassed from GstVideoFilter
- get/set_property on multifdsink is unimplemented
- the algorithm in multifdsink of dropping all blocking fds when one of them
is writable seems very suboptimal for what people expect
- a multifdsink should be implemented as tee ! fdsink tee0. ! fdsink ...
anyway, instead of being a core element
While some of them are only minor issues, others can introduce bugginess or
aunexpected behaviour. And we have to be particularly careful here, because
GStreamer is known for two things to the general public: powerful and non-
working. I only like one of those.
So how do we handle this?
More information about the gstreamer-devel