When GSTPAD_API.gst_pad_add_probe is called with a mask of IDLE which usually is what we want when calling block(), it can, if the pad is already IDLE directly call the probe-callback from the calling thread.
In the case of block() this will directly jump into the Pads eventReceived method, which will directly call removeCallback.
removeCallback tries to find the callback-object in the Pad's signals but fails to do so, because we actually have not yet created the actual callback object - we're still stuck in the constructor-call of the GCallback object.
Actually the GCallback is registered only after the actual callback has been executed for the first time, and it will be called again – and only on the second invocation it will actually be removed. Often, especially when unlinking the pad in the block-callback, there might not be a second invocation and the probe might be dangling forever.
The solution to this is to return PadProbeReturn.REMOVE from the block-callback. This will cause GSTPAD_API.gst_pad_add_probe to return a probe-id of 0, which can be used in addEventProbe to detect that the requested probe has already been handled and there is no need for it to be registered on the GObject. I implemented this optimization in this PR.
This fix is part of a set of fixes for #184 and is extracted from #186
neilcsmith-net
commented
4 years ago
When GSTPAD_API.gst_pad_add_probe is called with a mask of
IDLEwhich usually is what we want when callingblock(), it can, if the pad is already IDLE directly call the probe-callback from the calling thread.In the case of
block()this will directly jump into the Pads eventReceived method, which will directly call removeCallback.removeCallbacktries to find the callback-object in the Pad's signals but fails to do so, because we actually have not yet created the actual callback object - we're still stuck in the constructor-call of theGCallbackobject.Actually the
GCallbackis registered only after the actual callback has been executed for the first time, and it will be called again – and only on the second invocation it will actually be removed. Often, especially when unlinking the pad in the block-callback, there might not be a second invocation and the probe might be dangling forever.The solution to this is to return
PadProbeReturn.REMOVEfrom theblock-callback. This will causeGSTPAD_API.gst_pad_add_probeto return a probe-id of 0, which can be used inaddEventProbeto detect that the requested probe has already been handled and there is no need for it to be registered on the GObject. I implemented this optimization in this PR.This fix is part of a set of fixes for #184 and is extracted from #186