[gst-devel] recent wave of element additions

[Benjamin Otte]

Hi gang,

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

Just for the record, here's what I've found from glancing over recent 
additions:
- 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?

Benjamin