GNOME Bugzilla – Bug 795437
Not all outgoing buffers are caught while using data probes
Last modified: 2018-11-03 15:29:31 UTC
When I attach data probe to srcpad of `rtph264pay` element it doesn't catch all buffer the element sends. I'm adding a probe with ``` gst_pad_add_probe (pad, GST_PAD_PROBE_TYPE_BUFFER, (GstPadProbeCallback) cb_have_data, &m_latencyInfo, NULL); ``` and then writing down buffer info: ``` static GstPadProbeReturn cb_have_data (GstPad *pad, GstPadProbeInfo *info, gpointer user_data) { GstStructure *stats; guint mtu, seqnum, timestamp; gint seqnumOffset; g_object_get (G_OBJECT (element), "stats", &stats, NULL); g_object_get (G_OBJECT (element), "mtu", &mtu, NULL); g_object_get (G_OBJECT (element), "seqnum", &seqnum, NULL); g_object_get (G_OBJECT (element), "seqnum-offset", &seqnumOffset, NULL);&seqnum); gst_structure_get_uint(stats, "timestamp", ×tamp); log_debug("seqnum: % " PRIu32 " seqnum-offset: %" PRId32 " ts: %" PRIu32 " mtu: %" PRIu32 " size: %" PRId32, seqnum, seqnumOffset, timestamp, mtu, gst_buffer_get_size(buffer)); } ``` With default MTU value 1400 it shows only small amount of sent buffers (or packets): ``` seqnum: 0 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 14 seqnum: 1 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 23 seqnum: 2 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 16 seqnum: 163 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 14 seqnum: 164 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 23 seqnum: 165 seqnum-offset: 0 ts: 2467070291 mtu: 1400 size: 16 seqnum: 326 seqnum-offset: 0 ts: 2467160291 mtu: 1400 size: 14 seqnum: 327 seqnum-offset: 0 ts: 2467160291 mtu: 1400 size: 23 seqnum: 328 seqnum-offset: 0 ts: 2467160291 mtu: 1400 size: 16 seqnum: 489 seqnum-offset: 0 ts: 2467250291 mtu: 1400 size: 14 seqnum: 490 seqnum-offset: 0 ts: 2467250291 mtu: 1400 size: 23 seqnum: 491 seqnum-offset: 0 ts: 2467250291 mtu: 1400 size: 16 seqnum: 652 seqnum-offset: 0 ts: 2467340291 mtu: 1400 size: 14 seqnum: 653 seqnum-offset: 0 ts: 2467340291 mtu: 1400 size: 23 seqnum: 654 seqnum-offset: 0 ts: 2467340291 mtu: 1400 size: 16 seqnum: 815 seqnum-offset: 0 ts: 2467430291 mtu: 1400 size: 14 ``` and doesn't show main packets with encoded video, only SPS/PPS ones (probably). However all packets are displayed when I set MTU to value bigger than max packet size it produces: ``` seqnum: 0 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 14 seqnum: 1 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 23 seqnum: 2 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 16 seqnum: 3 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 220525 seqnum: 4 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 14 seqnum: 5 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 23 seqnum: 6 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 16 seqnum: 7 seqnum-offset: 0 ts: 154585161 mtu: 957712 size: 220784 seqnum: 8 seqnum-offset: 0 ts: 154675161 mtu: 957712 size: 14 seqnum: 9 seqnum-offset: 0 ts: 154675161 mtu: 957712 size: 23 seqnum: 10 seqnum-offset: 0 ts: 154675161 mtu: 957712 size: 16 seqnum: 11 seqnum-offset: 0 ts: 154675161 mtu: 957712 size: 220781 seqnum: 12 seqnum-offset: 0 ts: 154765161 mtu: 957712 size: 14 seqnum: 13 seqnum-offset: 0 ts: 154765161 mtu: 957712 size: 23 seqnum: 14 seqnum-offset: 0 ts: 154765161 mtu: 957712 size: 16 seqnum: 15 seqnum-offset: 0 ts: 154765161 mtu: 957712 size: 220575 seqnum: 16 seqnum-offset: 0 ts: 154855161 mtu: 957712 size: 14 ```
Just realized that the problem appears now only with data probes but also when debugging a pipeline with GST_SCHEDULING: ``` 0:00:03.673142334 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<capsfilter0:sink> calling chainfunction &gst_base_transform_chain with buffer buffer: 0xbaaf38, pts 0:00:00.800000000, dts 99:99:99.999999999, dur 0:00:00.033333333, size 3110400, offset 24, offset_end 25, flags 0x0 0:00:03.673697668 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<imxipuvideotransform0:sink> calling chainfunction &gst_base_transform_chain with buffer buffer: 0xbaaf38, pts 0:00:00.800000000, dts 99:99:99.999999999, dur 0:00:00.033333333, size 3110400, offset 24, offset_end 25, flags 0x0 0:00:03.674094001 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<imxvpuencoderh264-0:sink> calling chainfunction &gst_video_encoder_chain with buffer buffer: 0xbaaf38, pts 0:00:00.800000000, dts 99:99:99.999999999, dur 0:00:00.033333333, size 3110400, offset 24, offset_end 25, flags 0x0 0:00:03.719815001 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<h264parse0:sink> calling chainfunction &gst_base_parse_chain with buffer buffer: 0xbd02b0, pts 0:00:00.800000000, dts 0:00:00.800000000, dur 0:00:00.033333333, size 220698, offset none, offset_end none, flags 0x2000 0:00:03.723058001 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<rtph264pay0:sink> calling chainfunction &0x76598f20 with buffer buffer: 0xbd0350, pts 0:00:00.800000000, dts 0:00:00.800000000, dur 0:00:00.033333333, size 220698, offset 5295648, offset_end none, flags 0x400 0:00:03.723454001 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<udpsink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0xbd02b0, pts 0:00:00.800000000, dts 0:00:00.800000000, dur 99:99:99.999999999, size 14, offset none, offset_end none, flags 0x4000 0:00:03.724235334 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<udpsink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0xbd0210, pts 0:00:00.800000000, dts 0:00:00.800000000, dur 99:99:99.999999999, size 23, offset none, offset_end none, flags 0x6000 0:00:03.724790668 9620 0xb7a1b0 DEBUG GST_SCHEDULING gstpad.c:4203:gst_pad_chain_data_unchecked:<udpsink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0xbc4990, pts 0:00:00.800000000, dts 0:00:00.800000000, dur 99:99:99.999999999, size 16, offset none, offset_end none, flags 0x6000 ``` You may see that there are records only about small packets sent from rtph264pay to udpsink.
Sorry, by "that the problem appears now" it meant "that the problem appears not"
rtph264pay might push out buffer lists, which you would have to catch with a separate probe flag.
I see, thank you. So is it a kind of bug?
Well, not really. If a probe only catches buffers but not buffer lists it's not really clear if the probe author wanted to catch all data or just buffers but not buffer lists. It could be argued of course that there are hardly any legitimate use cases where someone would really only want to probe buffers but not buffers inside a list, and that GstPad should hence de-listify in case of a buffer-only probe as well (just like it does when pushing onto an element that doesn't have list support). If someone wanted to make a patch for that it might get accepted.
I don't think we can patch this easily, because of the return value. I'm fine saying you must handle both buffers and buffer list.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/468.