GNOME Bugzilla – Bug 751216
pad: buffer probe not triggered any more now that element outputs buffer list instead of individual buffers
Last modified: 2015-06-21 21:32:44 UTC
Hello, I have filesink element named urisink (created by GESPipeline). I want to know when buffer has been sent to filesink by muxer. On receiving GST_MESSAGE_STREAM_START on GESPipeline's bus I'm attaching probe to filesink's sink, with several printfs to stdout (sorry for C++11): ... ges_pipeline_set_mode(pipeline, GES_PIPELINE_MODE_RENDER); GstBus *bus = gst_pipeline_get_bus(GST_PIPELINE(pipeline)); gst_bus_add_watch(bus, [](GstBus *, GstMessage *msg, gpointer data) -> gboolean { ... switch (GST_MESSAGE_TYPE(msg)) { ... case GST_MESSAGE_STREAM_START: ... { GstElement *filesink = gst_bin_get_by_name(GST_BIN(pipeline), "urisink"); fprintf(stdout, "filesink: %p\n", filesink); fflush(stdout); GstPad *sinkpad = gst_element_get_static_pad(filesink, "sink"); fprintf(stdout, "sinkpad: %p\n", sinkpad); fflush(stdout); filesink_probe = gst_pad_add_probe(sinkpad, GST_PAD_PROBE_TYPE_BUFFER, [](GstPad *pad, GstPadProbeInfo *info, gpointer data) -> GstPadProbeReturn { ... fprintf(stdout, "probe cb data: %p\n", data); ... fprintf(stdout, "probe %u, offset: %lu\n", info->size, info->offset); fflush(stdout); ... return GST_PAD_PROBE_OK; }, impl, [](gpointer data) -> void { fprintf(stdout, "probe dn data: %p\n", data); fflush(stdout); }); fprintf(stdout, "filesink_probe: %lu\n", filesink_probe); fflush(stdout); ... } } ... break; ... I added printf to probe's callback and to destroy notify callback. Situation is following: on OS X with GStreamer 1.4.5, I see a lot of printfs called from probe callback. on Ubuntu and CentOS with GStreamer 1.5.1 and 1.5.0 I can not see printfs from callbacks being called. But filesink writes data in both cases.
Replacing GST_PAD_PROBE_TYPE_BUFFER with GST_PAD_PROBE_TYPE_BUFFER | GST_PAD_PROBE_TYPE_BUFFER_LIST solves my problem.
You're not telling us about your pipeline, so we can only guess. I suspect you're using mpegtsmux. The behaviour of mpegtsmux has changed in that it now outputs buffer lists. We *could* fall back to splitting out bufferlists in case there's a buffer probe attached, but it's not clear to me that's desirable. I'm leaning towards resolving as NOTABUG.
Yes, not a bug. I was just confused by enum constant names. So, as I understood correctly, pad can either receive single buffer or buffer list. Correct? In this case it's a bit unclear for me why GST_PAD_PROBE_TYPE_BUFFER not works for list of buffers. If pad got list of buffers, I'm assuming it got several buffers.
May be we should rename GST_PAD_PROBE_TYPE_BUFFER somehow to indicate that its only handle single buffers?
(In reply to Kyrylo V. Polezhaiev from comment #4) > May be we should rename GST_PAD_PROBE_TYPE_BUFFER somehow to indicate that > its only handle single buffers? You mean document better ? Obviously renaming a stable API is not an option. If you want to improve the documentation string, please do! We also need to find a efficient way to state which probe type are combinations (as the doc don't show this anymore).
Is anything still needed here other than a documentation fix?
I think just a docs fix. Unless people are of the opinion that we should serialise bufferlists for probes to maintain backwards compatibility in cases like this.
No, I don't think we should brake lists into the buffers just for probes. I don't know how that worked in the past. If we can not rename constant in stable API we can add an alias name to underline it's dedication to single / individual buffers. Because buffer list is still list of... buffers. So buffers do arrive into the pad. Also, it seems that every list produced by MpegTsMux has exactly one buffer inside :)