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

Zaheer Abbas Merali zaheerabbas at merali.org
Mon Jul 26 08:06:05 CEST 2004


On Mon, 2004-07-26 at 15:39 +0200, Ronald Bultje wrote:
> Hi,
> 
> Don't feel offended, please. I'm simply trying to do what's best for
> GStreamer. That includes keeping stuff out of gst-plugins if I don't feel
> it's suitable to be there yet.

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.

  

> Again, please be patient with adding stuff. I know you're not planning to
> break ABI, but you != anyone. Stuff in gst-plugins is supposed to be for
> anyone. I'm not doing this to annoy you, simply to keep gst-plugins
> liveable.

By submitting multifilesink (assuming it will not be merged into
filesink), I am doing 2 things:

i) committing myself not to break its behaviour during the 0.8.x cycle
ii) committing myself to fix bugs reported in it

> 
> And I'd appreciate comments from other developers as well.
> 

I would too especially on whether to merge it in with filesink or not.

Thanks

-- 
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/20040726/dfbe6cae/attachment.pgp>


More information about the gstreamer-devel mailing list