[Bug 791285] 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

--- Comment #20 from Sergey Mamonov <samamonov at gmail.com> ---
>  1) PTS -> running-time (see gst_segment_to_running_time())
>  2) OnTime if: running-time + some_latency <= clock_time_now

Thanks it is clear for me that base_time should not been modified but latency
has to be increased. But I still have misunderstanding how and where it should
be done(internally by jitterbuffer logic, internally in audiomixer logic or
externally by some application code)

> > I expected that rtpjitterbuffer's latency shows what is a maximum time
> > rtpjitterbuffer can keep incoming message before it has to be produced. It
> > is needed for fix some possible issues with message reordering and bursting
> > which can happend during sending messages over UDP.
> 
> No, rtpjitterbuffer don't have an upper limit by default unless you set
> drop-on-latency property to TRUE. It's kind of a missing feature to have
> some proper limits. drop-on-latency is a bit too agressive for most use
> cases.
I understand rtpjitterbuffer latency description
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-rtpjitterbuffer.html#GstRtpJitterBuffer--latency
absolutely different way.


> It's a very difficult problem to implement dynamic jitterbuffer. No one in
> the GStreamer community have proposed a solution. To be fair, audiomixer
> works for my use case, but I use the default slave mode, not the none mode
> that you seem to use.
slave mode works fine for me as well, but i have silence in modes node/synced

The main question for me is when audiomixer starts working in my case it has
all information for making a conclusion that 'latency' set incorrectly and some
bursting and pissible permanent silence can happen. It also can calculate some
'correction' value for fixing this situation.

Do you have any ideas what should audiomixer perform in such situation:
1) to do nothing and to work as previously (reject this ticket)
2) to report incorrect latency with some WARNING/INFO trace
3) to try to fix this latency internally (may be this functionality should be
enabled by some property flag)
4) your option?

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