GstCollectPads-related freeze in pads mgmt

[Andrey Utkin]

2014/1/3 Sebastian Dröge <sebastian at centricular.com>:
> The gst_pad_add_probe() takes a GDestroyNotify for the data :) Implement
> refcounting for the data for example.

Thanks, i've missed this possibility.

>> > But you're right, the IDLE probes are either called from the "main
>>
>> You must have meant "BLOCKING" here.
>
> No, only IDLE probes can be called from the thread that calls
> gst_pad_add_probe(). All others are called from the thread that triggers
> the probe, which is the streaming thread for anything serialized.

Due to doc,
GST_PAD_PROBE_TYPE_BLOCKING = GST_PAD_PROBE_TYPE_IDLE |
GST_PAD_PROBE_TYPE_BLOCK.

Do you mean that IDLE probes MAY be called directly on stack, but also
may be called on another thread? So IDLE is not a kind that is run
ONLY on the thread calling gst_pad_add_probe.

Thanks for explanations, now i think i understand the matter more clearly.

Are there any future plans, possibly far, about simplifying API, so
API user could avoid this callbacks stuff and just link or detach
whatever they need, whenever they want? Or does such higher-level API
exist already?
In my novice opinion, current GStreamer API is close to unthinkable,
because a lot of things must be taken into consideration, and these
things lack documentation and explanation.
The learning curve is low at the beginning, you can make up and
application very fast, but later you figure out that it is not quite
stable. Or is it just me? :)

-- 
Andrey Utkin