gstaggregator with start-time-selection=first uses incorrect base_time when waiting for data on sink pads
Submitted by Sergey Mamonov
Created attachment 365067
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;
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?
Patch 365067, "possible solution":