[gstreamer-bugs] [Bug 640610] basesink: QoS events are wrong in live pipelines

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #11 from Felipe Contreras <felipe.contreras at gmail.com> 2011-01-26 21:29:05 UTC ---
(In reply to comment #10)
>   The Fact is that elements that report latencies can only report latencies for
> which they are certain (in the case of an audio/video sources how big the
> capture buffers are, in the case of decoders how many buffers they will need to
> buffer up before they can decode them, in the case of rtpjitterbuffer how long
> it will delay the packets,...).
>   Those are *known* latencies (which can be updated, but there are
> determined/explicit formulas for calculating them based on the input). They do
> *not* depend on cpu speed/availability.

But of course in order to calculate those latencies, the framerate is needed,
which in the rtp example, it's not.

>   If you had an element that was doing some processing backed with a dsp with
> guaranteed/constant processing time based on input, you *could* report that
> latency (audio processing algorithms come to mind here).

Just to bring this a bit closer to reality. The DSP is not a magic box, just
like any other CPU, it cannot know beforehand exactly how much time a certain
input need to be processed. The best you can say (if the DSP is ruining a
real-tile OS), is that _after_ the processing you would receive the response
after exactly a certain amount of time. However, by _you_ I mean the GPP, which
of course runs linux, which is not real-time and there's tons of things that
could delay such response.

IOW; there's no way to report that latency.

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