Re: Aggregator (glvideomixer) in force-live mode "runs ahead" of pipeline clock

Hey Michiel,

What you describe does not sound like the intended behavior, indeed
with force-live you should not even need to have any source connected
to a sink pad of the element to have it act as live source, pushing out
data at the expected pace.

Can you try this first perhaps? Just use the element as a source with
no source upstream and see what happens? Perhaps there is some bug with
having all-eos inputs in force-live mode?

Can you also try with a different subclass (eg compositor) just to rule
out any unlikely error with glvideomixer ?

Cheers,
Mathieu

On Tue, 2023-09-19 at 07:50 +0000, Michiel Konstapel via gstreamer-
devel wrote:
> I am using a glvideomixer to switch between a placeholder image and a
> live 
> source that's initially not connected. Instead of an imagefreeze on
> the 
> placeholder image, I am trying to use force-live mode on the mixer,
> and 
> sending it just a single frame on a repeat-after-eos pad. However, in
> this 
> initial state (no actual live input connected) the glvideomixer
> appears to 
> be generating output buffers as far as downstream will take them,
> without 
> any regard for the pipeline clock. It looks like 
> gst_aggregator_wait_and_check will always see 
> gst_aggregator_check_pads_ready return TRUE because the only sinkpad
> is 
> EOS, and never gets to any of the consideration of latency and clock
> time: 
> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/libs/gst/base/gstaggregator.c#L841
> 
> 
> Am I interpreting this correctly, and is it intended behaviour? If
> so, how 
> do I get *my* intended behaviour, having the mixer behave (from 
> downstream's point of view) like a proper live source whether or not
> a 
> network input is connected?
> 
> Kind regards,
> Michiel