After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756898 - pad: gst_pad_probe_info_get_buffer_list() has wrong ownership transfer
pad: gst_pad_probe_info_get_buffer_list() has wrong ownership transfer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.6.0
Other Linux
: Normal normal
: 1.6.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-21 10:29 UTC by schmitt
Modified: 2015-10-22 12:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Small python program that failes to get bufferlists from probe that claim to be of type bufferlist (1.69 KB, text/x-python-script)
2015-10-21 10:29 UTC, schmitt
Details

Description schmitt 2015-10-21 10:29:16 UTC
Created attachment 313796 [details]
Small python program that failes to get bufferlists from probe that claim to be of type bufferlist

Hello,

when attaching a bufferprobe to the output of the rtph264pay element, sometimes the padprobeinfo type says it is a bufferlist, but if get_buffer_list() is called a GStreamer-CRITICAL message with "assertion 'GST_IS_BUFFER_LIST (list)' failed" is thrown. Since the type is BufferList, get_buffer() throws a "assertion 'info->type & GST_PAD_PROBE_TYPE_BUFFER' failed" message, but if (as a hack) the type is overwritten to be Buffer and not BufferList, the buffer is returned and can be used correctly.
I presume somewhere the type is set incorrectly?
I could reproduce the issue with rtpmpeg4vpay thus I presume the issue could be in the base elements from rtppayloaders.
I attached a small python program that reproduces the bug.
Comment 1 Sebastian Dröge (slomo) 2015-10-21 11:51:01 UTC
commit 0f5be03d766ffde4ece29bd795e849d0cafbd27d
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Oct 21 14:49:49 2015 +0300

    pad: Fix docs/annotation of gst_pad_probe_info_get_buffer_list()
    
    It's not get_bufferlist(). Because of that it was ignored by the docs and
    G-I, leading to crashes because of broken ownership transfer.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=756898
Comment 2 schmitt 2015-10-21 15:18:27 UTC
Thank you.
But might there be still an ownership issue?

After having called get_buffer_list() and exit the probe callback, I still get the following messages:

GStreamer-CRITICAL **: gst_buffer_list_length: assertion 'GST_IS_BUFFER_LIST (list)' failed

GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object->refcount > 0' failed

And the bufferlist seems not to get processed any further (even though I returned Gst.PadProbeReturn.OK)

(In reply to Sebastian Dröge (slomo) from comment #1)
> commit 0f5be03d766ffde4ece29bd795e849d0cafbd27d
> Author: Sebastian Dröge <sebastian@centricular.com>
> Date:   Wed Oct 21 14:49:49 2015 +0300
> 
>     pad: Fix docs/annotation of gst_pad_probe_info_get_buffer_list()
>     
>     It's not get_bufferlist(). Because of that it was ignored by the docs and
>     G-I, leading to crashes because of broken ownership transfer.
>     
>     https://bugzilla.gnome.org/show_bug.cgi?id=756898
Comment 3 Sebastian Dröge (slomo) 2015-10-21 15:33:47 UTC
Possible. How did you test the fix, what did you update and how?
Comment 4 schmitt 2015-10-21 16:17:01 UTC
I cloned the 1.6 branch, compiled and installed ... (well first I only changed the name in the 1.6.0 tag that I had already downloaded... but then just to be sure also the latest 1.6 branch).

When I run the in the original report attached python script, it creates these errors (and the image is distorted everytime a bufferlist comes, so I presume the buffers have been dropped..)
Comment 5 Sebastian Dröge (slomo) 2015-10-21 16:20:19 UTC
There's another bug somewhere then :)
Comment 6 Sebastian Dröge (slomo) 2015-10-22 08:24:41 UTC
Your sample application works fine here now. Make sure that you update the Gst-1.0.gir *and* Gst-1.0.typelib files that were on your system before and used by pygi. "make install" might install them in different locations, depending on your distro, etc.
Comment 7 schmitt 2015-10-22 12:12:21 UTC
Thank you very much for the hint! - yes the typelib files very not installed correctly.

(In reply to Sebastian Dröge (slomo) from comment #6)
> Your sample application works fine here now. Make sure that you update the
> Gst-1.0.gir *and* Gst-1.0.typelib files that were on your system before and
> used by pygi. "make install" might install them in different locations,
> depending on your distro, etc.