[Bug 749966] videoaggregator: add wait-sinks property to wait for inputs before creating output frames

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
I think we are confusing a first frame strategy from run-time strategy. The
original use case here is that following:

v4l2src name=a ! mixer.
v4l2src name=b ! mixer.
  videomixer name=mixer background=black ! output

Currently, the first few frame will randomly be:

  black | a | a+b | ...
  black | b | a+b | ...
  a | a+b | ...
  b | a+b | ...
or
  a+b | a+b

Because v4l2src may take different amount of time to start producing after the
pipeline has reached playing state. At run-time, it won't make much difference,
the current mixer behaviour is fine and the matching is quite smooth.

The problem is that this deadline only behaviour result in random mix of
streams all the time. The use case, and I think it's a fair live use case, is
that we would prefer having a initial gap then having a first frame which is
the background color defined in the mixer (or only 1 of the two images).

What I'm proposing here, is to enable for multiple first frame strategy
(instead of 2 using a boolean). So we can extend as needed. I think this
discussion already raised 4 cases.

1. Only start produce if a+b is possible (data on all pad, could wait forever
if the source can be sparse, but that is not a problem in live editing)
2. Only start producing if at least one of a or b is possible
3. Only start produce if a is present (or any other, that one would need
something on the pad indeed)
4. Produce as soon as the next deadline is met. This is current behaviour.

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