[gst-devel] 1:n, n:1 element event handling

[Stefan Kost]

hi,

I recently changed collectpads NEWSEGEMNT behaviour for newsegment
events to forward them instead of swallowing them. Without this change
adder was eating these events, thus they never reached the sink.

Tim pointed out that this might not the correct fix, as we ideally want
collect the newsegment-events and send one unified event instead. [1]

I looked over our source (basically did a search for
gst_pad_set_event_function() and looked at muxer/demux elements). I
found some FIXME comments :)

Below is my current analysis. I welcome comments and ideas :)

Stefan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=340060



                                        Demux             Mux
                        UP DOWN     Sink     Src      Sink    Src
GST_EVENT_FLUSH_START    x    x     .        .        .       spread
GST_EVENT_FLUSH_STOP     x    x     .        .        .       spread
GST_EVENT_EOS            -    x     .        .        collect -
GST_EVENT_NEWSEGMENT     -    x     .        .        merge   -
GST_EVENT_TAG            -    x     .        .        .       -
GST_EVENT_BUFFERSIZE     -    x     .        .        .       -
GST_EVENT_QOS            x    -     spread   -        -       spread
GST_EVENT_SEEK           x    -     spread   -        -       spread
GST_EVENT_NAVIGATION     x    -     spread   -        -       spread
GST_EVENT_DRAIN          ?

use gst_pad_set_event_function() to set a custom event function

= Operations =

spread:
send a copy of the event to all opposite pads

collect:
wait until the event came on all pads, then emit and clear flags

merge:
somehow merge multiple equal events (same events should be send just
once). we can remember the last newsegment event for each pad. if we
have received some events, when can we know that a new merged newsegment
should be generated and sent out?

= Changes =
collectspads:
* collect for eos, merge for newsegment