Depending on when gst_harness_pull was called - before the buffer reached
gst_harness_chain or after we can get different behaviors of the test
with enabled blocking push mode. The fix makes the behavior always the
same. In pull function we get the buffer first, thus making sure
gst_harness_chain waits for the signal, and emitting the signal after.
https://bugzilla.gnome.org/show_bug.cgi?id=761931
Set the sink_forward_pad to NULL before tearing down sink_harness to
avoid that the harness tries to forward events/queries to it while it's
tearing down.
https://bugzilla.gnome.org/show_bug.cgi?id=761904
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
1. Get a list of pad templates from the element class, not the
factory. This allows us to interact with test-elements that does
not have a factory.
2. Use the pad_template_caps in caps-queries when caps is not set
explicitly on the pad. Not doing so is simply wrong, and prohibits
interactions with special templates used for testing.
https://bugzilla.gnome.org/show_bug.cgi?id=754193
To be able to disable the slightly "magic" forwarding of the
necessary events between the harnesses.
Also introduce a new test-suite for GstHarness, that documents the
feature, and should hopefully expand into documenting most of the
features the harness possesses.
https://bugzilla.gnome.org/show_bug.cgi?id=752746
Even though asserts can't be disabled in GstHarness, Coverity still
complains about running code inside them. Moving the code to outside the
g_asserts().
CID #1311326, #1311327, #1311328
By introducing gst_harness_add_src_harness and gst_harness_add_sink_harness
we collect all sub-harness setup in one function, making the previous
sub-harness creation functions now calls these directly, and making it
much easier (and less error-prone) to add your own src or sink-harness
using the more generic harness-creation functions.
The element flag does not indicate wether a bin should be tested as a
source or as a sink, eg. a bin with the sink flag may still have a
source pad and a bin with the source flag may have a sink pad. In this
case it is better to determine the element type by looking at the
available pads and pad templates.
Also rename srcpad and sinkpad where it actually represents
element_srcpad_name and element_sinkpad_name.
https://bugzilla.gnome.org/show_bug.cgi?id=752493
