[gstreamer-bugs] [Bug 640610] basesink: QoS events are wrong in live pipelines
bugzilla at gnome.org
Wed Jan 26 13:29:09 PST 2011
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.
More information about the Gstreamer-bugs