[Bug 757548] aggregator: Forced to produce data in paused state

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Sebastian Dröge (slomo) from comment #16)
> Comment on attachment 326139 [details] [review]
> aggregator: Fix locking when using the clock
> 
> Typo in commit message (shit -> shot), otherwise good to go :)

Oops, will fix.

(In reply to Sebastian Dröge (slomo) from comment #17)
> Comment on attachment 326578 [details] [review]
> aggregator: Start the task when linked
> 
> This still seems to have the problem that you wait for a stream-start event
> before starting, but might already want to produce data in a live scenario.
> Consider the case where we link a live upstream that is already running and
> has sent its sticky events to the srcpads already before linking (like all
> demuxers do) but receives no data for a while. It would successfully answer
> the LATENCY query, but you will only see the stream-start event once the
> first buffer is sent (or another serialized event). We don't forward sticky
> events automatically when linking as that would forward them from the
> application thread and potentially block the application for a while.

I agree. I now have a better understanding of the strategy that was initially
used in aggregator. The idea is that it expects the query to fail until the
data is valid. So the real bug is probably that an element didn't fail and
reply with a non-live latency query in the first pace. I'll do another round of
investigation. There could be another bug around latency update, as it should
have been updated in that case. Tracking this is hard, because enabling traces
often prevent triggering the bug.

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