[gst-devel] Muxing subtitles to matroska [Was: Re: dvdsrc status update, sundry questions]

Michal Benes michal.benes at itonis.tv
Fri Dec 15 10:53:28 CET 2006

> > Well, just hoping that these hacks around collectpads can shed their "hacking"
> > existence some day, and that the functionality they provide can make it cleanly
> > into upstream, as much re-usable as possible ... :-)
> > 
> Probably by considering CollectPads to have been an experimenting and
> creating a CollectPads2 to replace it, as we've done with decodebin2

I have been thinking about this last night and I think that the real
problem here is that CollectPads is used in very different situations
(muxer ver. adder), therefore it is very difficult to implement correct
NEWSEGMENT handling (I do not know what is correct anyway).

So it would be probably better to implement new BaseMuxer class (that
uses CollectPads internally). This class would automatically find the
oldest buffer handling all the NEWSEGMENT stuff. I have quick checked
oggmux, avimux ffmux and matroskamux. It seems that they are interested
only in the oldest buffer so that they they could all benefit from the
BaseMuxer class (I am not quite sure about oggmux as I do not understand
it completely).

BaseMuxer would probably need some api addition to CollectPads to
disable/enable waiting for a pad (alternatively BaseMuxer could use
filler buffer hack internally).

Most important BaseMuxer API would be render function that looks like

 * GstBaseMuxerRenderFunction:
 * @muxer: the #GstBaseMuxer that trigered the callback
 * @data: the #GstBaseMuxerData that received the oldest buffer
 * @buffer: the oldest buffer
 * A function that will be called when #GstBaseMuxer found the oldest
 * Returns: GST_FLOW_OK for success
typedef GstFlowReturn (*GstBaseMuxerRenderFunction) (GstBaseMuxer
*muxer, GstBaseMuxerData *data, GstBuffer *buffer);

Please let me know your thoughts.


More information about the gstreamer-devel mailing list