[gst-devel] multifilesink and proposal to merge it with filesink

[Ronald S. Bultje]

Hi Zaheer,

let me try to explain it a bit clearer. There's currently a bunch of
plugins added to gst-plugins that *might* at *some point in time* be
useful to other applications. However, currently, they're not. They're
ususally being hacked up to only work with specific pipelines (simply
because they don't do proper event handling, don't have proper state
reset functions, etc.). The consequence of this is that these elements
are maybe not *in theory*, but they are *in practice*
application-specific. Other applications will not use them anytime soon.
Some developers have suggested that these plugins should not be
committed into gst-plugins until they have wider use. There are various
reasons to believe that this is a good idea:
* the plugin is now not expected to work in any application anymore, but
only in that one single application. This prevents bug reports due to
poor event handling, state reset handling and so on.
* the plugin interface (the way in which plugin and application
interface; properties, interfaces, signals, etc.) is not public anymore,
and is thus allowed to change at any point in time. The plugin interface
of a plugin in gst-plugins may never regress during a stable series.
This requires a *stable* and *well-thought-out* plugin interface. We
doubt that all the recently added plugins are that far. This is not an
offense to their developers, it's simply deduction: you ususally don't
get it right the first time, and that's completely normal.
* less plugin maintainance and less build time in gst-plugins.

Now, I hope that's clear. What I'm saying is: keep it in your
application, until other applications clearly see the need for this as
well. Then, we can test and possibly change the plugin interface to suit
everyone's need, and then possibly add it to gst-plugins. Gst-rec and
gst-autoplug also have private elements for this same purpose.

On Fri, 2004-07-23 at 00:10, Zaheer Abbas Merali wrote: 
> I committed it on the basis of proposing the small changes of adding new
> media support to filesink.  Also, there have been people on irc asking
> if such a plugin exists so it would not be unique to one particular
> application.
I've added and consequently removed that *ages ago*. See CVS. Reasons:
* the code became very cluttered and non-obvious. Most of the options
were not logical in any sane way. The plugin became unnecesarily
complicated and it basically surpassed the goal of the original, clean
filesink.
* I never figured out a sane way of changing filenames in filesink
without either doing some evil hackery (in which case it should be an
application-specific plugin; gst-core stuff is supposed to be
ultra-clean!), especially in an automated way. In the end, you end up
filtering and inserting EOS events in the pipeline anyway.

I know it is not application-specific, but it *does not belong in
gst-core*. Also, it *does not belong in gst-plugins* until we've found
clean, maintainable ways of solving the above problems. Different people
have different needs for opening new files and filtering or inserting
EOS at different points in time. It's *not* as easy and straightforward
as you described. If it was, I'd have coded it ages ago. Gst-rec needs
this too.

> I do not understand what you mean by "application-specific interfaces".
It means that the setup of the plugin to do a specific function is coded
specifically in a way because one specific application required that,
rather than being a generic interface that was coded that way because we
believe that's the right way to solve the issue and have applications
configure plugins.

> Remember also that multifilesrc is in gst-plugins and does not have a
> twin until my commit :)

multifilesrc is a very general plugin, with a very clean interface to
the applications. I'm in favour of keeping it. Multifilesink currently
isn't that yet. Besides, multifilesink and multifilesrc aren't twins
because they work differently. Multifilesrc creates a new buffer for
each individual file, which is for example useful if you want to read a
series of JPEG images and create an MPEG movie from it. Multifilesink
uses a different approach and creates new files after each individual
EOS. They're not the same.

Note, I'm not saying that multifilesink shouldn't ever be part of
gst-plugins. I'm saying we should be careful with what we add at this
point, because it's *stable* and *may not regress* after this. Be very
sure that it is generally useful before you make this commitment. You
can't fix it until 0.9.x afterwards.

Ronald