[Bug 791285] New: gstaggregator with start-time-selection=first uses incorrect base_time when waiting for data on sink pads

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 791285
           Summary: gstaggregator with start-time-selection=first uses
                    incorrect base_time when waiting for data on sink pads
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: samamonov at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 365067
  --> https://bugzilla.gnome.org/attachment.cgi?id=365067&action=edit
possible solution

Hi
I'm testing farstream rtp conference with audiomixer. 

| farstream participant 1 | -> | audiomixer | -> | farstream participant 2|

It was find out that in case of jitterbuffer mode=none audiomixer drops
incomming audio packets almost since it start. As far as I understand it
happens when audiomixer (gstaggregator) moves to live mode and waits for some
time if there are no data on input pads. The problem is that in case
gstaggregator's property start-time-selection is set to 'first' function
gst_aggregator_wait_and_check() calculates wake time the following way:

time = base_time + start + latency;

where:
start - a time when the next buffer has to be sent (i.e it is pts of buffer has
to be sent next)
latency - latency of element
base_time - time when element goes to PLAYING mode.

I assume that the problem is that for aggregator with
start-time-selection=first base_time is not equal with the time when the
element produces the first buffer pts=0.00000000. I.e. we have some time lag
between moments when aggregator moves to state PLAYING and the moment when it
receives the first buffer on it's sinks and produces the first buffer
pts=0.00000000 over it's src pad.

I have introduced some traces and I see that time between sending aggregated
buffer pts 0.10000000 (the last buffer which sink pad had received this buffer)
and starts mixing and sending aggregated buffer pts 0.12000000 performs without
wait:

0:00:01.763980665    45 0x56416f77eed0 DEBUG             aggregator
gstaggregator.c:690:gst_aggregator_wait_and_check:<output_mixer_0> possibly
waiting for clock to reach 2887:08:36.661652285 (base 2887:08:36.161652285
start 0:00:00.120000000 latency 0:00:00.380000000 current 2887:08:36.895968312)

as you can see the current time is more than wake time so there is no delay
between sending aggregated buffer pts 0.10000000 and sending empty buffer pts
0.12000000

My proposal is to set gstaggregator's base_time to the time when it produces
first buffer on it's src pad.
Infoutunately audiomixers's source code is bit difficult for me. Could you
please review my patch and let me know if it can broke something else?

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