[gstreamer-bugs] [Bug 415754] New GstMuxer class

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=415754

  GStreamer | gstreamer (core) | Ver: HEAD CVS


Mark Nauwelaerts changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manauw at skynet.be




------- Comment #6 from Mark Nauwelaerts  2007-03-09 22:57 UTC -------
I have noticed the following in the patches:

1) custom event handling:
it contains
  pads->func = NULL;
  pads->user_data = NULL;
but this does not seem to be used elsewhere ?
Is this perhaps a leftover of an older destroy_notify implementation, which
changed because it affected the ABI of GstCollectData.
This patch breaks the ABI of GstCollectPads itself, because event_func and
event_user_data are not stored inside abidata.ABI (so affect the overall struct
size).  Also, they won't both fit in there, because the padding is not that
much (GST_PADDING=4).  It may have to be worked around as well (storing in the
GObject data).

2) gst_collect_pads_set_waiting:
Similarly, it breaks GstCollectsData ABI; extends beyond the padding, as there
is no more room in there (there was already none for destroy_notify).

3) GstBaseMux:
Some nitpicking, it seems to use collect_data->abidata.ABI.new_segment
directly, but this is marked as private (though a borderline)
[will need to look some more at BaseMux, it is a quite a lot ;-) ]

As a design point, though, there is a lot of "pass-through" code in GstBaseMux,
e.g. _stop, _start, _add_pad, _set_event_function, destroy_notify handling, etc
that either all go straight to GstCollectPads or pretty much do the same = have
similar code as GstCollectPads, causing a lot of "duplication".
The real added value/intelligence is in the (essentially) pads_collected
function interplaying with the event handling callback (settable in the patched
GstCollectPads).
This could be reduced by modelling (say) GstMuxPads as a subclass of
GstCollectPads.  Such one could be pretty directly/readily used as a
replacement/enhancement of GstCollectPads in existing muxers, if they so
desire.
At present, using GstCollectPads already means a muxer accepts "ok, this thing
will take care of _chain and so on for me".  Handing it to GstMuxPads would
then in addition mean "ok, and this one even comes along with a typically
useful, more 'intelligent' collect deciding function that is decently
event-aware as well".
If the gst_collect_pads_set_event function were made sort-of "virtual" (in
GstCollectPads), then the using Muxer element could still use this to indicate
to GstBaseMuxer that it too wants to have a peek at the events (e.g. tags), in
addition to GstBaseMuxer fancy intelligent considering of (certain) events
[other "methods" might be useful to make "virtual" as well].
Beyond that, GstMuxPads could then also offer e.g. a callback custom
compare_func.
So, in short/overall, override/extend the GstCollectPads functionality by
inheritance rather than duplicate/wrap around it [and the real "core
intelligence code" in GstBaseMux would then stand out in a good place in such a
GstMuxPads].


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email