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

[Ronald S. Bultje]

Hi Zaheer & all,

On Mon, 2004-07-26 at 17:02, Zaheer Abbas Merali wrote:
> I understand your argument about gst-plugins.  But I feel that splitting
> gst-plugins is more appropriate than rejecting useful plugins.  Again, I
> only put it there so that people see the code and decide whether it
> should be merged into filesink or not.  If the decision is that it
> should not be merged into filesink, I would still like to see it as an
> element in either gst-plugins or gstreamer core because it is generally
> useful.
[..]
> 
> > 
> > On Mon, 26 Jul 2004, Zaheer Abbas Merali wrote:
> > [..]
> > > Again, the GStreamer API specifically shows how new media should be
> > > dealt with and that is by having a DISCONT event with the newmedia flag
> > > set.  Any other way is a hack.
> > 
> > No it's not. That's how you *interpreted* the API docs from a sink point
> > of view. However, those API docs only cover events from a source point of
> > view. We have simply never thought of how to do it elsewhere. You're
> > currently assuming that every output file should start when a new input
> > file starts, which is only true in very specific cases. Mostly, you'll end
> > up having to insert a WHATEVER event (DISCONT/new-media, EOS, ...)
> > manually to get the behaviour that your application needs.
> > 
> 
> For multifilesink, yes I have assumed that the behaviour should be that
> a new file is started when new media starts.  New media is not
> necessarily for files only though.  I do not plan to insert events
> manually, the plugins should insert these events as and when needed.  I
> have patched multifilesrc for this, I don't as yet see any other source
> elements that should insert these events in but then I haven't looked
> through each and every element.
> 
> I have also created a private element, which I do not plan to submit
> into gst-plugins or gstreamer which just passes data through it but
> allows my app to trigger the new media DISCONT as and when needed.  This
> element is application specific so I will keep this one with my app.

You're exactly saying what I said before: this element will be
*somewhat* useful, but not *very* useful. Most applications will need
this private element for it to be *very* useful. And you're also saying
what I said before and what I feared: this required element to make it
very useful is pretty application-specific and not very clean (the code
might be clean; the method, however, is not).

[..]

Anyway, I just wrote an extremely large reply to your mail, pretty much
repeating points that I made in my previous email too, just reiterating
them in a different way to be more politically correct and explaining
more in detail. I feel that's not worth it, because I'll get the exact
same reply (from both you and Thomas), so I deleted it again. I'll try
it in a different way (and found out that it became large anyway).

First some things that I feel you misunderstand (given the style of your
replies): I'm not trying to flame you or someone else down. That's not
my style, you should know that. My only interest is GStreamer. I know
that goes for you as well. My emails may sometimes be rough. that's
simply a matter of style. They're not intended to be rough in a personal
way.

"I do not plan to insert events manually, the plugins should insert
these events as and when needed."

That's the same thing. They might not mean the same thing in a
litteral-language way, but they still mean the same thing in the end.
"The plugins" here refers to plugins in the pipeline, possibly the
application-specific plugins. "I" refers to the application. So you will
insert those events through the application-specific plugins. I'm sure
that means that the plugin is very powerful, but it is not without this
appication-specific plugin. And *that* is what I was referring to. The
element indeed has a general function, but it's only useful in a limited
way.

So now the question is whether this is problematic. A few weeks ago,
Benjamin sent an email to the list in which he raised the point of the
overload of plugins being added to gst-plugins recently. He noted that
most of those plugins had a pretty application-specific character, even
though they might at some point in some way be useful to other plugins
as well. I support the point he raised there and believe we should be
more strict on what we add to gst-plugins. The reason for this is
extremely simple: we do *not* have the manpower to maintain that,
period. Benjamin raised more points, but this is the most important one
for me.

I understand that you will maintain the plugin, and I respect that and
think that's a very good idea. Therefore, however, I'd like to suggest
(again) to keep it in your application for the time being, because both
there and in gst-plugins will you be the only one maintaining it. If we
hadn't released a stable version yet, I'd have supported Benjamin in
requesting to keep tcpserversink and several other recently added
plugins out of the gst-plugins as well. Gst-plugins is currently a
'throw-it-all-in' bag; we need to stop that, and we will stop that now.
No more delays. (Note to Benjamin: I'll try to reply to your email
proposal before friday, I hope I find time; please kick me [gently] if I
forget.)

In another reply in this same thread, Thomas raised the point that this
plugin might very well be useful for some applications and that we
should find another way of splitting up gst-plugins. If Thomas wants to
continue that point, then I suggest he makes suggestions here in this
thread, and that we *solve* the issue in this thread and find a
solution.

Ronald

PS nobody will stop you copying LGPL'ed code from his application into
some other application and therefore re-using the element. We might want
to setup an invitation procedure for adding new plugins to gst-plugins,
where often-nominated plugins will be invited by the gst-plugins
maintainers to be added to gst-plugins.

PPS the property added to multifilesrc completely changes the element's
behaviour; I'm not sure if that's a good idea. Different behaviour is
generally believed to require a separate element (this has been
discussed multiple times in history of GStreamer), even though 90% is
the same. It decreases code cluttering and keeps gst-core maintainable.
We really don't want people to add random behaviour to plugins in
gst-core because their application uses that feature. Gst-core will be
(not should be; will be; must be; has to be; this is beyond any
discussion) ultra-clean.

PPPS again, this is not personal, don't take it personal. We all
appreciate each other's efforts. This is for GStreamer.

PPPPS I stop now. ;).