[RFC] New pad callback type: forcefully synchronous, blocking

Andrey Utkin andrey.krieger.utkin at gmail.com
Thu Jan 9 14:41:38 PST 2014


I know that there is such pad callback type that are executed _surely_
in non-synchronous (not on same stack) way - e.g.
GST_PAD_PROBE_TYPE_BLOCK, and there is such type that _may_be_
executed synchronously (on same stack): GST_PAD_PROBE_TYPE_BLOCKING.
It would be very handy for me (and hopefully for others, too) to have
such pad callback type that is guaranteed to execute
synchronously,.i.e. on same stack above gst_pad_add_probe(). Also it
should be executed in blocking mode, so we can manage the pad safely
in the callback. Yes, let it wait until it can execute, if needed.
Obviously the only reasonable return value for such callback type is
GST_PAD_PROBE_REMOVE, or the fact of single execution can be declared
specially in documentation.

Dear developers, do you think this is possible to implement in current
gstreamer?
If implemented, would a patch be reviewed for inclusion?

Any comments?

-- 
Andrey Utkin


More information about the gstreamer-devel mailing list