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

[Zaheer Abbas Merali]

On Wed, 2004-07-28 at 19:29 +0200, Ronald S. Bultje wrote:
> 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).
> 

Interesting grades of usefulness, I agree that it is useful but not to
the same extent as a codec decoder/encoder like mad and lame.

Yes, the method for the application specific element is not clean and
that is because we have no clean/defined way for the application to send
events to the pipeline.  Maybe this can be addressed in 0.9.


> [..]
> 
> 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).
> 

:) I guess the difference in opinion on this particular plugin won't
change.  I see the usefulness of this plugin, so does Thomas...both
because we have needed such an element before but none has existed.

Benjamin and Wim also thought the element was useful (going on irc
conversations).
 
> 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.
> 

Don't worry, I'm not taking it personally and yes I agree with you and
am glad you are blunt. :)

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

Any element here that should send new media discontinuities will,
whether it be app triggered or stream triggered (multifilesrc, other
elements where new media enters).  However at this current moment in
time, out of the stock GStreamer (and gst-plugins) elements only
multifilesrc originates them.  This should change, why throw away
pipelines and reconstruct them when all you are doing is changing the
source media.  The other elements in the pipeline "should" do the right
thing wrt new media and I am going to devote some time and effort into
making sure they do.

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

Agreed, we have too many elements that are broken in one way or another.
Though, funnily enough the newer elements are better maintained than
some of the older ones.  I guess this is because they are used heavily
by some GStreamer developer(s) and so they are more likely to be
maintained.


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

I would have supported the inclusion of tcpserversink et al, because the
previous tcp plugins were broken.

What you, and David has said in this thread, is we need a libegg style
"throw new plugins" gst-plugins-extra cvs module.  I do not think gst-
sandbox is good enough for it, because it would need to be structured
like gst-plugins is currently.  I think it would be a good idea to have
such a cvs module, with the view of the useful ones being moved to gst-
plugins.  However, this has the following disadvantages:

i) GStreamer is not as widely used as gtk+ and libgnomeui, so app
developers are going to be reluctant to take elements from gst-plugins-
extra CVS module.  (Is this a valid disadvantage?)

ii) There will be multiple versions of elements hanging around in apps,
potentially with different behaviour.  If an element is moved to stock
gst-plugins from gst-plugins-extra, it may have issues in these
applications.

There are probably other disadvantages, but there are advantages for a
structured element dumping ground.

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

I agree, gst-plugins should be split up.  How to do so is another issue
but defining the boundaries would be hard.  It would be useful if this
can be debated here.

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

Your argument basically says for example, ok lets put all the possible
decoders and demuxers into say totem and let all the other applications
that want to decode video/audio go and copy them from totem.  Ok, that
is a bit drastic but I hope you see what I mean.

I think you undervalue the usefulness of having a plugin repository that
is shipped and so an app requires only logic code and maybe very custom
elements for their own purposes.

The nomination procedure seems over-bureaucratic.  

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

I do not buy your argument regarding multifilesrc, the property I added
fixes multifilesrc.  The reason I added it as a property is so as not to
break current behaviour.  If you look, the patch is ultra-small and
ultra-clean.  Also, I do not agree with the design of the multifilesrc
element.  However I do not want to fix that until 0.9.  My application
does not use multifilesrc and has no plans to.  I wanted to fix it so it
works as it should.

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

I do not take it personally, so dont worry.  I am doing my thing to fix
behaviour in GStreamer for something that seems to have been designed in
but people did not have time to implement.

> PPPPS I stop now. ;).
> 
:)


-- 
Zaheer Abbas Merali <zaheerabbas at merali.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040729/0131a61e/attachment.pgp>