79484488

Date: 2025-03-04 17:54:39
Score: 0.5
Natty:
Report link

I tried to implement the above method, but as mentioned in a couple of comments, the probe wasn't being called when I wanted to transmit (it was being called once when everything started up, but then not again, perhaps because there wasn't a new buffer on the src pad of the queue, just the one being buffered?)

My solution was to hook up a blocking probe with no callback, and then when I wanted to unblock, I would remove the probe, and hook up a signal on the queue's underrun signal so that when the queue was drained I would block it up again, ready for the next time I wanted it to flow (if you wanted it to just keep on flowing you'd not need to do this).

First step (as given in the answer by @prabhakar-lad)

auto * pad = gst_element_get_static_pad(_queue, "src");
gulong blocking_pad_id = gst_pad_add_probe(pad, (GstPadProbeType)(GST_PAD_PROBE_TYPE_BUFFER | GST_PAD_PROBE_TYPE_BLOCK), NULL, NULL, NULL);

Then when I want things to flow again (the below code is untested, I've torn it out from my project, so it might need tweaking):

gulong connection_id = g_signal_connect(_queue, "underrun", G_CALLBACK(on_queue_underrun), this)
gst_pad_remove_probe(pad, blocking_pad_id);

void on_queue_underrun(const GstElement * queue, MyElement & self)
{
    // Remove the under-run signal hook-up - otherwise I kept on adding more and more signals and it went wrong.
    g_signal_handler_disconnect(queue, self._blocking_pad_id);
    // Do stuff here to put in the new blocking pad
}

Remember to unref your pads as needed (I've missed it out here for brevity)

Reasons:
  • RegEx Blacklisted phrase (1): I want
  • Long answer (-1):
  • Has code block (-0.5):
  • Contains question mark (0.5):
  • Low reputation (0.5):
Posted by: Gemms