[Bug 752746] harness: Keep synchronized events in sync with buffers

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Jul 23 11:42:54 PDT 2015


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

--- Comment #4 from HÃ¥vard Graff (hgr) <havard.graff at gmail.com> ---
Lets at least try and agree on something! We have currently (quick grep) 1473
tests using GstHarness, and it would be terribly sad if we had to fork it
already given all the effort we have put into getting it upstream, and the
steady stream of tests we have been providing ever since.

I have a strong preference to keep pull_event and pull as is, so that buffers
and events are separated, and can be individually inspected and pushed onwards
if desirable. This is the simplest solution, that also gives full flexibility
in writing tests.

Now, since 1.x, there are three events that needs to be present before you can
start pushing buffers, the Segment, Caps and Stream-Start. It quickly became
tedious to always have to manually pull and push these three events from
src-harness to main-harness in every test, so the forward-pad was born.

I completely agree that this has some shortcomings. It currently only forwards
STREAM_START, CAPS and SEGMENT, but there could be more of CAPS coming later
which probably should not be magically forwarded (but rather put on the
event-queue for inspection).

Thinking about it, it *should* be allowed to turn off the forwarding. This
allows you to drop, modify or forward the events coming from the src-harness
(which could have some applications), and it allows taking control of a case
like you describe, where you would simply disable the forwarding, and then use
alternating gst_harness_src_push_event and gst_harness_push_from_src to get the
sequence right (and deterministic).

So I would suggest adding a gst_harness_disable_forwarding or something like
that, and keeping everything else as-is, as this would solve your problem, and
not create any new ones for us! :)

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


More information about the gstreamer-bugs mailing list