[Bug 744106] Maximum latency handling broken everywhere

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=744106
  GStreamer | gstreamer (core) | unspecified

--- Comment #12 from Olivier Crête <olivier.crete at ocrete.ca> 2015-02-08 01:11:16 UTC ---
I think queues that have min/max set in bytes/buffers should try to use the
convert query to transform that into time, if that fails, then they should just
fail the latency query, which means that they aren't fit for use in a live
pipeline.

That would probably break the current usage of queues in decodebin, but I think
it's already broken as it can cause the pipeline to just drop every buffer if
they queue for longer than the declared latency, and it provides no
jitterbuffering at all in these cases anyway as all the queues will never fill
up higher than the min. My "hack" in these cases is to implement the latency
query in the application and set a value higher than min (but lower than max). 

I guess the queues (multiqueue?) could instead have a "error-above-bytes" and
"error-above-buffers", which would emit an error message, if the pipeline can't
preroll without buffering more than the limited number of buffers or bytes,
then it should fail instead of just blocking forever or randomly dropping
things.

I admit I hadn't though of leaky queues, as I have yet to hear a good use-case
for them, I generally feel that the QOS event handling is what you want
instead. That said, having them reset the max-latency to their max latency is
probably right, as it means nothing will ever be buffered upstream of a leaky
queue.

I think GstBaseSrc should set the default to [0,0] for "instantaneous" live
sources (videotestsrc, udpsrc, etc), as they never buffer anything and create
buffers "right now". Sources with a fixed latency, should set [n,n], etc.

That said, I'd really like to see Wim's input as he designed this latency thing
in the first place and put the max=-1 in basesrc.

-- 
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.