[Bug 744106] Maximum latency handling broken everywhere

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Feb 6 13:23:25 PST 2015

  GStreamer | gstreamer (core) | unspecified

Olivier CrĂȘte <olivier.crete> changed:

           What    |Removed                     |Added
                 CC|                            |olivier.crete at ocrete.ca

--- Comment #1 from Olivier CrĂȘte <olivier.crete at ocrete.ca> 2015-02-06 21:23:23 UTC ---
I think you're understanding of the maximum latency is not correct, what you're
describing is the min latency. I understand it as the maximum amount of buffers
(in time) that the element can accumulate.

Each element is meant to just add it's min and max the result of the upstream
query, for the max, NONE means "infinite" and is an absorbing value.

1) For an element like an encoder (or deinterlace) that has a fixed number of
buffers inside of it, min=max=n. This element will not produce buffers before
it has n data inside of it, and will block the input as soon as it reaches n
2) For a queue with min-threshold-*=max-size-*=0 that can grow without bounds,
the min=0, max=NONE.
3) for an element with no latency (filters, like audioconvert/audioresample),

I understand that the max latency is just a check to verify that you have
enough queuing in your pipeline.

For example, if for the audio you have the following pipeline:
zerolatencysource ! audiodecoder_with_no_latency ! zerolatencysink
zerolatencysource ! videodecoder_with_b_frames ! zerolatencysink
Then the min and max latency from the audiosink query will be 0, but for the
video sink, min=max=latency-of-the-decoder. Then GstBin will check that 
MAX(min)>=MIN(max) and that check will fail unless you add queue in the audio
pipeline, because the video takes "latency-of-decoder" to get to the sink, so
the audio has to be delayed by the same amount, but since there is no queues on
the audio sink, there is nowhere to store that data.

Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the gstreamer-bugs mailing list