[Bug 781958] harness: Abort when failed to construct the specified pipeline

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=781958

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.13.1

--- Comment #9 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
commit 5d40e49d12ecc9202c446909b0cc410d0bbc2cbb
Author: Yasushi SHOJI <yashi at atmark-techno.com>
Date:   Sun Apr 30 12:10:49 2017 +0900

    harness: Abort when failed to construct the specified pipeline

    gst_harness_new_parse() returns without any error even if it doesn't
    find the specified element.  Then a succeeding call to
    gst_harness_set_sink_caps_str() causes an error like this:

            Unexpected critical/warning: gst_pad_push_event: assertion
'GST_IS_PAD (pad)' failed

    This is a bit cryptic and doesn't give users any clue what was going
    on.

    gst_harness_new_parse() calls gst_harness_add_parse() with a newly
    created empty harness and the given pipeline description string, but
    gst_harness_add_parse() does not have a way to propagate the error
    back to the caller.  Since the function, gst_harness_add_parse(), is a
    public API, it's not a good idea to change its signature.  This patch,
    instead, makes the function to g_error() when it discovers any error.
    With this change the same error prints:

            ** (myelement-test:25345): ERROR **: Unable to create pipeline
'bin.( myelement )': no element "myelement"

    The current implementation of gst_parse_launch_full() doesn't return
    partially constructed pipeline when GST_PARSE_FLAG_FATAL_ERRORS is
    specified, however, this patch also adds a check for it.

    https://bugzilla.gnome.org/show_bug.cgi?id=781958

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.