GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Invalid argument. Aborting.
Sergei Vorobyov
sergei.vorobyov at facilitylabs.com
Tue Sep 23 02:56:29 PDT 2014
Sorry for my previous garbled code. Here's a better callback attempt which
discriminates between two cases: 1) when decodebin adds a video pad and 2)
when decodebin adds a non-video (audio pad).
I have two questions:
1) can the non-video pad (see the "ignoring" case below) be left without
linking, or it must be linked to the fakesink?
2) should str be unreffed?
3) should str_name be g_freed? (or it belongs to the internals?)
Thanks, I could not find the answers in the manuals/APIs
static void composition_new_pad (GstElement *decodebin, GstPad *pad,
gpointer identity) {
LOG_INFO("dynamically linking %s to %s...", GST_OBJECT_NAME
(decodebin), GST_OBJECT_NAME (identity));
GstCaps *caps = gst_pad_query_caps (pad, NULL);
GstStructure *str = gst_caps_get_structure (caps, 0);
gchar const *str_name = gst_structure_get_name (str);
if (!g_str_has_prefix (str_name, "video")) {
LOG_INFO("non-video pad type: %s, ignoring...", str_name);
gst_caps_unref (caps);
return;
}
if (gst_pad_is_linked (pad)) {
LOG_INFO("already linked!");
gst_caps_unref (caps);
return;
}
GstPad *sinkpad = gst_element_get_compatible_pad ((GstElement*)
identity, pad, caps);
gst_caps_unref (caps);
if (!sinkpad) {
LOG_INFO("empty sinkpad, ignore and return");
//LOG_ERROR("can't create sinkpad on %s", GST_OBJECT_NAME (data));
return;
}
GstPadLinkReturn pad_link_outcome = gst_pad_link (pad, sinkpad);
if (pad_link_outcome == GST_PAD_LINK_OK)
LOG_INFO("success!");
else
LOG_ERROR("composition_new_pad(): gst_pad_link() failed with code %d",
pad_link_outcome);
gst_object_unref (sinkpad);
}
On Tue, Sep 23, 2014 at 11:31 AM, Sergei Vorobyov <
sergei.vorobyov at facilitylabs.com> wrote:
> please disregard my erroneous callback code in the previous message, which
> I accidentally sent before finishing
>
> On Tue, Sep 23, 2014 at 11:29 AM, Sergei Vorobyov <
> sergei.vorobyov at facilitylabs.com> wrote:
>
>> A partial answer to myself:
>>
>> the .wmv media files in question cause decodebin call the callback
>> function twice in quick succession, once for video, once for audio
>>
>> I can discriminate between these cases using the following callback:
>>
>> static void composition_new_pad (GstElement *element, GstPad *pad,
>> gpointer data) {
>> LOG_INFO("dynamically linking %s to %s...", GST_OBJECT_NAME
>> (element), GST_OBJECT_NAME (data));
>> GstCaps *caps = gst_pad_query_caps (pad, NULL);
>> GstStructure *str = gst_caps_get_structure (caps, 0);
>> gchar const *str_name = gst_structure_get_name (str);
>> if (!g_str_has_prefix (str_name, "video")) {
>> LOG_INFO("non-video pad type: %s, ignoring...", str_name);
>>
>> return;
>> }
>> gst_caps_unref (caps);
>> if (gst_pad_is_linked (pad)) {
>> LOG_INFO("already linked!");
>> return;
>> }
>> GstPad *sinkpad =
>> gst_element_get_compatible_pad ((GstElement*) data, // identity
>> pad,
>> gst_pad_query_caps (pad, NULL)); // struct GstPad
>> if (!sinkpad) {
>> LOG_INFO("empty sinkpad, ignore and return");
>> //LOG_ERROR("can't create sinkpad on %s", GST_OBJECT_NAME (data));
>> return;
>> }
>> GstPadLinkReturn pad_link_outcome = gst_pad_link (pad, sinkpad);
>> if (pad_link_outcome == GST_PAD_LINK_OK)
>> LOG_INFO("success!");
>> else {
>> LOG_ERROR("composition_new_pad(): gst_pad_link() failed with code %d",
>> pad_link_outcome);
>> }
>> gst_object_unref (sinkpad);
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 22, 2014 at 2:01 PM, Sergei Vorobyov <
>> sergei.vorobyov at facilitylabs.com> wrote:
>>
>>> This error
>>>
>>> GLib (gthread-posix.c): Unexpected error from C library during
>>> 'pthread_mutex_lock': Invalid argument. Aborting.
>>>
>>> frequently happens when I am using vaapisink with i964_drv_video.so on
>>> Intel built-in graphics of NUC DN2820FYKH
>>>
>>> but *never* happens if I use ximagesink without video acceleration on
>>> NVidia Quadro FX580, without video acceleration (btw, I am missing
>>> /usb/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so and cannot find it in
>>> any packages).
>>>
>>> From this I plausibly conclude that my code is innocent.
>>>
>>> Googling for the above error produces many reports, but nothing that
>>> makes sense to me.
>>>
>>> After adding some debugging code I also suspect that the .wmv files may
>>> be the issue:
>>>
>>> 1. I am playing different media files through the same pipeline by
>>> varying different location=.... for the filesrc element
>>>
>>> 2. I am dynamically linking decodebin with identity, using
>>> g_signal_connect.
>>>
>>> 3. For that purpose I g_signal_connect decodebin on "pad-added" with a
>>> callback that is usually called ONCE per .avi files,
>>>
>>> 4. but TWICE in a very quick succession (a few milliseconds) on .wmv
>>> files. The first call returns a non-NULL sinkpad = gst_get_compatible_pad
>>> (identity, ...), which I link with the source pad of decodebin. The second
>>> call is problematic, it returns NULL==gst_get_compatible_pad (identity,
>>> ....). I can do nothing but ignore/return for that second call. The pipe
>>> plays invariably OK on NVidia without video acceleration but frequently
>>> breaks on i964_drv_video.so with video acceleration and vaapisink
>>>
>>> 5. Remark: I do not play sound, just images and video. I just relink the
>>> pipe (in C) between
>>>
>>> filesrc ! decodebin ! identity ! imagefreeze ! videoconvert !
>>> <videosink> for still images and
>>> filesrc ! decodebin ! identity ! videoconvert ! <videosink> for movies
>>>
>>> Maybe this explains everything to you?
>>>
>>>
>>>
>>> On Sun, Sep 21, 2014 at 3:40 PM, Tim Müller <tim at centricular.com> wrote:
>>>
>>>> On Fri, 2014-09-19 at 14:08 +0200, Sergei Vorobyov wrote:
>>>>
>>>> Hi,
>>>>
>>>> > GStreamer 1.2.4 and GLib v2.40.0
>>>> > I recently started to systematically get the following error:
>>>>
>>>> > GLib (gthread-posix.c): Unexpected error from C library during
>>>> > 'pthread_mutex_lock': Invalid argument. Aborting.
>>>> >
>>>> >
>>>> > [I preliminary guess it started when I switched from ximagesink to
>>>> > vaapisink,
>>>> > but this remains to be investigated]
>>>> >
>>>> >
>>>> > That does not come from my code and looks like a programming error.
>>>> > Sure I use a few threads, but those are initialized in the very
>>>> > beginning and run as infinite loops, nothing fancy.
>>>>
>>>> How do you know it's not from your code? It may be unlikely, but it
>>>> could also be some memory corruption caused by your code.
>>>>
>>>> > Apparently, it's a long-standing issue. There are many reports, but
>>>> > they don't explain nor fix the issue.
>>>>
>>>> It's the first time I hear about it. Many reports where? Is there a
>>>> report in bugzilla? If not, please file one, ideally with a stack trace
>>>> and if available also valgrind output (after installing libc, glib and
>>>> gst debugging symbols).
>>>>
>>>> Cheers
>>>> -Tim
>>>>
>>>> --
>>>> Tim Müller, Centricular Ltd - http://www.centricular.com
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140923/dfb6bc83/attachment.html>
More information about the gstreamer-devel
mailing list