[Bug 761914] New: gstharness: always set our test-clock on the harnessed element

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 761914
           Summary: gstharness: always set our test-clock on the harnessed
                    element
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: havard.graff at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: gstreamer at pexip.com
     GNOME version: ---

Created attachment 320951
  --> https://bugzilla.gnome.org/attachment.cgi?id=320951&action=edit
patch

The integration is already so tight, there is no reason to
not further formalize it!

An element will always get a clock set on it in a "normal" context from the
parent pipeline, and we found that in the tests where we don't care about the
clock, the testclock does not get in the way, and in all the tests where we
*do* want a clock, we will save the extra line of code to set it on the
element.

Not explicitly wanting a clock to be able to test no-clock scenarios is the
more unusual case, and to then have to explicitly do things like
gst_element_set_clock (element, NULL) makes this more explicit and better.

There are also some cases where you want to use the systemclock (stress-tests
or not bothering with determinism), and this then will need a call to
gst_harness_use_systemclock() which is fair.

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